Sądzę, że nie medium a protokół decyduje o jakości komunikacji (oczywiście w uproszczeniu).

Pisząc o CAT miałem na myśli port szeregowy. A to w jakich standardach będzie on wyprowadzony to inna sprawa...Poza tym, obsługa systemu plików FAT bardzo poszerza ilość potrzebnego miejsca na bootloader. Może się okazać, że mimo wielkości firmware całkowicie mieszczących się w danym uP musimy sięgnąć po wersję o większym Flash'u i zatem przydzielonemu miejscu na boot section (np. 64kB +4kB vs 128kB+8kB). Myślę, że to też jest jakiś argument

Cytat:Mnie interesuje koncepcja samego bootloadera. Czy jest to wersja mająca jakieś zabezpieczenia przed nieprawidłowym wgraniem firmware - np. suma kontrolna pliku? "BOOTLOADER DOS SD " to wersja obsługująca system plików FAT16?

polecam pobrać darmowego Bascoma lub kupić (wtedy będzie obsługiwał Xmega)

http://www.mcselec.com/ tam są różne działające przykłady na różne procesory
także na RS232 i na DOS-SD - duzo też jest na forum MCS sprawdzonych kodów - czasami trzeba tylko jakis przycisk przepiąć na inny PIN. MOżna zajrzeć do środka pliku i podejrzeć jak jest zrobione.

Cytat:Moim zdaniem ogólnie forma wgrywania nowego firmware za pomocą karty SD jest słuszna dla projektów zamkniętych - producent wypuszcza urządzenie i aby klient mógł sam sobie zaktualizować urządzenie, przesyła mu kartę SD. Oczywiście jest też inne podejście - producent chce maksymalnie odciążyć klienta i robi wszystko, aby aktualizacja odbywała się najprościej - bez udziału innego urządzenia (PC).

a dlaczego zamkniętych ??? - jeśli bootloader "łyka" czyste pliki BIN to jest to jak najbardziej przydatne do "otwartych" projektów. Ja takiego self-bootloadera DOS na kartę SD używam od jakoś dwóch lat w MAX6 a zabawy z kolorowym LCD w wolnych chwilach uskuteczniam od grudnia 2010.

Do zamkniętych projektów mogę użyć bootloadera zabezpieczonego szyfrowaniem AES128 i bliki BIN też generować szyfrowane... AES128....

Flaszowanie karta SD jedna z prostszych metod jakie znam. Wkładasz kartę do PC (WinXP Win7 ) lub do komórki .... i nagrywasz plik...

Cytat: Jednak gdy ktoś decyduję się na tak nowoczesną syntezę to czy nie będzie korzystał z CAT'a?

Bootloader to taki program uruchamiany przed programem właściwym żartem mówiąc coś jak BIOS w komputerze

...a kto powiedział że Bootloader nie może pracować przez RS232 i kartę SD jednocześnie (do wyboru) ??? właśnie takie rozwiązanie mam w MAX6 (ATMEGA128) - DUALNY bootloaer. Moge lądować program MCS bootloaderem przez RS232 wprost z BASCOMa ... albo karta SD - zależy jaki mam kaprys. :-) Bootloader możey być uruchamiany ręcznie (reset lub pozycja MENU ) ... automatycznie - komenda z RS232 lub linią RTS CTS itp...

Cytat:Poza tym nowoczesne karty SD mają duże pojemności i stwarza to problemy przy ich obsłudze. Mało tego, karty małej pojemności (atrakcyjniejsze z punktu widzenia programisty) stają się porównywalne cenowo z tymi o większej pojemności. Co gorsza karty o tej samej pojemności różnych producentów wcale (w tym akurat zastosowaniu) nie muszą być kompatybilne...Dlatego też, trzeba przeprowadzić testy z udziałem markowych i mniej znanych kart SD o różnych pojemnościach pamięci.

