[elektro] Atmega 168 Bootloader helyhiány

[Petrik Gergely]

Akkor passz, de amiket F. Arnold írt, azok bölcs és 
megfontolandó dolgoknak tűnnek. Először is generáltass mapet, 
hogy kiderüljön mi mindenféle fityfenét linkelt hozzá, majd 
pedig ha kiderült, hogy floating point libtől kezdve mindenféle 
nem kihasznált printf-ek és hasonlók vannak a végleges 
image-ben, akkor gondold át, nem-e lehetne printf("%d", abcde); 
helyett valami saját, egyszerűbb rutint használni. Ha 
ilyesmikről szó sincs, akkor jöhet a többi varázslás, a gcc -O 
kapcsolók megtámogatása megfelelő kódolással. A -Os egyébként 
csodákra képes, anélkül szvsz esélytelen, h bármi bárhova 
beférjen... :)

Megj: ha mindezeken már túl vagy, akkor bocsi, magamból indulok 
ki. Amikor először láttam, hogy a floating point lib 
és pl. egy darab fölösleges printf mekkora flashzabálást végez, 
egészen átértékeltem a nézeteimet a "gcc-vel atmega8 / 16-ra 
fejlesztés"-t tekintve. A gcc igazán sztem mega32-től fölfelé 
tud élni, akkor az összes flinc-flanc még mindig csak egy 
részét eszi meg a flashnek, és marad hely a lényegi részeknek.

De ismétlem, csak abból a bruttó 2+1 AVR-es barkácsprojektből 
vonom le a következtetéseket, amivel eddig foglalkoztam...
--
G

On Wed, 12 Nov 2008, Kardos Péter wrote:

> Igen ezt a bootloader funkciót használom én is :) csak még más funkciók
> is vannak. Flash törlés flash olvasás Flash írás Eeprom írás Epprom
> olvasás soros kommunikációban checksum számítás ....
>
>
> Petrik Gergely írta:
>> Szia!
>>
>> Az elején megjegyzem, hogy összesen ha 1-2x foglalkoztam bootloaderes
>> megoldással AVR-en, tehát nem vagyok mindentudó e téren. De 1 kérdés:
>> mi extrát kell tudnia a bootloaderednek, ami miatt ennyire nagy? 2k-ba
>> a soros kommunikáció mellé még némi vezérlés meg mifene is simán
>> elfér, nemhogy a nem túl bonyolult égetési "algoritmus"... Vagy valami
>> spéci titkosított/tömörített image-ekkel dolgozol? Én ezt a nem túl
>> komplikált bootloadert ismerem:
>>
>> http://reza.net/cms/index.php?page=AVReflash
>>
>> Ez belement Atmega16-ba, és a 168-ba tudtommal ugyanakkora bootloader
>> fér be. Megj: az eredeti, amikor én találkoztam vele nem működött
>> 16-on, hozzá kellett nyúlnom (ő is csak a mega128-at és 64-et említi,
>> hogy azokon próbálta).
>> --
>> G
>>
>> On Wed, 12 Nov 2008, Kardos Péter wrote:
>>
>>> Sajnos nem tudom és nincs is érteleme tovább tömöríteni mert a
>>> booatloader rész és a soros kommunkáció amin érkezik a leégetendő adat
>>> az kb 2x annyi mint a bootloader terület. :(
>>>
>>> És azt hogyan dolgozzam "alá" ??? Org direktívát hogyan lehet C ben
>>> használni??? nem az asm funkcióra gondolok!!! :) Vagy hol van egy jó gcc
>>> leírás???
>>>
>>> Üdv:
>>>
>>> Péter
>>>
>>> Fuzesi Arnold írta:
>>>> Illetve ha keves hely hijjan nem fér be, akkor érdemes jatszani a
>>>> fordítóval.
>>>> Sokat lehet gyurni ha kicsit "alá" dolgozol.
>>>> Ciklusok optimalizálása stb.
>>>>
>>>> Arnold
>>>> ----- Original Message -----
>>>> From: "Fuzesi Arnold" <arnold.fuzesi.lista at gmail.com>
>>>> To: <elektro at tesla.hu>
>>>> Sent: Tuesday, November 11, 2008 9:33 PM
>>>> Subject: Re: [elektro] Atmega 168 Bootloader helyhiány
>>>>
>>>>
>>>> IAR-ban siman a linker file-ban megadod h melyik szegmens meddig tart.
>>>> GCC eszempontbol baratibb... eziranyban keresgelj.
>>>>
>>>> Nalam is volt ilyen gond.
>>>> Mivel kb csak a timer IT-t hasznaltam igy a felette levo IT reszek
>>>> szabadok
>>>> lehettek a kódnak...
>>>>
>>>> Pár extra byte...épp befért így nagykinlodva, 1 byte maradt szabadon :)
>>>>
>>>> A.
>>>> ----- Original Message -----
>>>> From: "Kardos Péter" <chiplev at freemail.hu>
>>>> To: <elektro at tesla.hu>
>>>> Sent: Tuesday, November 11, 2008 3:44 PM
>>>> Subject: [elektro] Atmega 168 Bootloader helyhiány
>>>>
>>>>
>>>> Sziasztok!
>>>>
>>>> Már régen voltam itt tag és akkor is inkább mint olvasó, eddig
>>>> PIC-ekkel
>>>> foglalkoztam, de most már AVR-ekkel is foglakozom, és most nekem is
>>>> szükségem van az AVR guruk segítségére. :))
>>>>
>>>> Atmega 168-ast használok AVR GCC fordítóval.
>>>> Egy Bootloader programot írtam C-ben ami már nem fér bele az Atmega168
>>>> ban meghatározott bootloader területre. :(
>>>> Szeretném haszálni a bootloader területén a megszakításvektorokat és
>>>> szeretném ha a uC a bootloder részről tudna indulni nem pedig a
>>>> 0x0000-ról.
>>>> És itt most nagyon elakadtam.
>>>>
>>>> Egyik ötletem, hogy elindul a bootloader területén a kód és a
>>>> folytatása
>>>> az előző "szegmensrészen van" de ezt hogyan lehet megadni a
>>>> fordítónak???
>>>> A másik ötletem hogy a bootloader kezdőcímétől ugrik elöbbre a
>>>> tényleges
>>>> bootloader címre de akkor még a megszakításvektorokat is át kell
>>>> címezni. Ezt hogyan lehet?
>>>> A harmadik ami kivitelezhető de nem ezt akarom hogy a 0x0000 címről
>>>> indul a program egy ugróutasítással a Bootloader elejére ugrik és nem
>>>> használok megszakításvektorokat.
>>>> Megvalósítási ötleteket, vagy egyéb ötleteket várok.
>>>>
>>>> Köszönöm!
>>>>
>>>> Kardos Péter
>>>>
>>>> -----------------------------------------
>>>>           elektro[-flame|-etc]
>>>>
>>>> -----------------------------------------
>>>>           elektro[-flame|-etc]
>>>>
>>>> -----------------------------------------
>>>>           elektro[-flame|-etc]
>>>>
>>>>
>>>>
>>>
>>> -----------------------------------------
>>>          elektro[-flame|-etc]
>>>
>>>
>> ------------------------------------------------------------------------
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
>
> -----------------------------------------
>          elektro[-flame|-etc]
>
>