• Witaj na Forum Arduino Polska! Zapraszamy do rejestracji!
  • Znajdziesz tutaj wiele informacji na temat hardware / software.
Witaj! Logowanie Rejestracja


Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Zapis pomiarów na karcie SD
#11
(16-07-2018, 11:55)kaczakat napisał(a): ja dalej nie widziałem Pana super bibliotek.

Moje kody w 70% są otwarte i dostępne w Internecie

(16-07-2018, 11:55)kaczakat napisał(a): Żyjemy w dobie Internetu, nie muszę sam testować by wiedzieć - zapis linijki tekstu  w wierszu na SD może trwać od 10 do 40ms (atmega328 8MHz), prędkość zależy też od karty. Ale co tam, przetestowałem też u siebie,  na karcie Nokia 512MB około 11 ms na UNO i 6ms na ESP32.
Jak więc mogło być robionych miliony zapisów? 1/0,006 ~166. 166 zapisów na sekundę, to chyba mniej niż milopny? A to jest wariant optymistyczny do:
(16-07-2018, 11:55)kaczakat napisał(a): do 40ms
co da 1/0,04 = 25 na sekundę! 25 a milion, to różnica 40'000razy . Chciałby kolega zarabiać 40'000 razy mniej?

(16-07-2018, 11:55)kaczakat napisał(a): także proszę sobie wprowadzić poprawki do obliczeń i zamienić swoją bibliotekę SD na arduinową
Nie używam swojej biblioteki ani cudzej bo nie zapisuję na SD. Dlatego strzelałem z czasem zapisu kierując się wypowiedzią:
(16-07-2018, 11:55)kaczakat napisał(a): Pomyśl ile PC potrzebuje czasu po włożeniu karty SD na jakąś reakcję, wyświetlenie zawartości, odczyt pierwszego pliku.
Co jasno sugeruj długi czas zapisu. Zgadza się?
Kto napisał o karcie SD i PC?
Kto?

(16-07-2018, 11:55)kaczakat napisał(a): Kingston 32GB SDHC 90;45MB/s  miał czasy ponad 30ms. Mi karty SD padały w telefonach również po kilkukrotnym zapisie pracując w normalnym trybie jako magazyn fotek czy multimediów
Trzeba było złożyć reklamację.


PS
Kiedyś było 100mln Bolka, teraz mamy miliony @kaczakat-a  Big Grin
- uC: ARM Angel , AVR, Z8, PIC, 8051 / CPU: MC680x0  , Z-80, 6502
- CPLD, FPGA, GAL
- GSM, ISDN, ETH, USB, RS232C/485/422
- C, ASM, CUPL, PHP, BASIC C-64

http://er-mik.prv.pl/projekty_avt.php * http://er-mik.prv.pl/ * http://kolejki.prv.pl/

KA-NUCLEO-F411CE Idea , ESP32, Mega2560, UNO PLUS
 