Czy te obawy wynikają z praktyki używania "DOS"-a na procusiach czy ze zwyczajnej ostrożności ? Do tej pory tylko jakieś dziwne chińskie karty nie zawsze dobrze pracowały....

Cytat:Na koniec - czy kolega może się podzielić tymi bootloaderami (ich kodem źródłowym) na forum?

Tego bootloadera nie będe umieszczał źródeł (ponieważ nie mogę gdyż źródła są w SAMPLES w kompilatorze) - dam sprawdzone i przetestowane HEX dedykowane pod odpowiednie piny i okablowanie tego procka.

By wejśc w posiadanie zestawu bootloaderów - na RS232 lub kartę SD wtsraczy pobrać i zanstalowac BASCOM AVR ( na dole strony) a dodatkowo sa pełne helpy po polsku do pobrania z WWW

Pamięci na program mamy Jeszce 128kb... dla procka XMEGA128A3 .... oby tylko to użyć :-)


Karta ma też inne zastosowania o których pisałem wcześniej.

(23-04-2012 11:45)SP9FKP napisał(a):  Sądzę, że nie medium a protokół decyduje o jakości komunikacji (oczywiście w uproszczeniu).

Tak masz rację... a dodatkowo BOOTLOADER to jest inny program w innym obszarze pamięci i może on pracować na jednym z dowolnych portów RS232 :-)


Ja przykładowo mam podłączony na RS232 BLUETOOTH i może pokusze sie o flaszowanie bazprzewodowe... na linku powyżej widać działanie bootloadera. Dodane jest zabezpieczenie przed przypadkowym flaszowaniem - trzeba trzymac PTT przez 5 sekund podczas resetu lub włączania procesora.

Do bootloadera dodałem "debugowanie" czyli informacje diagnostyczne wyrzucane przez RS232 ... ale może jak dodam programowanie przez RS232 to trzeba będzie okroić teksty...



robiłem tez hamskie testy z wyciąganiem karty w trakcie, resetowaniem w trakcie i wyłączaniem... ... startujemy jeszcze raz programowanie i wszystko gra :-)

Ja nikogo przecież nie zmuszę do używania tego typu flaszowania :-)

Jest jeszcze jedna zaleta... jak ktoś nie ma programatora PDI to kolega może mu podesłać wspawany na płytce procek z bootloaderem.

---

..... EDIT >>>

(23-04-2012 11:40)SP9MRN napisał(a):  ...
No tak, ale CAT nie zapewnia na tyle pełnej komunikacji, żeby robić update. ...

By zrobić automatyczne startowanie bootlodera z poziomu sterowania przez RS232 musimy do tego zaprząc jakąś własną "komendę" (lub sekwencję polecenie-odpowiedź-potwierdzenie) ale komenda musi byc taka że się nam ten ciąg znaków nie przytafi przykładowo w normalnym potoku znaków - bo inaczej radio nam się zrestartuje ... i do tego trzeba by napisać własny boot-załadowywacz na PC :-)


Bootloader to taki mały dedykowany program na końcu procesora który może dobić naprawdę dowolna rzecz :-) jest on uruchamiany w chyba czterech przypadkach
- przy włączeniu - jak na fusach jest ustawiony wektor resetu
- po wciśnieciu przyciska reset
- po zadziałaniu watchdoga
- po skoku bezpośrednim z programu na adres bootloader

obecnie karta SD wisi na tych samych kablach co czytnik ekranu dotykowego...

Dla leniwców można tak napisać bootloader (i program) że:
- włożenie karty + obecność pliku xxx.bin
uruchomi flaszowanie automatycznie - po czym plik zmieni nazwę na OLDxxx.bin

możliwości jest naprawdę dużo

Procesory Xmega są zasilane z napięcia 3,3V i programowane poprzez interfejs PDI. Stare, proste, ogólnodostępne programatory nie obsługują rodziny Xmega. Aby zaprogramować procesor do syntezy na ATXmega128 musimy nabyć nowy programator, poprosić o kogoś o pomoc lub skorzystać z bootloadera.

