Elektroda.pl
Elektroda.pl
X
TermoPasty.pl
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

uProg - mały, szybki, przenośny programator AVR z SD

manekinen 03 Lip 2011 22:37 123319 336
  • Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • TermoPasty.pl
  • #92 03 Lip 2011 23:19
    manekinen
    Poziom 29  

    tksk2 napisał:
    A może po wywołaniu write, read, weryfi, i w tym samym oknie "delete" i po wyciśnięciu rozwinie się lista plików?,a potem wybór i "ok."

    Hmm jako że byłaby to opcja dodatkowa (raczej taka awaryjna), to myślę że wystarczy jeśli wywoła się ją poprzez przyciśnięcie dwóch przycisków na raz (np środkowych) - no i potwierdzenie przyciskiem ok.

    J_Bravo napisał:
    A jak idą prace z automatycznym ustawieniem fusów po programowaniu procesora?? Będzie taka możliwość?

    Na razie nie miałem kiedy, ale jeśli da się to w prosty sposób zrobić to oczywiście, czemu nie :)

    leonow32 napisał:
    Można by zrobić opcję do automatycznego ustawiania fusebitów przed programowaniem - chodzi o to, że jak jest na płytce kwarc 16MHz to niech się proces programuje korzystając z zegara kwarcowego a nie z wewnętrznego generatora 1MHz.

    Hmm już nad tym myślałem, ale trzeba by dla każdego jednego procka przechowywać dodatkowo ustawienie fusebitów dla zewnętrznego 16MHz. No i później wracać do pierwotnego ustawienia. Więc doszedłem do wniosku że jeśli ktoś ma duuuży wsad do wgrania to może sobie przygotować dwa pliki fusków TXT i ręcznie zmienić taktowanie przed programowaniem :)

  • #93 03 Lip 2011 23:50
    mlassota
    Poziom 18  

    leonow32 napisał:
    Można by zrobić opcję do automatycznego ustawiania fusebitów przed programowaniem - chodzi o to, że jak jest na płytce kwarc 16MHz to niech się proces programuje korzystając z zegara kwarcowego a nie z wewnętrznego generatora 1MHz.


    Pytanie jeszcze jak to zrobić?
    Jak stwierdzić czy na płytce jest kwarc? Jak się przestawi a nie będzie to... trzeba będzie podpinać...

    Procedura mogłaby wyglądać tak:
    Odczyt fusebitów
    Jeśli mniejszy niż 8MHz - zmiana na 8MHz - wewnętrzny
    Programowanie
    Powrót do uprzednio odczytanych

    Szczerze nie bardzo widzę taką potrzebę... W końcu nawet przy 62,5kHż programowanie nie trawa wieczności...


    Jeszcze jedna rada dla osób skałdających

    Idealnie (prawie) do przytrzymywania wyświetlacza nadaje opakowanie na elementy w obudowach SSOP. Trzeba wyciąć wklęsłą cześć z zapasem ok 1mm.
    Łatwo można to wykonać... Polecam

    To opakowanie wygląda tak
    uProg - mały, szybki, przenośny programator AVR z SD

    a zamocowany wyśletlacz - tak:
    uProg - mały, szybki, przenośny programator AVR z SD

  • TermoPasty.pl
  • #94 04 Lip 2011 06:27
    J_Bravo
    Poziom 27  

    manekinen napisał:
    Na razie nie miałem kiedy, ale jeśli da się to w prosty sposób zrobić to oczywiście, czemu nie Smile

    Wystarczyło by żeby na karcie był plik txt (albo bascomowy prg) z ustawieniami o takiej samej nazwie co plik in/hex i programator automatycznie programował by fusy.
    Taka opcja przydał by się osobom które często programują czyste procki.

  • #95 04 Lip 2011 10:17
    piotrva
    Moderator na urlopie...

    mlassota, pomysł ciekawy na montaż, tym bardziej dla mnie, bo mam trochę tych opakowań. Ja osobiście będę kombinował coś z wykorzystaniem oryginalnej ramki, jak przyjdzie mi płateczka i części.
    Co do programowania fusebitów to przecież mamy opcję wgrywania takowych z pliku, więc... Moim zdaniem wystarczyłoby gdyby np. stwierdzenie takiej samej nazwy pliku z programem i fusami powodowało (o ile będzie załączona stosowna opcja w ustawieniach) wgranie przed programowaniem właśnie tych fusów.
    Co do stwierdzania obecności kwarcu to tego zrobić się nie da - trzeba założyć, że takowego nie ma...

  • #96 04 Lip 2011 13:12
    J_Bravo
    Poziom 27  

    Jeśli chodzi o Lockbity (czy jak to się nazywa) to chyba lepiej po programowaniu.

  • #98 06 Lip 2011 15:40
    piotrva
    Moderator na urlopie...

    Zmontowałem wczoraj uProg'a i miałem spore problemy z uruchomieniem, gdyż nie wlutowałem żadnego kondensatora jako C5 (przy karcie SD). Po różnych próbach wlutowałem tam kondensator 22uF THT (wystaje "nieco" poza LCD) i ruszyło od razu. Cały czas programator zasilany był napięciem 3,4V z lm317. Teraz będę testować i później planuję dodać prosty system zasilania z układu programowanego, na razie mi się nie udało tego zrobić, gdyż diody zennera które powinny być na 3,3V dają napięcie 2,4V - nie wiem czemu...

  • #99 06 Lip 2011 15:50
    manekinen
    Poziom 29  

    Zgadza się. Ale i kondensator 10uF może być za mały - dla tego pisałem o tym w opisie, żeby dać możliwie duży. Jak widać karta potrzebuje sporego chwilowego prądu przy inicjacji, trzy piny mikrokontrolera nie koniecznie dadzą radę - bo na nich występuje dodatkowy spadek napięcia.

    Także jeśli ktoś widzi napis "SD ERROR" to proponuję zacząć od właśnie tego kondensatora :) Jeśli nie, no to można sprawdzić na innej karcie, można sprawdzić jakość lutów gniazda karty, czy jego styki nie są np ubrudzone topnikiem. I wszystko powinno ładnie ruszyć :) No i upewnić się jak jest sformatowana karta albo najlepiej zrobić format przed uruchamianiem.


    //dodano


    piotrva znalazł błąd, kiedy plik HEX nie zaczyna się od adresu 0 (np bootloader) to programator źle oblicza adres końcowy i po dojściu do końca nie kończy programowania, ale wysyła dane gdzieś w kosmos i się zawiesza/zapętla. Pracuję nad poprawką :)

  • #100 07 Lip 2011 14:20
    piotrva
    Moderator na urlopie...

    Dorobiłem jeszcze do swojej wersji taką modyfikację: Na złączu ISP na linii CLKO/VCC przed rezystorem 1K dałem wyprowadzenie, które zworką można podpiąć do:
    a) stabilizatora L1117-3.3C, który daje napięcie 3,3V do zasilania układu
    b) bezpośrednio na zasilanie układu (jeśli układ programowany też chodzi na 3,3V)
    Wkrótce postaram się zamieścić fotki tej modyfikacji w stylu na pająka i może schemacik.

  • #101 07 Lip 2011 20:54
    manekinen
    Poziom 29  

    narasta kilka stron temu napisał:
    Jeśli chodzi o ręczne ustawianie FuseBitów to wydaje mi się że najlepiej było by je wprowadzać w hexie znak po znaku, czyli najpierw wybiera się pierwszy znak (dwa przyciski góra dół) i potem kolejny i mamy już całego fuse'a


    Program sprawdza podłączony procesor, i do edycji pobiera fabryczne fuski (nie te które są zapisane w procku).

    Zrobiłem tak jak opisałeś, wydaje się że jest to wygodne. Przyciskami góra i dół przewijamy pierwszy znak pierwszego fuska. Wciskamy OK, i przechodzimy do edycji następnego znaku tego fuska. Znów OK, i przechodzimy do pierwszego znaku kolejnego fuska. I w ten sposób aż do końca, na końcu jest zapis oraz odczyt - w ostatniej linii pojawiają się odczytane fuski.

    I jak? :)

    Z tej opcji trzeba korzystać bardzo ostrożnie. Czemu - chyba każdy wie.

  • #102 08 Lip 2011 09:51
    piotrva
    Moderator na urlopie...

    Zgodnie z obietnicami zdjęcia:
    uProg - mały, szybki, przenośny programator AVR z SD uProg - mały, szybki, przenośny programator AVR z SD
    W załączniku schemat mojej modyfikacji.
    Zworka/złącze SV1 może pełnić następujące funkcje:
    1. Wybór zasilania poprzez stabilizator LDO L1117-3.3 ze złącza ISP - CLKO(VCC), niepodłączony pin to wtedy wyjście zasilania 3V3, można połączyć np. z regulatorem napięcia w programatorze.
    2. Wybór zasilania bezpośredniego - pin złącza ISP - CLKO(VCC) podłączony bezpośrednio do zasilania 3V3 na płytce - funkcja przydatna, gdy ukłąd docelowy jest zasilany napięciem 3v3 - stabilizator LDO powodowałby wtedy zbyt duży spadek napięcia
    3. Zworka zdjęta - pin CLKO działa jako wyjście sygnału zegarowego, należy wtedy podpiąć pod odpowiedni pin złącza zasilanie z układu zewnętrznego/baterii

  • #103 08 Lip 2011 15:01
    chemik_16
    Poziom 24  

    Świetny projekt :)
    Jako że na płytce jest sporo wolnego miejsca - proponowałbym wcisnąć tam MAX1811 - ładowarke baterii li-ion - wymaga tylko 2 zewnętrznych kondensatorów - sygnalizacje ładowania można dać na wejście procka o ile jakieś sie jeszcze ostało.
    Układ jest dostępny jako sample, bardzo już popularny ;p
    w ten sposób odpada nam kwestia ładowania baterii.

    edit: oczywiście jako element opcjonalny calej konstrukcji - jak już zamawiać większą ilość płytek to warto by była możliwa pewna rozbudowa :)

  • #104 08 Lip 2011 17:19
    manekinen
    Poziom 29  

    piotrva - dzięki za fotki, ten stabilizator to jakby stamtąd był :)

    chemik_16 - tak, jeśli będę zamawiał kolejną partię płytek to umieszczę jakieś opcjonalne pady na stabilizatory czy regulatory, tak żeby można było wlutować wg własnego widzi-mi-się. Koszt ten sam a możliwości rosną :)

    No więc tak, ręczne ustawianie fusków działa fajnie. Dodałem usuwanie plików tak jak prosiliście. Dodałem nowe ustawienia do pliku konfiguracyjnego, usunąłem ten błąd z bootloaderami w plikach HEX, i poprawiłem parę innych rzeczy.

    Obecnie pracuję nad poprawną obsługą układów atmega2560 i atmega2561, nie jest to proste, tym bardziej że nie mam takich układów a mój drugi beta tester nie ma zbyt dużo czasu na testowanie... Więc aktualizacja softu do 1.3 będzie dopiero gdy się z tym uporamy :) Jeśli ktoś ma możliwość (i chęci) potestować - zapraszam na pw :)

  • #105 09 Lip 2011 05:40
    krzycho123
    Poziom 31  

    Akurat te uP są mało popularne ze względu na cenę ~50zł/sz i napewno ta funkcjonalność nie zostanie zbyt wykorzystana przez użytkowników ;)

    Ja spotkałem ten uP tylko o najmocniejszej odmianie arduino a tam isp jest zbędny bo jest USB i bootloader.

    Ja osobiście widziałbym jeszcze drugą opcję do ustawiania fusebitów z zaznaczaniem poszczególnych - opis każdego na ekranie .
    Żeby wpisywać wartość HEX trzeba używać kalkulatora na PC a tak było by dodatkowo łatwiej.

  • #106 09 Lip 2011 15:16
    manekinen
    Poziom 29  

    Jasne że łatwiej, ale chyba nie zdajesz sobie sprawy ile trzeba byłoby doskrobać kodu żeby takie coś zrobić. Praktycznie każdy jeden µkontroler inaczej rozmieszczone fuski lub pełnią inną funkcję - dla każdego trzeba by zrobić osobne opisy itd. Jasne, można do tego wykorzystać kartę pamięci, ale to za dużo pracy niestety.

    Ręczne ustawianie fusków zajęło tylko 300 bajtów (bo jest super-proste), wersja z opisami... nawet boję się myśleć :)

    Atmegę2560 będę miał we wtorek-środę więc jakoś wtedy będzie aktualizacja :)

  • #107 09 Lip 2011 16:33
    krzycho123
    Poziom 31  

    Wiem wiem że to masa roboty z tym ale całość mogła by być ładowana w zależności od wybranego proca z karty :)

    Chodziło mi raczej o prosty opis i możliwoćś przełączania 1-0 przy każdym , taki dodatkowy ficzer w tak doskonałym już sprzęcie jakbyś chciał go dalej rozwijać :)

  • #108 09 Lip 2011 16:38
    manekinen
    Poziom 29  

    Nawet gdyby ktoś się zajął opisami i przygotował plik zawierający opisy dla każdego układu (uwierz, masa roboty, wiem co mówię bo wyciągałem z każdego datasheeta dane takie jak fuski, wielkość pamięci, czy typ programowania) to i tak czarno widzę upchanie takiej opcji do pamięci. Jak na tak mały procesor, oferuje on już bardzo dużo funkcji. W przyszłości usunę bootloader i w jego miejscę zrobię programowanie Xmega z interfejsem PDI, czy zostanie miejsce - wątpię.

    Krzycho lepiej pokaż jak ci wyszła płytka bo jestem ciekaw :)

  • #109 09 Lip 2011 18:12
    tmf
    Moderator Mikrokontrolery Projektowanie

    A nie myślałeś, żeby zamiast karty SD wsadzić pamięć dataflash i dodać obsługę USB? IMHO, parę GB jest mi do niczego niepotrzebne, bo sensowną ilość wsadów da się umieścić w paru MB, natomiast dosyć uciążliwe jest przegrywanie hexów na SD, a potem wkładanie karty do programatora. Tak wystarczyłoby ją podłączyć i po prostu przegrać. Gdyby jeszcze była widziana w kompie jako USB Mass Storage to byłaby bajka. Zauważ, że takie rozwiązanie (podłączenie przez USB) ma jeszcze jedną zaletę - ten programator można by wykorzystać jako zwykły programator ISP sterowany np. z AVR Dude oraz jako niezależny programator w terenie.
    Drugi pomysł - dla hexów zawartość FLASH, EEPROM i fusy muszą być osobno. Z kolei struktura elf jest zbyt skomplikowana, aby je obsłużyć w mikrokontrolerze, ale można wszystkie HEXy skleić razem, przyjmując np. że FLASH zaczyna się od adresu 0x0000, EEPROM od 0x100000, fusy od 0x200000. Wtedy jest tylko jeden plik zawierający wszystko. Taki plik łatwo wygenerować modyfikując nieco makefile z wykorzystaniem narzędzia objcopy.

  • #110 09 Lip 2011 18:22
    krzycho123
    Poziom 31  

    manekinen właśnie miałem wrzucić , bo dzięki Twojej pomocy udało się rozwiązać problem.

    Miałem własne płytki , po długich poszukiwaniach sprawcy problemu okazało się że 10uF kondensator jest zbyt mały do uruchomienia moich kart mSD. Spadek napięcia był taki że dopiero zastosowanie 2x 10uF pozwoliło na prawidłową inicjalizację karty.
    Udało się odpalić dopiero na PCB od autora konstrukcji.

    Oczywisćie bardzo dziękuje manekinen za pomoc :D

    PS> niestety klej o którym pisałem choć był do ceramiki puścił po 2dniach od szkła

    uProg - mały, szybki, przenośny programator AVR z SD

  • #111 10 Lip 2011 13:30
    manekinen
    Poziom 29  

    tmf napisał:
    A nie myślałeś, żeby zamiast karty SD wsadzić pamięć dataflash i dodać obsługę USB? IMHO, parę GB jest mi do niczego niepotrzebne, bo sensowną ilość wsadów da się umieścić w paru MB, natomiast dosyć uciążliwe jest przegrywanie hexów na SD, a potem wkładanie karty do programatora. Tak wystarczyłoby ją podłączyć i po prostu przegrać. Gdyby jeszcze była widziana w kompie jako USB Mass Storage to byłaby bajka. Zauważ, że takie rozwiązanie (podłączenie przez USB) ma jeszcze jedną zaletę - ten programator można by wykorzystać jako zwykły programator ISP sterowany np. z AVR Dude oraz jako niezależny programator w terenie.


    Takie rzeczy to nie w bascomie ;) I nie na takim małym procku. Ale pomysł świetny, zamiast pamięci flash zostawić poczciwa kartę µSD - i urządzenie mogło by z nią pracować jako dysk przenośny. Opcją w menu lub przytrzymaniem przycisku wybieramy czy urządzenie się zgłasza jako dysk - czy jako programator. Jeśli to drugie, to na wyświetlaczu pokazują się także szczegóły programowania ale jest to robione z komputera. I żeby jeszcze obsługiwał PDI i TPI. Pomarzyć można :)

    Ewentualnie dodać usb dla karty µSD tak jak Kolega kombinuje TUTAJ

    tmf napisał:
    Drugi pomysł - dla hexów zawartość FLASH, EEPROM i fusy muszą być osobno. Z kolei struktura elf jest zbyt skomplikowana, aby je obsłużyć w mikrokontrolerze, ale można wszystkie HEXy skleić razem, przyjmując np. że FLASH zaczyna się od adresu 0x0000, EEPROM od 0x100000, fusy od 0x200000. Wtedy jest tylko jeden plik zawierający wszystko. Taki plik łatwo wygenerować modyfikując nieco makefile z wykorzystaniem narzędzia objcopy.

    No z tym "grupowym" programowaniem jeszcze będę coś myślał, muszę sprawdzić jakie pliki fusków generują winavr i bascom - jakie są róznice. Choć wgrywanie ich (wsadów dla flasha, eepromu, i fusków) do różnych katalogów może być uciążliwe i można będzie się pomylić. O ile taki wspólny plik winavr wygeneruje, to bascom nie. Bo nawet plik ELF można ugryźć - czemu nie. Skoro obsługuję hexy z rozszerzonym adresowaniem i liczeniem sum kontrolnych - a różne kompilatory potrafią różnie te hexy tworzyć i trzeba być przygotowanym na jakieś niespodziewane wpisy itd :)

    I właśnie osoby testujące programator zgłaszały mi ciągle jakieś błędy z plikami hex, i co do takiego pliku nie zajrzałem, to nieco inaczej zbudowany był czy miał własnie dodatkowe wpisy, np typu "03" czy "05", lub też wpisy typu "02" czy "05" oznaczające rozszerzone adresowanie, umieszczone na samym końcu pliku - moim zdaniem nie potrzebnie bo po co rozpoczynać kolejny 64kB blok danych skoro dalej danych nie ma, jest tylko koniec pliku czyli "01". Doszło więc sporo dodatkowych warunków, porównywania adresów, nie dość że program się powiększył to i działać będzie nieco wolniej - no niestety :(

    krzycho123 napisał:
    niestety klej o którym pisałem choć był do ceramiki puścił po 2dniach od szkła

    A może masz opakowania od układów, tzw "laski", takie jak TUTAJ - ta gumka recepturka nie wygląda dobrze, na pewno przy wyjmowaniu karty lub podłączaniu ISP wyświetlacz Ci się przesuwa na boki i traci kontakt.

    Dobrym rozwiązaniem będzie też wziąć 4 malutkie miedziane blaszki, wygiąć w uchwyty, i zwyczajnie przylutować do pola masy na płytce, tak aby trzymały wyświetlacz po bokach - w ten sposób wyświetlacz będzie można wysunąć do góry aby dostać się do elektroniki, a same uchwyty powinny solidnie go trzymać :)

    No to się rozpisałem... :)

  • #112 10 Lip 2011 14:00
    krzycho123
    Poziom 31  

    manekinen gumka tylko do foto była żeby nie było że nie działa :D , jak tylko kupię nowy Poxipol to przykleje całość porządnie bo akurat mam resztkę .

    Z "laską" od sampli próbowałem , niestety taka od układów SO8 nie sprawdziła się bo trzeba by podłożyć pod spód coś a blaszek nie chcę bo łatwo ukruszyć szkło - kiedyś rozwaliłem wyświetlacz od 6210 właśnie przez źle dopasowaną blaszkę.

    Co do USB , dla mnie zbędne jest . Nano czytnik Kingston FCR-MRG2 kosztuje koło 6-7zł :)

  • #113 10 Lip 2011 14:02
    tmf
    Moderator Mikrokontrolery Projektowanie

    No w Bascomie to pomarzyć można, ale jakbyś chciał przejść na C to chętnie ci pomogę i jakieś fragmenty mogę ci przeportować, np. menu, programowanie, itd.
    Co do USB to prosto to zrobić np. na ATMega z serii U2, które posiadają sprzętowego device USB, do tego są gotowce typu mass storage. Albo z tego zrezygnować i wrzucić poczciwego FTDI. Koszty niewielkie, a taki programator byłby naprawdę świetny. Nic nie trzeba także przełączać, bo urządzenie USB może jednocześnie zgłaszać się jako kilka klas.
    Co do hexów to sklejanie jest proste, nawet zwykłe połączenie dwóch plików zadziała, gorzej z fusami. Natomiast jeśli myślisz nad obsługą elf to naprawdę porywasz się z motyką na słońce. libelf to kilkanaście kB kodu źródłowego. Natomiast jeśli chcesz mogę ci podrzucić moją implementację obsługi HEX (co prawda na PC ale bez problemów da się to przenieść na AVR).

  • #114 10 Lip 2011 14:06
    kaeltaz
    Poziom 16  

    manekinen napisał:
    Takie rzeczy to nie w bascomie :wink: I nie na takim małym procku. Ale pomysł świetny, zamiast pamięci flash zostawić poczciwa kartę µSD - i urządzenie mogło by z nią pracować jako dysk przenośny. Opcją w menu lub przytrzymaniem przycisku wybieramy czy urządzenie się zgłasza jako dysk - czy jako programator. Jeśli to drugie, to na wyświetlaczu pokazują się także szczegóły programowania ale jest to robione z komputera. I żeby jeszcze obsługiwał PDI i TPI. Pomarzyć można :)


    Jeśli mało pamięci zawsze można zatrudnić atmege128. :-)

  • #115 10 Lip 2011 14:34
    manekinen
    Poziom 29  

    tmf napisał:
    No w Bascomie to pomarzyć można, ale jakbyś chciał przejść na C to chętnie ci pomogę i jakieś fragmenty mogę ci przeportować, np. menu, programowanie, itd.
    Co do USB to prosto to zrobić np. na ATMega z serii U2, które posiadają sprzętowego device USB, do tego są gotowce typu mass storage. Albo z tego zrezygnować i wrzucić poczciwego FTDI. Koszty niewielkie, a taki programator byłby naprawdę świetny. Nic nie trzeba także przełączać, bo urządzenie USB może jednocześnie zgłaszać się jako kilka klas.

    Gdyby kiedyś natchnęło mnie na C - to jasne, dzięki, skorzystam :) Ewentualnie gdybyś może chciał sam taki programator stworzyć, ja pomogę w tym całym ISP, bo z tego co widać po poprawkach - wcale nie jest takie proste jak się na początku mi wydawało :)

    tmf napisał:
    Co do hexów to sklejanie jest proste, nawet zwykłe połączenie dwóch plików zadziała, gorzej z fusami. Natomiast jeśli myślisz nad obsługą elf to naprawdę porywasz się z motyką na słońce. libelf to kilkanaście kB kodu źródłowego.

    Tak, po wpisie "koniec pliku" wystarczy sprawdzić czy znajdują się jakieś dane i tyle - można je nadal normalnie adresować, np dla eeprom czy nawet dla fusków. adres 0, długość danych 3 bajty, no i 3 bajty z sumą kontrolną. To może być nawet niegłupie rozwiązanie :) Co do ELF, bez bicia przyznam się że nawet nie zaglądałem, ale jeśli tak piszesz to od razu się poddaję :)

    tmf napisał:
    Natomiast jeśli chcesz mogę ci podrzucić moją implementację obsługi HEX (co prawda na PC ale bez problemów da się to przenieść na AVR)

    Dzięki, ale sądzę że już nie będzie problemów. Po prostu zmienna z adresem jest typu word, i trzeba dobrze pilnować żeby się "nie przekręciła" przy zapisie/odczycie ostatniego bajtu z hexa - w różnych warunkach.

    A przy okazji, zapytam, może masz jakiś sposób na liczenie ilości danych w pliku HEX? Ja liczę je przed zapisem żeby stwierdzić czy wybraliśmy dobry plik - jeśli jest większy od pamięci podłączonego procka to programator zwraca stosowną informację.

    Obecnie mam to tak zrobione, że programator leci przez plik HEX w poszukiwaniu dwukropków. Jeśli natrafi na wpis rozszerzonego adresowania to dodaje FFFF do adresu. Jeśli natrafi na koniec pliku to pobiera z poprzedniej linii właśnie adres i ilość bajtów, dodaje adres uzyskany z wpisów o rozszerzonym adresowaniu do adresu z poprzedniej linii, i do tego dodaje ilość bajtów ostatniej linii. I w ten sposób znany jest adres końca danych. Niestety musi lecieć przez calutki plik, i jeśli plik ma np 500kB to trochę to trwa.

    Miałem taki pomysł żeby po prostu sprawdzić długość pliku (po otwarciu w avrdos taka informacja jest od razu dostępna), odjąć np 100 bajtów od tej długości, i zacząć od tego miejsca sprawdzanie pliku. Program trafi na ostatnią i przedostatnią linię, doda ostatni adres i ilość bajtów ostatniej linii - i będzie adres końcowy. Sposób prawie że błyskawiczny - ale z jedną wadą. Program ominie w ten sposób wszystkie wpisy z rozszerzonym adresowaniem. Mam nadzieję że nie namieszałem zbytnio :)

    kaeltaz napisał:
    Jeśli mało pamięci zawsze można zatrudnić atmege128

    Tak, i nie dość że na płytkę nie wejdzie to koszt rośnie w kosmos :) Atmega644 już mniejsza ale jeszcze za duża. Chyba że są jeszcze jakieś procki w TQFP32 z większą pamięcią?

  • #116 10 Lip 2011 14:55
    tmf
    Moderator Mikrokontrolery Projektowanie

    Niestety, jeśli chcesz dokładny rozmiar danych w hex to musisz cały przelecieć. Z drugiej strony i tak musisz, bo co z tego, że ilość danych mieści się w pamięci, skoro są one adresowane poza zakresem adresów dla danego typu procesora. Trzeba więc sprawdzić wszystkie rekordy. Przy okazji można także sprawdzić czy sam hex jest poprawny, przez wstępne jego sparsowanie i sprawdzenie, czy CRC rekordów się zgadza.

  • #117 10 Lip 2011 15:10
    kaeltaz
    Poziom 16  

    No niby zawsze można zrobić kanapkę z pcb i wrzucić większą atmege.

  • #118 11 Lip 2011 13:14
    manekinen
    Poziom 29  

    tmf napisał:
    Z drugiej strony i tak musisz, bo co z tego, że ilość danych mieści się w pamięci, skoro są one adresowane poza zakresem adresów dla danego typu procesora. Trzeba więc sprawdzić wszystkie rekordy.

    Tzn nie sprawdzam wszystkich rekordów. Nie zakładam aż tak strasznej sytuacji że plik hex będzie adresowany w taki sposób że najpierw będą starsze adresy a potem gdzieś młodsze/wcześniejsze - choć jest to możliwe ale nie wiem czy gdzieś wykorzystywane?

    Ok mój opis był nieźle zakręcony więc może pokażę na fragmencie pliku jak pobieram końcowy adres, tzn adres ostatniego bajtu - a znając go wiem czy wsad się zmieści:
    uProg - mały, szybki, przenośny programator AVR z SD
    Punktem odniesienia dla pobieranych danych są dwukropki, które niestety mi sie ucięły przy szybkiej obróbce zdjęcia.

    W ten sposób plik może się zaczynać od dowolnego miejsca, np bootloader. A ja znam adres gdzie się kończy - więcej mi nie potrzeba. Podczas zapisu do pamięci wgrywam tylko dane które istnieją, podczas zapisu programator pobiera adres rekordu, ilość bajtów, i pobiera kolejno bajty aż licznik ilości bajtów = ilości bajtów rekordu. Potem szuka kolejnego dwukropka i w ten sposób leci aż adres = adres ostatniego bajtu (przy zapisie nie patrzę na dodatkowe rekordy końca danych czy rozszerzonego adresowania, po prostu je omijam). No bo po co znów je czytać.

    Nie wiem czy to jest zrobione profesjonalnie, czy nie, ale działa to dobrze. Chyba że znów natrafię na jakieś kwiatki w plikach hex to będzie trzeba poprawić :)

    tmf napisał:
    Przy okazji można także sprawdzić czy sam hex jest poprawny, przez wstępne jego sparsowanie i sprawdzenie, czy CRC rekordów się zgadza.

    No tak można, bo i tak czytam z pliku każdy jeden znak. Dopiszę to do listy, pewnie kiedyś będzie dodane :)

  • #119 11 Lip 2011 16:38
    tmf
    Moderator Mikrokontrolery Projektowanie

    Wydaje mi się, że nieprawidłowo liczysz adresy. Zauważ, że rekordy 02-05 zawierają różnie zapisany adres, który powinieneś odczytywać, a nie zakładać, że przestrzeń adresowana jest liniowo. To ma znaczenie w kodzie, gdzie przesuwasz segmenty, albo tworzysz własne segmenty w pamięci (w BASCOMie tego chyba nie ma, więc możesz się z tym problemem nie spotkać). Np. jeśli jakaś zmienna ma być w konkretnym miejscu pamięci FLASH, to w hex masz rekord przed którym i po którym jest "dziura" w adresacji. Nieco wydumany problem, ale realny to sklejanie dwóch hexów. Np. mam hex z bootloaderem i kodem aplikacji i chcę otrzymać hex wynikowy. Wtedy dodatkowo kolejność adresacji wcale nie musi być wzrastająca.

  • #120 11 Lip 2011 16:58
    piotrva
    Moderator na urlopie...

    No właśnie stąd były m.in. problemy z moimi bootloaderami, które szczerze mówiąc przypadkowo wybrałem do testów, ale problem jest rzeczywiście bardziej złożony niż tylko bootloadery.