Dlaczego w symulacji BASCOM dla ATMega88 widzę mniej rejestrów I/O?

W datasheecie procesorów ATMega48/88/168 znalazłem informację że procesor ATMega48 jest podobny do procesora ATMega88. Procesor ATMega88 jest "potomkiem" procesora ATMega8 i jest z nim zgodny pod względem wszystkiego. Rożni się tylko tym że jest w stanie chodzic na 24MHz i że ciagnie mniej prądu. A procesor ATMega48 jako że nie ma swojego przodka w postaci procesora ATMega4, jest podobny do ATmega8, tyle że ma mniej pamięci programu i pamięci RAM. Timery i rejestry I/O powinien mieć takie same.
A jak odpalalam BASCOMa i wejdę do symulacji programowej to w zakładce I/O, tej ktora pokazuje zawartość rejestrów jest bardzo mało rejestrów. Może jakaś 1/3 tego co powinno być.
Dlaczego? Czy jednak ATMega48 jest uboszszy od ATMega88 nie tylko pod względem mniejszej pamięci?

No może i w innej przestrzeni adresowej ale dla ATMega88 pokazuje rejestry a dla ATMega 48 nie.

Czyli pisząc program mogę zdeklarować dowolny z procesorów ATMega8/88/48 a bedzie on i tak działał na każdym z nich.
Wielkie dzięki za informacje!

A teraz mam inny problem. Doszedłem do wniosku że AVRStudio to jednak coś fajnego i postanowiłem go sobie zainstalować. Jakieś kilka miesięcy temu mi się to nie udawało bo na stronie Atmela mieli jakąś lipną instalkę której nie mogłem zainstalować na żadnym kompie. Dopiero dzisiaj ściągnałem tą instalkę znowu i tym razem udało mi się ją zainstalować.
Wszystko piękne ale nie kompiluje mi programów. Jak otworzę plik USBtoRS232.asp autorstwa Igora Cesko to po wciśnięciu F7 (Build) wywala mi taki błąd jak na dołączonym screenie.
Co ciekawe wywalenie tej linijki nic nie daje. Jak znowu wcisne F7 to wywala błąd w pustej linijce w miejscu gdzie wcześniej był błąd.
Rozumiem że słowo "OR" jest zastrzerzone ale skoro tak to jakim cudem znalazło się w bibliotece procesora ATMega8 dostarczonej wraz z AVRStudio?
Jak Wy jak sobie radzicie z kompilacją?
Acha. I taki błąd występuje niezależnie od tego czy chcę kompilować w starszej czy w nowszej wersji AVRStudio.

Attempt to redefine keyword "Or".

Nie chodzi o konwerter USB-RS232, bo mam kilka takich już (takich w kablu).
Chodzi o odpalenie AVRStudio. Podałem przykładowy kod do USB bo to jedyny jaki mam który powinien działać (kompilować się).

Acha. Wystarczyło zapisać plik przed ponowną kompilacją.

Dodano po 3 [minuty]:

Acha. I jeszcze jedno: Po pierwsze ja potrzebuję używać funkcji logicznych więc trudno będzie ich nie używać. A po drugie w tym przypadku to nie ja ich użyłem, tylko AVRStudio i sam sobie wywalił błąd z tego powodu.

Teraz mam inny błąd: Out of range in: "ldi R28, 0x8005".
Takie coś działa:
ldi bitcount,CRC16poly>>8
A takie już nie
ldi bitcount,CRC16poly.

Jak zrobic żeby załadował do R28 młodsza połówke tej stałej?

Dziex, ale już wpisałem ldi bitcount, low(CRC16poly).
Wcześniej mi to nie działało. Może zrobiłem jakąś literówkę.