Odpowiedź
#12
Widziałem Pana wypowiedzi na kilku forach i pewnie jak zwykle będzie Pan walczył do ostatniego członka niczym Czarny Rycerz. Nie wiem gdzie Pan znalazł informacje, że kartę SD można zapisać 300 tysięcy razy, że mają jakieś zarządzanie ilością zapisów itd. Słyszałem o tym w dyskach SSD za parę stówek (choć daleko im do trwałości kilkudziesięciu lat), ale nie w kartach za dwie dyszki. I to bardziej jako podawanie użytkownikowi ile jeszcze życia w dysku. Przecież to dodatkowa pamięć, która musi to zapisywać co i ile razy było użyte. Może robią to jakieś kontrolery w urządzeniach, nie karta. Normalne użytkowanie karty SD to zapis zdjęć i filmów, nawet użytkując bardzo ale to bardzo intensywnie aparat można to zrobić kilkaset razy w ciągu 5 lat gwarancji. A i tak karty padają. I teraz zapis z gwarancji SANDISK:
"Niniejsza gwarancja nie obejmuje przypadków, gdy Produkt zastosowano w niżej określony sposób lub w połączeniu z którymkolwiek z niżej wymienionych urządzeń (wskazanych przez SanDisk): (i) normalne zużycie, (ii) wideo monitoring, zabezpieczenia i urządzenia nadzoru, (iii) protokół IP / kamery sieciowe, (iv) urządzenia rejestrujące w samochodzie / kamery na desce rozdzielczej / kamery czarnej skrzynki, (v) urządzenia wyświetlające z pętlą wideo, (vi) urządzenia dekodera ciągłego nagrywania, (vii) urządzenia ciągłego rejestrowania danych, takie jak serwery, lub (viii) inne zastosowania, przekraczające zasady normalnego użytkowania określone w opublikowanych instrukcjach."
Wkładając kartę do rejestratora, który zapisze ją całą powiedzmy w ciągu doby, następnie powtórzy cykl 365x5 lat otrzymalibyśmy zaledwie ~2000 zapisów każdej komórki, a już to oznacza utratę gwarancji.
Cytat z porównania kart do rejestratorów samochodowych:
"karty są budowane z wykorzystaniem lepszych pamięci MLC, w których komórki wytrzymują kilka tysięcy cykli zapisu w porównaniu do TLC, które wytrzymują kilkaset cykli".
W Arduino karty zużywają się właśnie jeszcze szybciej przy drobnych zapisach, zapisując sektor na 50 x10 bajtów zapisujemy go 50x cały. Może być tak, że nie zapiszemy karty ani razu do pełna i będzie szrotem. Szczególnie robiąc to z częstotliwością 100Hz.
Niech Pan sobie dalej żyje w swoim wyimaginowanym świecie i kopie się z rzeczywistością, popatrzę z boku.
 
Odpowiedź
#13
(16-07-2018, 18:33)kaczakat napisał(a): że mają jakieś zarządzanie ilością zapisów itd.
Proponuje się dokształcić i zastanowić jakim sposobem można odzyskać skasowane pliki, które teoretycznie zostały nadpisane.
- uC: ARM Angel , AVR, Z8, PIC, 8051 / CPU: MC680x0  , Z-80, 6502
- CPLD, FPGA, GAL
- GSM, ISDN, ETH, USB, RS232C/485/422
- C, ASM, CUPL, PHP, BASIC C-64

http://er-mik.prv.pl/projekty_avt.php * http://er-mik.prv.pl/ * http://kolejki.prv.pl/

KA-NUCLEO-F411CE Idea , ESP32, Mega2560, UNO PLUS
 
Odpowiedź
#14
Jeśli macie koledzy problem z funkcją millis(), bo ja rozumiem że 2^32 to jest niewielka liczba (dla Was), to można ją w każdej chwili zresetować. Rozumiem też, że dla projektów, w których istotne jest mierzenie czasu, nie instalujecie RTC (no bo po co?).

Procedura wygląda tak:
Kod:
//Deklaracja zmiennych
extern volatile unsigned long timer0_millis;

Potem gdzieś w jakiejś pętli sprawdzamy tą nieszczęsną millis().
Jeśli chcemy reset co sekundę:
(można też co jedną milisekundę, jak co poniektórzy się upierają) 

Kod:
if (millis() >= 1000){
noInterrupts ();
timer0_millis = 0;
interrupts ();
}

W ten sposób możemy resetować wartość zmiennej millis i ustawiać każdą wartość 32bit.
Oczywiście w normalnych warunkach, gdy zmienna millis osiągnie 4 294 967 296, to po prostu zostanie wyzerowana i odliczanie nastąpi od początku. Nie nastąpi koniec świata, jak niektórzy użytkownicy tego forum by sobie życzyli.
Gdy ktoś chce odliczać wielkie interwały, to nie musi stosować powyższego kodu, tylko sprawdzać, czy millis się nie przepełniło, a jeśli tak to inkrementować jakąś zmienną, lub co innego tam zaznaczyć.
Można na przykład założyć, że:
{49 dni
 17 godzin
 2 minuty
 47 sekund
 296 milisekund}
to jest epoka Arduino i liczyć kolejne epoki.
Na prawdę funkcja millis() nie jest jakimś potworkiem i jego używanie nie jest problemem.
Nie prawdą jest też, że:

