Na początek chciałbym się przywitać - jestem nowy, to mój pierwszy post, a więc wypada

Ale do rzeczy: mam pytanko o OSCCAL w ATmega32u4 pracującej z zewnętrznym kwarcem (NIE RC!!!!) - czy mogę użyć ten rejestr jako zwykły rejestr, i przechowywać sobie w nim "coś swojego"?

Przestudiowałem oficjalną dokumentację, wiadomo, że wartość OSCCAL ma znaczenie tylko z wewnętrznym RC - a więc skoro z RC nie korzystam, to mogę wykorzystać OSCCAL jak chcę?
Testował to ktoś może?

Piotrek

A do czego chcesz go wykorzystać? RAMu nie możesz do tego celu użyć?

Oczywiście, że mogę.
Pytanie jest nieco... teoretyczne

BTW: w notkach producenta n/t optymalizacji kodu jest wzmianka, że używanie rejestrów z obszaru I/O (niskie adresy pamięci) do przechowywania wartości daje pewne korzyści (mniejszy i szybszy kod), no i takie zmienne zachowują się jak "volatile", co bywa wygodne np. jeśli są wspólne dla programu głównego i kodu obsługi przerwań.

Zresztą są nawet 3 rejestry przeznaczone do tego: GPIOR0...2 - ale zawsze przydałoby się kilka więcej

z punktu widzenia pisania kodu w języku C - to przepraszam, ale to jest nonsens ... kompletny nonsens. Jeszcze żeby była mowa o prockach które albo nie mają w ogóle pamięci RAM i pisze się do nich kod w ASM to można byłoby zrozumieć, ale z kolei w nich akurat OSCCAL jest zwykle potrzebny bo one działają nwe wewn. oscylatorze RC.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Pamiętaj, że zawartość OSCCAL podczas resetu procka jest nadpisywana.

To mnie nie boli, niech się traci. Myślę o przechowywaniu tam flag bitowych maszyny stanów, które i tak ustawiane są na jakieś wartości początkowe przy starcie programu, i są dość często testowane w rozmaitych miejscach.
Bardziej boję się tego, że np. jakieś zdarzenie (np. ustawienie jakiegoś bitu w którymś rejestrze) wbije mi niespodziewanie do OSCCAL jakąś nieoczekiwaną wartość.
Nie wiem, w C programuję zawodowo od prawie 20 lat, ale na ATmegę (AVR-gcc/AVR-libc) to mój pierwszy program w C i nie znam jeszcze na pamięć całej dokumentacji procka

------------------------ [ Dodano po: 12 minutach ]



Wiesz, z jednej strony może i nonsens, z drugiej strony jeśli sprawdzam/dotykam flagę bitową w kilkunastu miejscach, w dodatku potrzebuję kilku takich flag, to troszkę miejsca i cykli można przyoszczędzić Tym bardziej, że projekt, który robię, korzysta z kilku tablic których elementy są dość sporymi i rozbudowanymi strukturami, i ciut się obawiam, że koniec końców trzeba będzie to i tak odchudzić, bo RAMu nie styknie...

Na czytelność programu to nie wpływa - od czego jest niezastąpiony #define Zresztą wykorzystanie takich rzeczy można sobie zrobić warunkowo (na poziomie kompilacji oczywiście, i oczywiście z pomocą #define/#ifdef).

Moim zdaniem jest co najmniej jeden ważny powód, żeby tego nie robić:

Myślę, że lepiej nie kombinować i uznać, że ten rejestr służy tylko do kalibracji. Jeśli już koniecznie musisz użyć rejestru IO, możesz użyć (jak sam słusznie zauważyłeś) jednego z rejestrów GPIOR.

No właśnie widziałem to, i też wzbudza to moje wątpliwości. Niby przy użyciu kwarcu nie powinno to być wykorzystywane - ale może jednak jest, i zapisy do EEPROM/FLASH (a z EEPROMa korzystam, a jakże) są taktowane mimo wszystko z RC? Kto ich tam wie Nie znam ATmegi (jeszcze)

Szczerze mówiąc miałem nadzieję, że ktoś już to robił/testował - ale jeśli nie, to rzeczywiście dam sobie siana, bo jak mi się maszyna stanów zacznie zachowywać nieprzewidywalnie, to zimy nie starczy na uruchomienie projektu

A od czego są dokumentacje producenta?


...pod warunkiem, że rejestr jest dostępny dla instrukcji asm: SBI, CBI, SBIS i SBIC. OSCCAL nie jest dostępny nawet dla instrukcji asm IN i OUT, więc raczej nic nie zaoszczędzisz, bo dostęp do niego masz taki sam, jak do pamięci RAM. Do tego, co chcesz osiągnąć nadaje się tylko rejestr GPIOR, którego adres w przestrzeni I/O jest mniejszy od 0x20 (zwykle GPIOR0, ale to trzeba sprawdzić w dokumentacji konkretnego mikrokontrolera). Tylko wtedy uzyskasz szybki dostęp do poszczególnych bitów.


Myślę, że nikt nie testował, pewnie dlatego że - jak już wspomniał wcześniej kolega Mirek i jak być może teraz sam zauważyłeś - nie ma to większego sensu.