PS. Żeby wywalić starszą połówkę to trzeba przesunąć 8 razy z nie 4.
Wiem że LDI działa tylko na liczbach 8-bitowych. Assembler AVR mam w jednym palcu. Dziwiłem się tylko że kompilator automatycznie nie wstawia młodszej połówki jak widzi liczbę 16-bitową. Igorowi Cesko to działało więc czemu mi ma nie działać.
Do tej pory wszystkie problemy znikineły. Nawet programator USB działa (AVR910). Oczywiście z BASCOMem nadal się zawiesza.

Ja ASMa znam już gdzieś od 2 lat. Używam go nie dlatego że go lubię, tylko dlatego że lubię patrzeć jak program śmiga i jak mało zajmuje pamięci. Jak bym pisał w wysokim poziomie, nawet w C, to jakieś 70% moich programów w ogóle nie miało by szans działać. Na przykład programu do USB gdzie potrzebna jest superextremalna optymalizacja i dokładnie ustalony czas wykonywania określonych procedur. A w C nawet jak by to działało szybko, to czas mógł by być różny zależnie od tego jak kompilator to skompiluje. Nowsze wersje kompilatorów zwykle mają jakoś bardziej zoptymalizowane funkcje i dają szybciej działający kod, lub mają dodaną jakąś obsługę błędów i wtedy program działa wolniej. Trudno to przewidzieć.
Ja w dodatku często stosuję różne niespotykane nigdzie sztuczki do operowania na bitach, które trzeba pisać w assemblerze. Albo jakieś sztuczki w obsłudze przerwań. To tez wymaga pisania w assemblerze. Nie ma osoby która przekona mnie do pisania w całości w wysokim poziomie na mikrokontrolery. Na kompa to nie trzeba mnie przekonywać, bo od zawsze tak robię. Ale na sprzęt to nie. Jak już to mogę mixować ASMa z BASCOMem. Mixowanie ASMa z C to same problemy z tego co słyszałem.

Ja w przeciwieństwie do 99% programistów mam konkretne powody dla których nie lubię C. Każdy tylko ma jakieś widzimisie albo maxymalnie po prostu nie rozumie mocno skompresowanych programów.

To jest powód także dla mnie. C jest tak zwięzłe że najczęściej nic z tego nie rozumiem. Podstawy C i jakieś działające programy w nim to ja już pisałem. Ale czyichś to nie rozumiem.
Największym problemem jest odpalenie kompilatora. Nie widziałem jeszcze kompilatora (z edytorem) w którym piszę, kompiluję i działa. W Delphi, Pascalu albo BASCOMie to standard. A w C nie bardzo. Jeszcze nigdy samemu nie udało mi się uruchomić żadnego kompilatora C. Zawsze musi mi pomagać ktoś inny, kto normalnie robi w C.

Drugim problemem jest mixowanie z ASMem. To dotyczy tylko mikrokontrolerów, bo na kompa to nie piszę w ASMie.

No komendy są takie same. Każdy język wysokiego poziomu ma instrukcje "if", "for" itp. itd.
Ale różni się i to bardzo. A mixowanie jest po to żeby w assemblerze napisać to co musowo, czyli to co musi działać szybko, a całą resztę w C.
Mi też brakuje czasu ale ja piszę tak extremalnie wyżyłowane programy że muszę to robić w AMSie.

Nawet nie wiedziałem.
Ja tez nie wiem jak z nich korzystać bo nigdy z nich nie korzystałem.

Mam datasheeta procesora ATMega88 z 2004 roku (preliminary). I w nim pisze że on chodzi na 24MHz (ATMega88 - 24PI/AU/PU).
A teraz szukam na allegro i gdzie tylko indziej sie da takiego procesora ale nigdzie takiego nie ma. Są za to ATMega88 - 20PI/AU/PU.
Ściągnołem sobie więc nowego datasheeta żeby zobaczyć czy jest tam jakaś wzmianka o tej wolniejszej wersji. I ku mojemu wielkiemu zdziwieniu nie tylko "wzmianka" jest, ale w dodatku nie ma żadnej wzmianki o procesorze na 24MHz!!!
O co tutaj chodzi? Czy projektanci projektowali procesor na 24MHz, ale im nie wyszło?
Mam kilka procesorów ATMega88-20PI i chodzą one spokojnie nawet na 28MHz przy 5V i sprostały moim wymaganiom szybkościowym ale miałem nadzieję że skoro procesor na 20MHz łyka spokojnie częstotliwość 1.3razy większą to procesor na 24MHz tez tak zrobi i pójdzie co najmniej na 30...32MHz.
Ale teraz widzę że nie łyknie, bo go nie ma.
Wiec są takie procesory czy nie?

