[nobody]

Pai vendorii is permit AI enhacend crapware.

Pentru AVR am mai folosit un compilator dragut, culmea facut in Romanai: http://www.hpinfotech.ro/cvavr-features.html
Merge mai bine ca GCC, mai ailes la constantele stocate in FLASH.
Arduino iti face buffer overflow la stringuri daca n-ai grija, le trateaza ca obiecte, le tot muta si rasmuta pana ajunge de-ti scrie si peste registrii si IO. Cand am facut debugging si m-am uitat in surse, n-avea nici o urma de protectie in bibliotecile de baza. This sht is not for me. Scuze de divagatie, eu am facut scoala pe Z80. 16k ROM, 6k video RAM, si restu pana la 64k, RAM liber.

Ca senzor as alege unu ce are o interfata standad hardware, i2C, SPI, nu bit-bang. Iti mai salveaza timp de procesor si mai putine sanse de rateuri la comunicatie.

[zoth]

[varadinagypal]

offtopic, dar na, am pornit ceva aici,

Sunt putin mai tinerel se pare, eu am inceput cu asm x86 pe de o parte, si citind codul sursa de librarii din delphi proaspat aparut pe cealalta parte. De aceea recunosc cand cineva bate campii ca legacy code, dar pe vremea aia era bun - nu, nene, nici in urma cu treizeci de ani nu se scriau balarii cum intalnesc mai peste tot.

Eh, stringuri, folosesc exclusiv partea de C in arduino, pana si cu ESP32. Fara C++, tocmai ca sa nu am surprize. Am dispozitive care ruleaza brici de luni de zile, si se reseteaza doar cand se ia curentul. Iar cu constantele in flash, subscriu, am mai scris cod javascript ca sa genereze cod C in diferite gusturi: cu FP, cu concatenari sau zstringuri ca sa vad cand cum arata binarul respectiv ramii disponibili.

La locul lor, sunt dispozitive foarte mega capabile jucariile astea arduino. Iar legat de vendorii profi, va pot arata document public de la Renesas in care le cere utilizatorilor sa nu foloseasca mijlocul ramilor daca cpu ruleaza la 240MHz ca apar flag-uri de paritate, nu si erori, dar flag-uri.

[valy]

Tot offtopic, dar cred ca Arduino este mai curand pt. rapid prototyping, nefiind un sistem sa zicem "critical mission aerospace grade"...totusi.

[nobody]

Rezonatorul ala ceramic iti baga un drift care se acumuleaza in timp.
Toleranta la asta folosit pe Arduino e de +-0.5% ... nu pare mult la prima vedere, dar un ceas cu pendula e mult mai precis.
Culmea e ca la procesorul cu USB de pe aceeasi placa au folosit un cuart de aceeasi frecventa... de ce ?
Pentru ca in toleranta aia nu ar functiona partea de USB.
Si tot culmea este ca puteau folosi acel clock si la procesorul principal, ca are iesire de buffered clock pe un pin care sta nefolosit.
Adica o carpeala hardware.

Pe forumuri raspunsul este "da la ce-ti trebuie asa precizie?" ... ca sa reglez un ceas cu cuc, nu invers.

Nu stiu de ce "sarea pasi" la tine, nu cred ca are legatura cu acest drift, poate altceva, de exemplu milisecunda bisecta Arduino:
millis() is incremented (for 16 MHz AVR chips and some others) every 1.024 milliseconds, then incrementing by 2 (rather than 1) every 41 or 42 ticks, to pull it back into synch; thus some millis() values are skipped

[valy]

Parca am folosit micros(), nu mai stiu exact..

Nu e o gresala in specs, milis se incrementeaza la 1024 microseconds?

[varadinagypal]

Legat de Arduino, eu as aprecia aspectul ca exista in primul rand ca idee. E un layer de abstractizare, un standard chiar portabil, decent pentru serial, decent pentru i2c, decent pentru GPIO, decent pentru intreruperi si decent pentru timp. Nu e aero-space-medical-automotiv ready, si ce, nici nu pretinde ca ar fi, deci e within specs. Au si familia Portenta.

Function/prototype hoisting cand ai un singur fisier, sau macar in cadrul aceluias fisier, la fel mi se pare o idee buna. Deci serios, warning: implicit declaration of function cand e acolo cu trei linii mai jos? Who needs that? Am vazut cod serios stricand stackul la variadic arguments, ca insista ca functia din acelasi fisier nu ar avea antetul declarat, si zbam, byebye double, ca remapat la int32 (arhitectura) si arrivederci stack.

Plus, sa nu uitam ca ESP32 are nucleu Arduino, are si microul RP2040, nu e doar familia AVR.

Nu vreti sa stiti cate artificii am vazut in cod "profi", cat scarpinat la picioare de lemn, roti reinventate sub forma nitel patratica, las' ca merge si asa, si pentru ca acei genii - stiti voi, garda veche - nu au scris absolut niciun layer de abstractizare, functii inline macar, macrouri macar, ci au trantit copy-paste-paste-paste dar cu variabilele locale pe unde si ce, cateodata shadowed global, cateodata nu, ca "economisim la callstack", nici dumnezeul nu mai face ca acel business logic sa ruleze pe alt micro fara sa rescrii din temelie.

