bootloader AVR nieco inaczej.

Witam!

Dłubie pewne urządzenie, którego głównym zadaniem będzie sterowanie pewnym procesem. Niestety bieganie z komputerem za każdym razem, gdy trzeba zmienić program jest dla mnie kłopotliwe (śjakieś 1000km ;) stąd zaczynam zastanawiać się nad następującą sprawą:

Tworze bardzo prosty soft, którego zadaniem jest komunikacja z kartą MMC na której znajdą się dane pomiarowe zbierane przez urządzneie, ale również kod programu (firmware) do wykonania przez procka. Po połączeniu "bootloader" zrzuca zawartośc MMC do węwnetrznego Flash'a i rozpoczyna wykonywanie kodu.

I mam pytanie: jako, że z bootloaderem nie miałem do tej pory do czynienia chciałbym zapytać czy to w ogóle jest wykonalne (czytam dokumentacje do ATmega* i wydaje mi się że tak ...) w tej formie jaką podałem. W szczególności czy bootloader ma nieograniczony dostęp do pamięci Flash.

Ponadto jest jeszcze jedna sprawa ... być może chciałbym zaszyfrować firmware jakimś szyfrem jednostronnym. Po zrzuceniu danych do Flasha i ich rozkodowaniu ktoś mógłby wyjśc procka z podstawiki i zczytać rozkodowany kod. Pytanie zatem, czy bootloader może sam sobie przepalić fuse na odczyt kodu ? Z tego co widze są dwa bezpieczniki do bootloadera i reszty ...

Na razie jestem na etapie rozmyślania, czy w ogóle ma to sens, ale wydaje mi się to jednynym sensownym rozwiązaniem na taką odległość.

Reply to
Sebastian Bialy
Loading thread data ...
Reply to
invalid unparseable

:( Ale przynajmniej amatorów jakoś zablokuje. Swoją drogą robią to jakimiś metodami typu rozpuszczanie plastiku czy kombinacja z zasilaniem ? A może jakoś inaczej ;) ?

No ba ;)

Wiem, ale dokumentacja jest słaba w tym miejscu, i nie jestem na 100% pewny, czy mam dostęp do całego flasza włacznie z wektorami przerwań itd. W ogóle mam wrażenie, że ta technika bootloadera jest jakaś taka niedorobiona do końca :/

Źle się wyraziłem - chodzi o algorytm z asymetrycznym kluczem - deszyfrować można wyłącznie na konkretnym uC. To lekkie utrudnienie, nawet gdyby ktoś wyrwał mi program z atmegi, to będzie miał poważny kłopot w przygotowaniu plikow do zaladowania - z racji innego klucza. Oczywiście dla chcącego nic trudnego i można zmodyfikować binarkę, ale tu już bym postarał się lekko utrudnić życie.

Nie - żadnej łaczności - z róznych względów. Jesli miałbym sieć to w ogóle nie było by o czym mówić na pewno bym to wybrał i pozbył się MMC.

Reply to
Sebastian Bialy
Reply to
invalid unparseable

w miarę uniwersalne funkcje odczytu karty MMC przy użyciu sprzętowego portu SPI zajmują mi 324 bajty. po optymalizacji na pewno da się zejść poniżej 300. reszta to już tylko kwestia tego, ile chcemy przeznaczyć na aplikację.

w.

Reply to
Wojtek Kaniewski

ale w czym problem? masz do dyspozycji maksymalnie 2kB na bootloader. programowa obsługa SPI, MMC, FAT, paru klawiszy i zewnętrznego dekodera MP3 zajęła mi 1,7kB. poza tym, jeśli sam wrzucasz firmware na kartę, równie dobrze możesz umieścić go w określonych blokach pamięci i obsługa FAT nie będzie konieczna. programowanie to góra kilkaset bajtów. na oko wychodzi, że zmieściłyby się co najmniej 2 bootloadery.

w.

Reply to
Wojtek Kaniewski

2kB to maksymalna przestrzeń w najmniejszym ATmega8. wszystko co się w tym zmieści, można zastosować w dowolnym ATmega.

w.

Reply to
Wojtek Kaniewski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.