Szkoda.
Wprawdzie potrzebowałem 24MHz i ucieszyłem się że ten na 20MHz chodzi i na 24MHz. Ale liczyłem na to że jak zdobędę ten na 24MHz to łyknie ze 30MHz. Szczególnie że okazało się że 24MHz mi nie wystarczy. Wczoraj przypadkiem odkryłem w datasheecie dodatkowe rozkazy (muls, mulsu, fmul, fmuls, fmulsu, movx, lpm, Rx, Z, lpm, Rx, Z+).
Pomoc BASCOMa nic o nich nie wspomina. A na niej sie opierałem do tej pory. Dzięki tym instrukcjom znacznie uprościłem program ale i tak musi chodzić na 26MHz.
Moje egzemplarze ATMega88 spokojnie łykały 28MHz przy 5V i nie wykazywały żadnych usterek podczas pracy.
BASCOM nie potrafi konfigurować Timerów w ATMega88! Dotyczy to na przykład TIMERa0. BASCOM stawia kod jak dla ATMega8, czyli próbuje modyfikować rejestr TCCR0. Tylko że ATMega88 nie ma takiego rejestru, tylko TCCR0A i TCCR0B i BASCOM zamiast modyfikować rejestr TCCR0 modyfikuje…SREG!
Dobrze że BASCOM przynajmniej wie jakie są adresy tych rejestrów i przynajmniej można samemu skonfigurować Timer0 pisząc to w assemblerze. Jak by nie wiedział to by trzeba było adresy wpisywać.

A swojego czasu zastanawiałem się jak kompilator radzi sobie z różnymi rodzajami procesorów. I teraz doszedłem do wniosku że po prostu sobie nie radzi.
Ma listę rejestrów i ich adresy w plikach *.def, ale musiałby także wiedzieć jak z nich korzystać. Przecież niektóre procesory nie mają rozkazu mnożenia i dla nich kompilator powinien wstawiać kod mnożący programowo.
Albo na przykład powinien wykorzystywać sprzętowy interfejs 2wire, a jak go nie ma to nie.

Dlaczego w 2007 roku wersja AVR Studio też z 2007 roku nie umie programować procesora ATMega88? Chodzi mi o ustawianie bezpieczników. AVR Prog nie słyszał o takim procesorze. Próbowałem ustawić bezpieczniki ustawiając typ procesora na ATMega8 i zablokowałem sobie 2 procesory. Na szczęście po dokładnym przeanalizowaniu datasheetów procesorów ATMega8 i ATMega88 doszedłem do wniosku, że bitu które ustawiłem, które miały włączyć tryb pracy generatora na „max xtal freguency”, dla procesora ATMega88 oznaczają tryb „low frequency crystal oscillator” więc procesory jeszcze da się uratować programując je przez ISP, trzeba tylko będzie podłączyć kwarca ze 30…500kHz i w programatorze ustawić „Low SCK”.
Brak rejestrów, brak typów procesorów, błędy przy kompilacji to standard.
Szkoda że programator AVR910 nadal nie działa z BASCOMem. BASCOM słyszał o procesorze ATMega88, i nim mógłbym go zaprogramować. Niestety nie słyszał o poprawnej pracy z programatorem USB ;(.
Wniosek: Mam 2 kompilatory, oba coś potrafią. Oba są fajne. Ale jeżeli chodzi o programy na ATMega88 i o programowanie ATMega88 to obydwa g…. potrafią ;(.

Nawet mi sie nie chciało jak to pisałem ;p