Witam.

Nurtuje mnie zagadnienie przechowywania danych:
1. Posiadam sobie dane o ustawieniach. Będą one przechowywane w EEPROM, i słane po RS. Czy takie dane lepiej trzymać w tablicach, zmiennych czy strukturach (typie strukturalnym)?

2. Teraz mam dane (np . temperatura, napięcie - dane z przetwornika ADC) czy takie informacje które nie będą w EEPROM a będą słane po RS należy trzymać w tablicach, zmiennych czy strukturach (typie strukturalnym)?

3. Dane które będą na bieżąco wyliczane i nie opuszczą pamięć RAM należy trzymać w tablicach, zmiennych czy strukturach (typie strukturalnym)?

Rozmiar to przeważnie od 1 do 16bitów (wiem nie ma typu jedno bitowego w C dla AVR, ale w strukturze da się to uzyskać zapewne).

Chodzi mi o to aby jak najlepiej zarządzać przestrzenią zajmowaną przez dane, łatwością dostępu (szybkość nie jest konieczna, zawsze OC lutownicą na kwarcu można zrobić ), a jak już słać przez RS to żeby można było łatwo je odczytać na PC, czy innym AVR,ku.

Najbardziej dziwią mnie twoje pytania -



a to przepraszam - to każda z tych wyżej wymienionych rzeczy to coś innego ? bo mnie się wydawało zawsze, że to to samo ....

tablice to zmienne tablicowe
struktury to zmienne strukturalne
zmienne to zmienne



poza tym co to może oznaczać że dane nie opuszczą pamięci RAM ... albo co może mieć wspólnego wysyłanie przez RS232, I2C, SPI czy inny protokół ze sposobem przechowywania danych ?

czy tobie się coś bardzo mocno nie pomyliło ?

fakt, że w EEPROM'ie warto przechowywać dane w formie zmiennych strukturalnych - zresztą w każdej innej pamięci także ... no ale żeby to wiązać akurat z przesyłaniem RS232 ? no chyba że ja czegoś nie zrozumiałem to mnie popraw proszę - bo też tak się mogło zdarzyć .

o sposobach przechowywania danych w EEPROM poczytaj i obejrzyj to:

http://mirekk36.blogspot.com/2012/11/av ... iazek.html

_________________
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 ]

Ja może podpowiem tak:

zmienne, które aż się proszą o stablicowanie -> do tablicy. Czyli wiele podobnych liczb o takim samym charakterze i typie, powiedzmy próbki jakiegoś sygnału.

Zmienne, które mogą być różnych typów ale są ze sobą powiązane, bo np. opisują jeden moduł (różne jego cechy) -> do struktury. Np. struktura opisująca wyświetlacz: rozdzielczość w pionie (int), rozdz. w poziomie (int), głębia kolorów (int), typ interfejsu (string), producent (string), font (wskaźnik do pliku) itp.

luźne zmienne -> te, których nie można stablicować (pojedyncze zmienne) ani nie łączą się z innymi w sposób logiczny.

_________________
ATB 1.03, Win XP SP3, ECLIPSE Indigo 3.7.2

Mirku po twoim kursiku z linka mam takie zakręcenie w głowie. Bo wcześniej to robiłem tak jak kolega @Ledes napisał.
Tu nagle stosowanie typu strukturalnego... I tak zaczynam myśleć, że co do tej pory się nauczyłem to możne już są złe nawyki, może są inne lepsze sposoby niż stosowanie np tablicy z progami alarmów (czasowych, temperaturowych, napięciowych itp). Może takie dane lepiej jest trzymać w inny sposób?
Sadzę że jak by to było dokładnie to samo to by nie istniały trzy rodzaje jednej rzeczy.
To jak samochód:
- Osobowy to samochód,
- Dostawczy to samochód,
- Ciężarowy to też samochód.
Niby samochody ale pierwszym, nie przewieziesz 10t towaru, tak samo nie ma co jechać wielkim tylko do kolegi w odwiedziny (oczywiście można tylko sens ekonomiczny).

A ja ci powiem tak - używaj jak ci jest wygodniej. Nikt nie przedstawi ci złotego środka kiedy używać zmiennych, kiedy struktur a jeszcze innym razem danych tablicowych. Im częściej będziesz ich używał tym szybciej nabędziesz doświadczenia i wyczucia kiedy jakich danych używać i nie bój się błędów każdy z nas je popełnia

To tyle tytułem wstępu. A teraz weźmy przykład który z resztą sam przytoczyłeś

Samochód osobowy - jeżeli będziesz chciał wiedzieć czy jest czy go nie ma lub będziesz chciał przechować jeden parametr np. prędkość to raczej użyjesz zmiennej.
np.

Jednak sytuacja się zmieni jeżeli będziesz chciał przechować kilka parametrów to wtedy już lepiej zastosować strukturę, w końcu łatwiej jest się odwołać do parametru czy też coś zapisać w takiej postaci:



np. tak:


A co zrobisz jak będziesz miał kilka samochodów ? To zrobisz kilka zmiennych strukturalnych ? A po co, przecież można użyć tablicy

np.:


Mam nadzieję że ci teraz się troszkę rozjaśniło

Mi nie chodzi jak działa zmienna, tablica czy struktura. Ja to wiem i w sowich programach stosuje, ale pytanie moje jest takie, jak lepiej je wykorzystać. Bo na pewno do jednej zmiennej nie będę powoływać tablicę 100-elementową.
Kiedyś do EEPROM zapisywałem zwykłe zmienne i działało, obejrzałem poradnik i widzę że może działać efektywniej, To też nasuwa mi się pytanie czy na ten przykład w przesyle też można to robić efektywnie...
Jak patrze na zasobożerność aktualnych programów na "winde" to stwierdzam że programiści już nie zwracają uwagę na efektywność kodu tylko uważają że sprzęt da rade. A jak nie to nowy...
Tutaj na forum tez już się spotykam z takimi radami "jak Ci nie zmieści się kod to weźmiesz większy AVR" ale jakby popatrzeć na kod pisany przez początkujących to można sporo ukroić (wiem to po sobie, trzecie podejście do kodu i widzę różnice) efekt będzie ten sam, wykonanie lepsze i procek mniejszy. To tak jak radzicie porzucać bascom bo tam trudniej zapanować nad wynikiem hexa, niemniej również mówicie że jest to wykonalne, również pisząc w C też można "rozśmieszyć" "bascomowców".

Pytanie może i banalne ale jak tak siedzę, czytam to mam większy mętlik. Nie jestem zawodowym programistą ale chcę być przynajmniej starannym w pisaniu.

Jeszcze nie bawiłem się w przesyłanie danych przez RS (rs232 bo tak komunikuje się kompem) tak aby na nich operować i zwracać z powrotem do proca wynik. Fakt uruchamiałem sobie gotowy kod Mirka z komendami AT - działa (jeszcze nie miałem okazji go przeczytać staranie ale wiem troszkę jak on działa).
Mamy tam bufor cykliczny i ta\k teraz zastanawiam się czy lepiej upychać tam trzy zmienne tego samego typu, czy tablice[3]; chodzi w tym przypadku o lekkość i łatwość przesyłania.

Ja wcale nie pokazywałem działania zmiennych , struktur czy tablicy .Pokazałem ci tylko przykłady zastosowania w/w elementów w stosunku do potrzeb zbierania, przechowywania danych.
Reasumując akurat tego aspektu który poruszasz nikt cię nie nauczy, ponieważ każdy program jest inny i co innego będziesz potrzebował w nim zrobić.
Wyczucie co, kiedy i jak zastosować przychodzi z doświadczeniem, a po pewnym czasie sam już będziesz wiedział co zastosować żeby było ci wygodniej korzystać, czy też co jest bardziej optymalne. Mirek w książce oraz na swoim blogu wskazał tylko drogę, ale przejść ją musisz już sam

Witam ;
Myślę ,że na miejsce i organizację danych można spojrzeć też od tej strony :

1. Szybkość dostępu przez ALU:
wtedy kolejność byłaby najszybciej RAM ,wolniej FLASH , żółwie tempo ale z zapisem EEPROM,

2. Szybkość dostępu do tej samej pamięci wymuszona organizacją potrzebnych zmiennych w pamięci :
A. Grupowanie w unie/ struktury , w większości też kolejność deklaracji tych zmiennych(w
większości ale bez gwarancji ) .
B. Zmienne używane przez funkcje , szczególnie te często wywoływane , w tablicach o ile są jednakiego typu,
deklarować/definiować po kolei .
3. Z uwagi na stos o ile nie jest niezbędne sporadyczne korzystanie ze zmiennych, korzystać ze wskaźników.

ps. niniejsze bardzo ogólne sugestie napisał "asemblerowiec" proszę zatem zachować niezbędny dystans,...

ps. wyjaśnienie : Z uwagi na zestaw rozkazów asemblera dla AVR najszybszy dostęp z użyciem jedynie jednego wskaźnika/adresu uzyskujemy wówczas , gdy "odległość" między pierwszą a ostatnią potrzebną zmienną jest poniżej 65 bajtów = wtedy na stosie potrzebujemy jedynie dwa bajty wskaźnika, a i to niekoniecznie (nie dotyczy EEPROMktóry zresztą przy szybkich i ważnych funkcjach/procedurach nadaje się wyłącznie jako dostępne w bardzo żółwim tempie źródło danych konfiguracyjnych , lub z konieczności jako miejsce przechowywania efektów działania na czas zaniku napięcia).;

------------------------ [ Dodano po: 18 minutach ]

ps. Oczywiście nie należy zapominać iż translację C na asm zrobi i tak kompilator , na razie
nie mam większych pretensji do kompilatora o tworzony kod ,choć nie umiem póki co
tego gościa przekonać, ani zmusić do używania odczytu flash z autoinkrementacją,
jestem tylko początkującym w C , więc póki co wierzę iż dogadamy się z czasem