Kanał - ATNEL tech-forum
Wszystkie działy
Najnowsze wątki



Teraz jest 2 kwi 2020, o 00:47


Strefa czasowa: UTC + 1





Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 9 ] 
Autor Wiadomość
PostNapisane: 25 lut 2018, o 06:54 
Offline
Nowy

Dołączył(a): 25 lut 2018
Posty: 4
Lokalizacja: Warszawa
Pomógł: 0

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



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 25 lut 2018, o 07:33 
Offline
Użytkownik

Dołączył(a): 25 lip 2013
Posty: 2060
Pomógł: 98

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



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 25 lut 2018, o 07:50 
Offline
Nowy

Dołączył(a): 25 lut 2018
Posty: 4
Lokalizacja: Warszawa
Pomógł: 0

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 ;)



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 25 lut 2018, o 08:47 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 25274
Lokalizacja: Szczecin
Pomógł: 956

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 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 25 lut 2018, o 08:48 
Offline
Użytkownik

Dołączył(a): 25 lip 2013
Posty: 2060
Pomógł: 98

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



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 25 lut 2018, o 09:08 
Offline
Nowy

Dołączył(a): 25 lut 2018
Posty: 4
Lokalizacja: Warszawa
Pomógł: 0

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 ]

mirekk36 napisał(a):
z punktu widzenia pisania kodu w języku C - to przepraszam, ale to jest nonsens ;) ... kompletny nonsens.


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).



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 25 lut 2018, o 09:27 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 518
Pomógł: 131

villagetech napisał(a):
... OSCCAL ... czy mogę użyć ten rejestr jako zwykły rejestr, i przechowywać sobie w nim "coś swojego"?

Moim zdaniem jest co najmniej jeden ważny powód, żeby tego nie robić:
Atmel/Microchip napisał(a):
Note that this oscillator is used to time EEPROM and Flash write accesses, and these write times will be
affected accordingly. If the EEPROM or Flash are written, do not calibrate to more than 8.8MHz.
Otherwise, the EEPROM or Flash write may fail.

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.

_________________
Miksowanie kodu C i ASM przy użyciu GCC



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 25 lut 2018, o 09:41 
Offline
Nowy

Dołączył(a): 25 lut 2018
Posty: 4
Lokalizacja: Warszawa
Pomógł: 0

Cytuj:
Moim zdaniem jest co najmniej jeden ważny powód, żeby tego nie robić:
Atmel/Microchip napisał(a):
Note that this oscillator is used to time EEPROM and Flash write accesses, and these write times will be
affected accordingly. If the EEPROM or Flash are written, do not calibrate to more than 8.8MHz.
Otherwise, the EEPROM or Flash write may fail.

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 :)



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 25 lut 2018, o 10:06 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 518
Pomógł: 131

villagetech napisał(a):
Kto ich tam wie :) Nie znam ATmegi (jeszcze)

A od czego są dokumentacje producenta? ;)

villagetech napisał(a):
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ć...

...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.

villagetech napisał(a):
Szczerze mówiąc miałem nadzieję, że ktoś już to robił/testował

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.

_________________
Miksowanie kodu C i ASM przy użyciu GCC



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
Wyświetl posty nie starsze niż:  Sortuj wg  
Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 9 ] 

Strefa czasowa: UTC + 1


Kto przegląda forum

Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 1 gość


Nie możesz rozpoczynać nowych wątków
Nie możesz odpowiadać w wątkach
Nie możesz edytować swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Skocz do:  
Sitemap
Technologię dostarcza phpBB® Forum Software © phpBB Group phpBB3.PL
phpBB SEO