[elektro] Atmega 168 Bootloader helyhiány

[Kardos Péter]

Megnéztem a map fileokat és csak a saját függvényeim vannak benne én 
printf-et nem is használok csak saját függvényeket kivéve a bootloader 
leégető rutint! Lehet hogy a sok tömbkezelés miatt lett ilyen nagy, :(
-Os van bekapcsolva! :)



Petrik Gergely írta:
> 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]
>>
>>
> ------------------------------------------------------------------------
>
> -----------------------------------------
>           elektro[-flame|-etc]