es2 napisał(a):Ten co wymyślił millis musiał być kretynem albo naćpany. 
I jeszcze jedno:
es2 napisał(a):Problem przepełniania jest o czym niejedne już się dowiedział. Co się stanie jak czekając np 60 minut, użyję rozkazów:
x=millis() + 60*60*1000;
if( millis() > x )
a millis będzie równe 0xFFFFFF00 ? 

Równie dobrze można zapytać, co się stanie:
char x, y;
x = y + 250;
a y będzie równe 10 ???????????????????????
No masz babo placek.
Jeśli masz problem z kodem lub sprzętem, zadaj pytanie na forum. Nie odpowiadam na PW, jeśli nie dotyczą one spraw forum lub innych tematów prywatnych.

[Obrazek: SsIndaG.jpg]
 
Odpowiedź
#15
Ja nie mam żadnego problemu z millis, ale jednak tak całkowicie to nie można ignorować jej właściwości. Może się zdarzyć, że jeśli jest nieodpowiednio użyta, nawet używana tak jak przeze mnie tylko do odliczania 100ms czy 1s ify się nie spełnią i program przestanie działać po 49 dniach.
Rozwiązaniem jest stosowanie rzutowania wyniku z popularnego przykładu:
if ((unsigned long)(currentMillis - previousMillis) >= interval) , używanie tu zmiennych UL, a wtedy nie uronimy żadnej ms. Nawet jeśli to trwa pierdylion cykli na AVR, oszczędzamy lata na pisaniu bibliotek, przechodzimy od razu do zabawy i wg mnie jest super.
Jest to opisane tutaj: https://www.baldengineer.com/arduino-how...illis.html i autor odradza reset licznika, bo millis są używane przez wiele bibliotek, może to im zrobić kuku.
 
Odpowiedź
#16
No jeżeli millis jest używane prze wiele bibliotek, to zgodnie z tym co napisałeś, w przypadku resetu, kuku nie powinno się stać. A jeśli powinno, to stanie się to w momencie przepełnienia millis. (Chociaż nie wiem, bo jeszcze nie wypiłem kawy i nie chce mi się myśleć)
Problem sprowadza się do tego, że dane mają swoje typy, bo jak mamy pętlę:

Kod:
while(0){
unsigned int x;
...
...
...
if(x > 4294967295) break;
x++;
}

To nigdy nie wyjdziemy z pętli i nie mogę powiedzieć, że koleś, który wymyślił, że sizeof( unsigned int ) == 4294967295 jest idiotą. To autor kodu nie zna C/C++.

A co się tyczy nieodpowiednio użytej funkcji, to mamy taki przykład z życia wzięty.

Cytat:
Kod:
if ((zakresCzas >= zakres1) && (zakresCzas < zakres2))
   {
 digitalWrite(PRZEK_1, ON);
  }else{
    digitalWrite(PRZEK_1, OFF);
  }
Mam coś takiego. Ustawiam czas OD zakres1 DO zakres2 i chcę, aby przekaźnik włączał się od - do a poza zakresem był wyłączony. Wszystko działa jak zakres1, czyli godzina jest wcześniejsza od godziny zakres2, ale jak ustawie np., że ma działać OD 22:15 DO 07:30 to niestety już nie.

No bo jak pociąg do Poznania wyrusza o 23:50, a pociąg do Gdańska 25 minut po nim, to skąd system wie, że odjazd będzie o 00:15, skoro 00 jest mniejsze od 23 ???
To nie jest tak, że programista źle porównuje zmienne. Bo wtedy musimy sobie zadać pytanie, czy na pewno mamy do czynienia z programistą?
Jeśli masz problem z kodem lub sprzętem, zadaj pytanie na forum. Nie odpowiadam na PW, jeśli nie dotyczą one spraw forum lub innych tematów prywatnych.

[Obrazek: SsIndaG.jpg]
 
Odpowiedź
#17
(18-07-2018, 07:14)Robson Kerman napisał(a): No jeżeli millis jest używane prze wiele bibliotek, to zgodnie z tym co napisałeś, w przypadku resetu, kuku nie powinno się stać. A jeśli powinno, to stanie się to w momencie przepełnienia millis.
Może być gorzej, warunek nigdy się nie spełni:
Kod:
t=millis()+60*60*1000; //godzina
if( millis() > t ) ....
a inna biblioteka resetuje:
Kod:
t_xxxx = 0; // resetowanie millis
t2 = millis()+60*1000; // minuta
if( millis() > t2 )...
O tym ile takie porównania pochłaniają pamięci programu i czasu uC już pisałem. Przerwanie 1ms i indywidualne timera dla każdego zadania w 99,9% działają szybciej niż porównywanie millis, zajmują mniej pamięci, nie przepełniają się NIGDY, NIGDY tez nie zakłócają pracy innych zadań.

