logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[atmega8][avr] Dodatkowa pamięc programu w uC

y0yster 07 Sie 2009 11:23 7465 27
  • #1 6866283
    y0yster
    Poziom 19  
    Witam,

    Zastanawiałem się jaki jest sposób na rozszerzenie pamięci programu dla mikrokontrolerów z rodziny AtMega.
    Czy można rozszerzyć pamięć programu? Wiem, że w prockach z rodziny 51 można było ją rozszerzyć, ale dla np. Atmega8 nic konkretnego nie znalazłem.
    Atmega8 ma także bootload'er, który daje możliwość modyfikacji kodu. Oczywiście można go odczytywać z karty pamięci lub czegoś podobnego, ale pozostaje problem ciągłego nadpisywania pamięci bezpośrednio w uC. Takie coś może skutkować przedwczesnym zużyciem się flash'u i błędami z tym związanymi.

    Dla np. Atmega128 istnieje możliwość podłączenie dodatkowego ram'u, ale czy można także do niej podłączyć pamięć programu taką jak flash?

    Pozdrawiam.
  • #3 6866367
    Jacek31
    Warunkowo odblokowany
    Ostatecznie możesz przejść na ATMEGA168 który jest właściwie ATMEGĄ8 z rozszerzoną pamięcią programu do 16KB. To jedyne wyjście jeżeli nie możesz użyć CPU w innej obudowie a potrzebujesz więcej pamięci programu.
    Natomiast nie przejmowałbym się zbytnio ilością cykli programowania. producent gwarantuje 100 000 cykli kasowana/zapisu, a to wystarczająco sporo. Nawet gdybyś kasował proca i programował 10 razy dziennie to daje ci to 10 000dni czyli 27 lat, bezawaryjnej pracy.
  • #4 6866373
    y0yster
    Poziom 19  
    Użyć innej obudowy mogę. Chodzi mi o podobne możliwości i koniecznie z rozszerzeniem pamięci programu.
    Może jakieś dalsze propozycje, nie musi być to koniecznie atmel.
  • #5 6866388
    Jacek31
    Warunkowo odblokowany
    W takim razie tylko rodzina 8051 np. AT89S8252. programowany przez SPI tak jak AVRy. 8KB flash, 256B IRAM, w miarę rozbudowany jak na standardową 51 można podłączyć zewnętrzny RAM z którego da się uruchamiać programy.
    Jest jeszcze AT89S8253, który zamiast 8KB flash ma ich 12KB, reszta ta sama. Natomiast nie są to funkcjonalnie odpowiedniki ATMEGI 8, nie mają przetwornika A/C i Timery są biedniejsze. Ostatecznie najbardziej rozbudowana 51 czyli 80552, ci pozostaje.
    AVRy żadne nie potrafią wykonywać programu z zewnętrznej pamięci bo są 16-bitowymi rdzeniami tak defakto, no może poza XMEGA, ale to już lepiej zainwestować w ARMy. Ale koszty takiego komputerka i tak będą spore.
    http://www.atmel.com/dyn/resources/prod_documents/doc4136.pdf
    Najbardziej rozbudowana 51 dostępna w TME (za ok 30zł), która jest w stanie konkurować z Mega8 (i nie tylko). Jest jeszcze wersja w obudowie PLCC52 do której można dołożyć zewnętrzną pamięć, ale nie wiem czy ją się da kupić??
    No i znajomość asemblera 51, mile widziana, bo BASCOM na pewno tego nie wspiera.:D
  • #6 6866444
    y0yster
    Poziom 19  
    A coś jeszcze innego, może jakieś PIC'e, albo jeszcze coś innego co ma podobne możliwości, wyżej wymienionego przez mnie procka.

    Szukałem także na necie jakiegoś zestawienia pod tym kontem, ale niestety nie udało mi się nic takiego znaleźć.

    Pozdrawiam.

    Też dodam jeszcze coś. :)

    Co do bascom'a to nie ma problemu. Ja piszę w C, a jak w assemblerze coś trzeba będzie napisać to też się napisze. Takie były początki :P
  • #7 6866456
    Jacek31
    Warunkowo odblokowany
    PICy raczej pod tym względem nie bardzo sie różnią od AVR. To znaczy zewnętrzna pamięć programu. Choć dzisiaj taką cechę posiadają tylko najmocniejsze procesory, i to głównie 32-bitowe, co od razu idzie w koszty, i skomplikowane PCB. Z tanich rozwiązań to wydaje mi się tylko 51 zostaje, tylko trzeba dobrze poszukać.
  • #8 6866457
    y0yster
    Poziom 19  
    To może z innej beczki. Jak można sobie poradzić z małą ilością dostępnej pamięci programu.

    Oprócz owego bootloader'a i łączeniem kilku uC ?
  • #9 6866535
    Jacek31
    Warunkowo odblokowany
    Optymalizacja kodu, ostatecznie knif z interpretatorem języka BASIC. Ale to i tak wymaga proca który ma min 8KB FLAsh a dobrze jak by miał 16KB (wtedy można wstawić bardziej konkretny interpreter BASIC), no i z 1KB RAM. W procku jest program interpretatora BASIC, który pobiera kod programu z zewnętrznej pamięci (dowolnej) np. 24c512 i go wykonuje. To jedyne wyjście, jak optymalizacja zawodzi. takie projekty (interpretatory) są na pewno na 51 i na AVRy też powinny być.
    To cię może zaiteresuje:
    http://pl.wikipedia.org/wiki/BASIC_Stamp
    oraz coś więcej i konkretnie:
    http://www.colinfahey.com/basic_stamp_computer/basic_stamp_computer_pl.html
    http://riad.usk.pk.edu.pl/~mlankosz/uc/uc_inst01.pdf
    Natomiast czasami warto zwrócić moim zdaniem uwagę na stare już dziś zapomniane książki o programowaniu jeszcze z komputerów C64, ZX Spectrum czy kontrolerów 8048. Tam przecież programiści musieli się naprawdę gibać bo mieli bardzo mało zasobów i mocy obliczeniowej, a tworzyli istne cuda. Często odpowiedzi są w właśnie takiej zapomnianej literaturze. Ja osobiście zbieram takie książki, jak się da, to istna skarbnica bezcennej wiedzy. Co prawda przenoszenie czasem tego na nowsze proce jest pracochłonne, ale warto, doświadczenie się przydaje a kody z tamtych czasów są bardzo dobrze zoptymalizowane jeżeli chodzi o ilośc pamięci programu i danych jaką wykorzystują.
  • #10 6866638
    mirekk36
    Poziom 42  
    tak sobie czytam i patrzę, że na upartego próbujesz wydrążyć temat jeśli chodzi o problem, którego podejrzewam tak na prawdę nie ma - tylko ty nie jesteś może do końca świadomy tego ? ;)

    .... jak sam wspomniałes i któryś kolega wcześniej, to odpalanie programu z pamięci RAM albo EPROM to rodzina '51 - ale jak było powiedziane nieco biedniejsza jeśli chodzi o procki w podobnych cenach do ATmega

    .... z drugiej strony powiedz może co najbardziej cię nurtuje - jaka potrzeba wymusza na tobie poszukiwanie takiego rozwiązania ??? czy tylko obawa, że częste przeprogramowywanie procka może doprowadzić do uszkodzenia tej pamięci FLASH ???? - to już ci jakiś kolega wyjaśnił ile lat mżesz tak sobie w kółko jednego proca bez najmniejszych obaw przeprogramowywać - nawet jak będziesz to robił 2razy - 4razy częściej to i tak wystarczy ci na parę ładnych LAT !!! ;)

    Po to jest opcja bootloadera żeby tak właśnie też robić bez konieczności podłączania ISP - i to też ładnie i szybko działa - często już używam takiego sposobu na zmianę firmware nawet w testowych prockach

    .... czy też może inny powód cię męczy - np mała ilosć tejże pamięci w samych prockach - ale na boga! - mówisz o ATmega128 - i powedz szczerze - udało ci się już napisać taaaak przepastnie wielki program w C żeby zajeździć jego pamięć ;) tzn chodzi mi o wielkość kodu wynikowego ????? nawet jeśli tak - to masz znowu ze 2-3 wyjścia:

    1. albo zoptymalizować program - bo może jest baaardzo nieoptymalnie napisany

    2. wziąć procka ATmega o jeszcze większej pamięci bo przecież są takie które mają na pokładzie 256. Ale jak mówię w tym przypadku z czystej ciekawości pytam - co takiego programujesz że aż tyle jej zjadasz ??? ;)

    3. rzeczywiście sięgnąć po jakiegoś ARM'a
  • #11 6866709
    y0yster
    Poziom 19  
    Ciekawie Jacek31 piszesz. Mógłbyś może podać jakieś pozycje? Co do basic stamp to raczej odpada.

    Co do Ciebie mirekk36 to hmm :). Raczej jest to problem teoretyczny, gorzej jak niedługo przerodzi mi się w praktyczny.

    Piszę po prostu soft pod taki termometr z lcd i pakuję w niego dość sporo funkcji. Już na dość początkowym etapie kod zajmuje mi prawie 5kB. Jest to już sporo dla takiego programu, a pozostało tylko 3kB, które na pewno niedługo wykorzystam.

    Jeśli chodzi o optymalizację, bo ten wątek już był kilka razy wspomniany, to o jaką konkretnie chodzi? O optymalizację kompilatora? Jeśli tak to mam opcję -Os i jak na razie wszystko dość dobrze działa. Tylko jedna rzecz mnie irytuje. Co od optymalizacji kodu też takową przeprowadziłem, np. odczyt prowadzę z dwóch czujników, to wszystko jest w pętli. Przeprowadziłem to samo z napisami, które wyświetlają się na lcd. Są one upakowane w wewnętrznym eepromie, ale nie przyniosło to zmniejszeniu kodu. Wręcz przeciwnie, troszeczkę go przybyło :/.

    Pozdrawiam.
  • #12 6866761
    Jacek31
    Warunkowo odblokowany
    Oj... zaczynam mieć poważne obawy co do tego tematu :?: Faktycznie brniesz w coraz to dziwniejsze rozważania, jak kolega wspomniał.
    Ale jeżeli chodzi o optymalizacje, to oczywiście chodzi także o tę w opcjach kompilatora, ale głównie o optymalizacje kodu który ty piszesz. 8KB na termometr powinno starczyć. Sęk w tym że każdą procedurę, da się napisać na wiele sposobów, jedne będą szybsze inne wolniejsze, jedne zajmą np 0,5KB inne tylko 0,3 KB pamięci i o to się biega w całej sztuce programowania. Trudno tu coś doradzić tak z powietrza, sam musisz przemyśleć swój program pod tym kątem, a nóż się okaże że niektóre obliczenia da się robić prościej. Czasem paradoksalnie pozorne komplikowanie programu go upraszcza (mniejszy kod wynikowy), np podział na więcej procedur wywoływanych w odpowiednich pętlach.
    ale tu wszystko zależy od wiedzy i zdolności programisty, i raczej nikt ci prostego gotowego sposobu nie przedstawi. Ogólnie kluczem do sukcesu w takich przypadkach jest znajomość budowy algorytmów. Czasami dobrze sobie problem rozrysować na kartce i podzielić na logiczne bloki, wtedy łatwiej dostrzec własne błędy, lub alternatywne drogi rozwiązania. Niekiedy w informatyce lepsze rezultaty daje działanie na wspak, czyli od końca. Ale to można by całą książkę napisać na ten temat (zresztą taka jest :wink: ). Warto także zajrzeć do not katalogowych, czy not aplikacyjnych US czy czujników szczególnie jak używasz układów DS, tam często są gotowe procedury w C lub ASM dla AVR lub 51 i wystarczy je tylko zastosować.
    Oto przykład ze starej książki. Może na dzisiejsze czasy mało przydatny jako fragment bez schematu urządzenia, ale tam to było fajne że wszystko tłumaczone na chłopski rozum i prosto
    [atmega8][avr] Dodatkowa pamięc programu w uC
  • #13 6866780
    mirekk36
    Poziom 42  
    y0yster --> ja też jak zaczynałem pisać w C to na początku bałem się, że przy rozpoczęciu programowania - po wrzuceniu wstępnej obsługi jakiegoś LCD albo u mnie VFD, do tego 1wire, I2C itp - program szybko skoczył o kilka kb powiedzmy. Ale później robudowywanie samych pętli, dodatkowych funkcji itp - to śmiesznie mało miejsca zajmuje. Dlatego zwykle ostatnio sięgam po Atmega32 rzadziej 16. I zwykle się okazuje, że po zakończeniu takiego czy innego projektu jeszcze zostaje cały HEKTAR pamięci do zaorania. To daje o tyle wygodę, że nawet na szybko coś pisząc bez optymalizacji - starcza tego miejsca do bólu w takim np ATmega32. Mówię ci spróbuj na coś większego pisać - to szybko się okaże , że "nie tak łatwo" ;) zapchać mu pamięć pisząc w C - w porównaniu oczywiście do Bascoma.

    Natomiast jeśli chodzi o optymalizację - to oczywiście nie chodzi mi o opcje typu -Os itp

    po prostu zwykle po zakończeniu całości - biorę się za odchwaszaczanie, i optymalizację tego czego nieraz gdy robi się na szybko to zajmuje X kodu a gdy się na to później popatrzy już na spokojnie na całość - to okazuje się, że jeszcze tu można poprawić i tu .... i tam no i X się jeszcze znacznie zmniejsza wiele razy
  • #14 6872776
    Zajc3w
    Poziom 14  
    y0yster napisał:
    Ciekawie Jacek31 piszesz. Mógłbyś może podać jakieś pozycje? Co do basic stamp to raczej odpada.

    Co do Ciebie mirekk36 to hmm :). Raczej jest to problem teoretyczny, gorzej jak niedługo przerodzi mi się w praktyczny.

    Piszę po prostu soft pod taki termometr z lcd i pakuję w niego dość sporo funkcji. Już na dość początkowym etapie kod zajmuje mi prawie 5kB. Jest to już sporo dla takiego programu, a pozostało tylko 3kB, które na pewno niedługo wykorzystam.

    Jeśli chodzi o optymalizację, bo ten wątek już był kilka razy wspomniany, to o jaką konkretnie chodzi? O optymalizację kompilatora? Jeśli tak to mam opcję -Os i jak na razie wszystko dość dobrze działa. Tylko jedna rzecz mnie irytuje. Co od optymalizacji kodu też takową przeprowadziłem, np. odczyt prowadzę z dwóch czujników, to wszystko jest w pętli. Przeprowadziłem to samo z napisami, które wyświetlają się na lcd. Są one upakowane w wewnętrznym eepromie, ale nie przyniosło to zmniejszeniu kodu. Wręcz przeciwnie, troszeczkę go przybyło :/.

    Pozdrawiam.


    No wiesz... Na atmedze8 zmieściłem alarm z obsługą modułu GSM. konfiguracja była przez smsy, uzbrajanie strzałkami, powiadamiał smsami o zdarzeniach na 2 wejściach, o zaniku zasilania i wyczerpaniu akumulatora. Treści smsów, numery uprawnione polaryzacje wejść i wyjść wszystko konfigurowane przez smsy.

    Na Atmega64 można zmieścić FAX GSM(odbiera dane z normalnego faksu i wysyła do odbiorcy przez sieć GSM kod wersji beta miał ~40KB)

    Jak na termometr trochę dużo kod Ci zajmuje. Albo piszesz niechlujnie, albo nie włączyłeś optymalizacji. No chyba że upchnąłeś tam obsługę kart SD do zapisu logów... :D
  • #15 6872802
    y0yster
    Poziom 19  
    Nie nie ma tam karty SD ;).
    Co do tego czy piszę kod niechlujnie, to może sam ocenisz.
    Co w programie się znajduje to: obsługa lcd (z bussy flag), 2 termometry ds18b20 na jednej linii z możliwością rozbudowy do znaczniejszych ilości ;), odczyt kodów RC5, zapis danych do wewnętrznego EEPROM'u, wchodzenie w stan uśpienia oraz dość rozbudowane menu, jak na razie sam szkielet, w którym można edytować 2 opcje.

    Co zamierzam dodać to komunikację po rs232, zapis do zewnętrznego EEPROM'u oraz rozbudowa trybu chronionego, (cokolwiek by to miało znaczyć :P- termometr będzie miał dostępne inne opcję po podaniu hasła).

    Pozdrawiam.
  • #16 6872953
    markosik20
    Poziom 33  
    y0yster napisał:
    Raczej jest to problem teoretyczny, gorzej jak niedługo przerodzi mi się w praktyczny.


    Więc posłuchaj kolegów, zastosuj uC z większą ilością flash'a. Z tego co napisałeś program Twojego urządzenia powinien bez problemu zmieścić się w 16kB, więc dla zapasu można zastosować 32kB. W miarę "rozrastania" się programu kompilator inaczej sobie go optymalizuje. Mnie się zdarza czasami że mam np: 11kB kodu , dopisuje dużą funkcję i kompilator robi z tego wszystkiego 10kB. Kombinowanie dzisiaj z zewnętrznymi flash'ami przy tak małych projektach jest nieopłacalne i nieefektywne (więcej zabawy będzie z zatrzaskami, płytką, adresowaniem i programowaniem pamięci niż z samym softem).
  • #17 6873005
    y0yster
    Poziom 19  
    Całkiem rozsądnie mówisz, ale jest jeden problem. Gdzieś w postach zdaje mi się, że pisałem o tanim rozwiązaniu :/.

    Bardzo chętnie zastosowałbym Atmega328P, jest to coś takiego jak Atmega88, tylko, że z pamięciom 32kB. W dodatku ma tyle samo pinów co Atmega8. Jedyne "ale" to to, że kosztuje ~20zł i znalazłem ją tylko w jednej hurtowni.

    Więc szukam jakiś odpowiedników, ale jeszcze nic konkretnego nie znalazłem :/.
  • #18 6873140
    mirekk36
    Poziom 42  
    y0yster --> a po co ci od razu droga nowa Atmega328 - jak możesz użyć spokojnie taniej jak barszcz Atemgi16 albo Atmegi32 - przecież pisałem o tych prockach - inne też ;) a ty na mega328 patrzysz ;) .... poza tym Atmega16/32 ma o wiele więcej wyprowadzeń niż mega8

    oj coś z czytaniem not PDF kiepsko, widzę ;)
  • #19 6873164
    y0yster
    Poziom 19  
    Oj mirekk36, z czytaniem not jest całkiem dobrze, nie narzekam ;)

    Co to tych wyprowadzeń, ma ich więcej, prawda ma ich więcej, ale na razie nie chce się przeprowadzać na większą ilość wyprowadzeń, to co mam na razie mi wystarcza (co do ilości wyprowadzeń).

    Także, nie znalazłem uC dostosowanego do moich potrzeb :/.

    Jest jeszcze Atmega168 może mi przypasować, ale cena już jest 2 razy większa niż zwykłej, poczciwej atmega8 i ma tylko 2 razy więcej pamięci.
  • #20 6873179
    mirekk36
    Poziom 42  
    aaa no to trzeba było mówić , że szukasz procka AVR, który ma tylko tyle wyprowadzeń co ATmega8 - ale za to więcej pamięci FLASH ;)

    hmmm tyle tylko, że jeśli tak jest - to gwarantuję ci, że nie znajdziesz żadnego prostego sposobu - albo w ogóle sposobu aby dla procka o takiej ilości wyprowadzeń podłączać większą zewnętrzną pamięć FLASH z możliwością wykonywania programu w niej zapisanego

    niestety - coś za coś
  • #22 6873297
    mirekk36
    Poziom 42  
    Wiesz co - jak kiedyś się wkurzyłem i zassałem sobie prkatycznie po kolei prawie wszystkie noty PDF procków AVR

    i teraz jak coś zaczynam projektować i mam wybrać procek - to najpierw sobie spokojnie przeglądam po kolei noty - aby sobie odświeżyć wiedzę na temat, który ma ile pamięci FLASH i jakie ma inne peryferia... (jeśli mi odpowiada to sprawdzam jeszcze ceny i dostępność u dostawców)

    bo tak z gruszki to ciężko coś polecić - w końcu zapewne nie tylko o pamięć ci chodzi ale i o peryferyjne moduły jak Timery itp

    polecam więc taką drogę doboru AVR'ków
  • #23 6873308
    y0yster
    Poziom 19  
    Tak też próbowałem dobierać procki, ale korzystam nie not, ale z zestawienia, procków, które jest dostępne na stronie atmel'a.

    Właśnie, decydujący czynnik, to także koszt takiego układu.

    Nie raz też bywa tak, że dobierasz coś do danego projektu, a potem się może okazać, że jednak czegoś tam brakuje. A kupowanie na zapas droższych uC według mnie mija się z celem.

    Pozdrawiam.
  • #24 6873484
    markosik20
    Poziom 33  
    y0yster napisał:
    Co to tych wyprowadzeń, ma ich więcej, prawda ma ich więcej, ale na razie nie chce się przeprowadzać na większą ilość wyprowadzeń, to co mam na razie mi wystarcza (co do ilości wyprowadzeń).

    Także, nie znalazłem uC dostosowanego do moich potrzeb :/.


    I wątpię żebyś znalazł :wink:. Kto Ci każe wykorzystywać dodatkowe piny? Chcesz mało zapłacić ale zarazem mieć dużo...takie rzeczy to tylko w Erze.
    Oferta Atmela (AVR) jest na dzień dzisiejszy najtańszym rozwiązaniem na rynku Polskim dla uC poniżej 32kB (za kilka złotych więcej od Atmegi32 masz STM'a32 z 32kB Flash'a). Jakbyś nie liczył im więcej kB potrzebujesz tym MUSISZ więcej zapłacić (czy to za dodatkową pamięć zewnętrzną, czy więcej miejsca na płytce). I szukanie rozwiązań na których zaoszczędzisz 2-3zł (a stracisz dwa tygodnie na uruchomienie)....no wybacz śmiechu warte.....chyba że chcesz to produkować w tysiącach egzemplarzach?....to wtedy raczej trzeba się dogadywać z dostawcami o rabaty.
  • #25 6874096
    ZbeeGin
    Poziom 39  
    y0yster napisał:
    Jest jeszcze Atmega168 może mi przypasować, ale cena już jest 2 razy większa niż zwykłej, poczciwej atmega8 i ma tylko 2 razy więcej pamięci.

    A 4 razy więcej w ATMega328P? 32kB będziesz miał ciężko zapełnić.

    Niestety kwiestia ceny jest taka a nie inna - innej obecnie nie będzie. ATMega8 to stary układ i cena jest niska, gdyż czyszczą się magazyny. Sam Atmel polecał już dawno przechodzić na ATMega88, bo kończy (albo nawet już zakończył) produkcję ATmega8. Pomyśl o tym, bo staniesz w miejscu. Projekt będzie gotowy do wdrożenia, ale kupienie większej ilośći układów będzie graniczyło z cudem.
  • #26 6874198
    _Robak_
    Poziom 33  
    Nie rozumiem czemu tak bardzo chcesz dodawac na sile do procka pamiec zewnwetrzna. Bierzesz procka z wieksza iloscia pamieci i juz, a ze ma wiecej IO ktorych nie wykorzystasz... trudno. Bardzo latwo policzyc ze placisz za ilosc pamieci a nie za IO. Cena atmega16/atmega32 = 0.73, cena atmega88/atmega16=0.75. Jak wiesz atmega16 i atmega 32 roznia sie tylko iloscia pamieci.
  • #28 6963304
    y0yster
    Poziom 19  
    Tak, bardzo fajne :).

    A co do termometru, to czytając temat powinieneś wywnioskować, że już jest skończony ;).

    Temat zamykam, żeby nie było off-topick'u.
REKLAMA