Daca e sa aleg intre Arduino si demiurgii din garda veche (in afara de chiar top gen Knuth si din astia, ori cu kernelul), aleg Arduino x100.

[varadinagypal]

Oh, Renesas Synergy mai e cat de cat decent ca RTOS, cu niste mentiuni de rigoare: timpul e un pain in the ass, calibrarea rtc-ului e un pain in the ass, filesystem-ul e un pain in the ass la patrat rau de tot, networking-ul e un pain in the ass ca-i poti otravi lejer packet pool-ul, plus, acum s-a bagat microsoft, ca nu au stricat deja destul in lume, isi mai acapareaza domenii de stricat. Dar siliconul e acceptabil. Am mai pomenit de parity in rami.

Ei, arduino uno rev4 e bazat pe silicon renesas, nu mai e avr. DAR: ramane interfata soft. Pentru ca e una sa numeri bitii din registri si alta sa scrii programe, ie business logic.

[nobody]

La UNO R4 au rezolvat cu cuartu' ... l-au scos de tot ... au trecut pe oscilatorul intern +-2%

P.S. Pentru mine ideea de 'microcontroller' este legata de 'real-time operating'. Mi se apre ca Arduino se indeparteaza de acest concept tocmai pe principiul 'las' ca merge si asa'.

[varadinagypal]

@nobody si ceilalti, va invit la acest fir din forum, pentru a-i lasa aer colegului cu proiectul, ca ne-am cam bagat peste el ca niste derbedei cu offtopic-ul nostru

https://www.astronomy.ro/forum/viewtopic.php?p=230039

[AVD]

Dupa ceva timp de lucrat si testat, am revenit cu versiunea 2. Imbunatatita si rafinata.


https://github.com/florindumitrescu94/DashBoard_PowerBox_V2

Imbunatatiri fata de prima versiune:

-Cate o siguranta resetabila de 2.5A pe fiecare iesire si o siguranta mare de 15A pe intrare
-Protectie la tensiune inversa
-Comutatie a celor 4 mufe DC prin P-MOS
-Automatizare a incalzitoarelor anti-roua (momentan, doar prin atasarea unor termistori ce vor fi montati sub incalzitoare, dar planuiesc sa gasesc o metoda de a controla puterea doar pe baza conditiilor atmosferice (dew point, umiditate relativa si temperatura ambientala)


Documentatia completa poate fi gasita pe pagina Wiki.

varadinagypal - Multumesc de sugestiile si exemplele de documentatie. Sper ca am facut o treaba macar pe jumatate buna cu aceasta noua versiune

Orice sugestie este binevenita
Spor la construit!

[varadinagypal]

da

[nobody]

Felicitari pentru progresele de la Layer 1 !

Acu' la layere superioare:

[AVD]

Mulțumesc!

Și mulțumesc de observația legata de timpul între ciclurile de rulare ale Get_power.. nu mi-am dat seama ca vor fi câteva milisecunde pierdute în care nu masor nimic. Legat de precizie, am încercat sa atribui unei variabile raportul a altor doua variabile, care îmi rezulta 0.9834(..). În momentul când am folosit acea variabila intr-o formula, a fost tratata ca 0.1. Când am încercat sa folosesc un calcul care sa îmi măsoare energia consumata direct în Wh, din nou, m-am lovit de aceeași problema. Energia consumata în 20mS era 0.000ceva. Formula folosita anterior era energia_totala += (puterea*delta_t)/3600000. Aceasta formula rezulta 0.000ceva și era trunchiat la 0.00. Pe parcursul întregii seri, energia_totala a rămas 0 (dacă adaugi 0.00 la 0, tot 0 ramane). Scrie lucrul asta și pe site-ul arduino (și double tot aceeași problema are), dar poate nu m-am exprimat eu corect..

Get_power se ocupa de măsurarea tuturor datelor despre energia electrica (curent, tensiune, putere, energie consumata). Am încercat sa fac media curentului intr-un singur ciclu și varia foarte mult, asa ca am mers pe o medie pe un timp mai lung, in care orice schimbare brusca este amortizata.

[nobody]

Ai niste exemple concrete sa le testez ?
O bucata de cod care nu functiona cum te asteptai sau chiar exemple de pe site-ul arduino.

Probleme de genul asta se pot rezolva cu 'type casting', chiar compilatorul iti mai da warning-uri ca este o situatie ambigua. Asta daca nu sunt chiar bug-uri, double e cam buggy in AVR gcc, dar float ar trebui sa functioneze.

P.S.
Daca e vorba de rotunjiri si trunchieri de precizie la float ca aici:
https://forum.arduino.cc/t/strange-float-or-rounding-error/469408
atunci este si o problema de optimizare a formulelor, sau a unitatilor de masura alese.
Float-ul poti sa-l consideri ca o scara logaritmica, rezolutia este relativa la ordinul de marime.
De ex. daca aduni un numar mic la un numar mare, vei pierde din precizie la numarul mic, sau il pierzi chiar de tot.