Nie widzę sensu naprawiania millis różnymi metodami, bo nadal ma to wady w postaci objętości kodu i czasu działania a Arduino to przeważnie powolny AVR z małą ilością pamięci programu a zwłaszcza pamięci RAM. 2kB w UNO nie pozwalają na zrobienie sensownych buforów nadawczych dla USART, SPI, I2C. Nie ma możliwości aby w prosty sposób obsłużyć na przerwaniach wysyłanie danych do LCD mono 128x128 bo brakuje pamięci.
Mega2560 ratuje sytuację, ale wystarczy, że obsługuję 2xSPI, 3xUSART, LCD po I2C i znów zaczyna brakować pamięci (LCD 2kB, SPI 2kB, USART 3kB). Jedyny sensowny, jeśli chodzi o RAM, AVR z rodziny MEGA to 1284 z 16kB.
Właśnie brak RAM (zewnętrzny pożera nawet 18 pinów uC) oraz "_P", "_PF", "PROGMEM" brak DOUBLE, ograniczenia niektórych funkcji do 16-bit spowodowały to, że zrezygnowałem z AVR.
Na ARm program pisze się mniej więcej 2 razy szybciej niż na AVR. Pisze o sensownym programie a nie miganiu diodą.
- uC: ARM Angel , AVR, Z8, PIC, 8051 / CPU: MC680x0  , Z-80, 6502
- CPLD, FPGA, GAL
- GSM, ISDN, ETH, USB, RS232C/485/422
- C, ASM, CUPL, PHP, BASIC C-64

http://er-mik.prv.pl/projekty_avt.php * http://er-mik.prv.pl/ * http://kolejki.prv.pl/

KA-NUCLEO-F411CE Idea , ESP32, Mega2560, UNO PLUS
 
Odpowiedź
#18
Nie widzę sensu jeżdżenia tramwajem.
Jest duży i ciężki. Rano jest w nim ciasno. Tramwajem nie dojadę z Warszawy do Ożarowa. Co kilka minut się zatrzymuje, nie ma klimy, nawigacji, internetu, radia i podgrzewanych siedzeń.
To właśnie brak tych udogodnień spowodował, że kupiłem sobie samochód (mercedesa zresztą).
Jadę tam gdzie chcę i kiedy chcę, mam radio z DVD i siedzenia z masażem. Samochodem jadę dwa razy szybciej niż tramwajem i piszę tu o sensownej jeździe, na przykład na urlop, a nie o dojeżdżaniu na studia.
I dziwi mnie to, że ogromna większość studentów, znając przytłaczające wady tramwaju, wciąż dojeżdża nim na uczelnię.

To tyle, odnośnie Arduino i ARM.
Jeśli masz problem z kodem lub sprzętem, zadaj pytanie na forum. Nie odpowiadam na PW, jeśli nie dotyczą one spraw forum lub innych tematów prywatnych.

[Obrazek: SsIndaG.jpg]
 
Odpowiedź
#19
(18-07-2018, 14:35)Robson Kerman napisał(a): Nie widzę sensu jeżdżenia tramwajem.
(...)nie ma klimy, nawigacji, internetu

W Wa-wie ma.
- uC: ARM Angel , AVR, Z8, PIC, 8051 / CPU: MC680x0  , Z-80, 6502
- CPLD, FPGA, GAL
- GSM, ISDN, ETH, USB, RS232C/485/422
- C, ASM, CUPL, PHP, BASIC C-64

http://er-mik.prv.pl/projekty_avt.php * http://er-mik.prv.pl/ * http://kolejki.prv.pl/

KA-NUCLEO-F411CE Idea , ESP32, Mega2560, UNO PLUS
 
Odpowiedź
  


Skocz do:


Przeglądający: 1 gości