Wielu producentów udostępnia dedykowane bootloadery do swoich modułów np. Mikroelektronika lub środowisk programowania jak wspomniany przez Jarka Bascom firmy MCS.
Procesory Xmega mają kilka interfejsów szeregowych, SPI dostępnych na różnych portach dlatego każdy gotowy bootloader musi być przystosowany do konfiguracji posiadanego modułu.

Zaletą bootloadera pracującego poprzez kanał szeregowy jest jego bardzo mały kod możliwy do wgrania praktycznie na każdym procesorze z sekcją boot. Przy napisaniu bootloadera w assemlerze można go zmieścić w 256 komórkach word. Wadą takiego rozwiązania jest konieczność dostępu do komputera, może w przyszłości tabletu oraz dłuższy czas programowania.

Zaletą bootloadera pracującego poprzez odczyt karty SD jest pełna niezależność od komputera w czasie programowania. Tak czy inaczej plik jakoś trzeba pobrać z sieci i wgrać na kartę SD. Pewną wadą tej metody jest duży kod bootloadera. Bacomowa wersja na kartę SD dla Xmega wykonana przez Jarka wymaga procesora minimum Xmega128A3 ponieważ kod bootloadera jest większy niż 4kB i nie można go osadzić na mniejszych procesorach Xmega64.

Nie musimy obawiać się błędów przy wgrywaniu nowego softu ponieważ sekcja boot w procesorze jest chroniona przed zapisem i co najwyżej będziemy musieli ponownie powtórzyć wgrywanie nowego oprogramowania albo wrócić do starej wersji.

To czy aktualizacja oprogramowania potrwa kilka czy kilkanaście sekund dla zwykłego użytkownika nie ma najmniejszego znaczenia. Co innego dla programisty, który dokonuje kilkaset zmian w trakcie pisania programu. Ale ten zazwyczaj powinien mieć programator. Ja optuję za RS-232 z optoizolacją, który i tak będzie potrzebny np. do współpracy z programami logującymi.
Karta SD byłaby uzasadniona, gdyby trzeba było zbierać jakieś duże zestawy danych, co w przypadku sterownika transiwera raczej nam nie grozi.

Oczywiście nikt nikomu nie zabroni kupienia programatora PDI/SPI za 80 pln i programować procka wprost z komputera z AVRStudio.

Sam bylem zaskoczony że programowanie SD>procek trwa około 5 sekund dla kodu 128 kb ... ale należy pamiętać że zegar procka to 32 MHz a plik BIN idzie "na żywca" do pamięci procka bez zbędnego przeliczania ze sprzętowego SPI .... Nawet bardzo szybki programator PDI nie dorównuje temu bootloaderowi.

Jak ktoś chce protestować karty SD mam też programik do testowania szybkości operacji na karcie - napisany dla testowania "nowych"kart SDHC. ... ale wszystko w swoim czasie - niech najpierw płytka przejdzie pierwsze testy. Ja już swoje pierwsze uwagi sprzętowe zgłosiłem.

Dwie pierwsze dosyć banalne - Brak buzera i podświetlenie sterowane z procka (oszczędzanie energii i inne sprawy)

(23-04-2012 14:24)SP9FKP napisał(a):  Karta SD byłaby uzasadniona, gdyby trzeba było zbierać jakieś duże zestawy danych, co w przypadku sterownika transiwera raczej nam nie grozi.

zakładam że to czytałeś...
http://sp-hm.pl/thread-912-post-8577.html#pid8577

Nie mam zamiaru nikogo odwodzić od implementacji karty. Ale tak jak napisał Adam, po co robić dwa kroki skoro można jeden. Myślę ile trzeba kodu by zrobić proste operacje na plikach. Może przygotować hardware i oprogramować w kolejnych wersjach ?