[elektro] Atmega 168 Bootloader helyhiány

[Kardos Péter]

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]