Är AVR rätt för mig om jag ska bygga små system?

[Klas-Kenny]

Bara för att de flesta 32bitars MCUer har många avancerade periferienheter, betyder inte det att du måste använda dem.

För att blinka en lysdiod med en STM32 eller annan ARM, eller PIC32 eller vad som helst, så behövs marginellt mer kod än för att göra samma sak på en AVR.
Detta förutsatt att man gör det direkt mot register, istället för att använda tillverkarens HAL-drivare. Då blir det ofta mer kod för initiering och liknande, men kanske bättre läsbarhet. Men det går lika bra att jobba direkt mot hårdvaruregister i avancerade MCUer som i enklare AVR.

Enda stora skillnaden är att istället för ett enda diskret datablad på några hundra sidor, så har man en referensmanual på kanske 1000-2000 sidor att bläddra i, för att det finns så mycket hårdvara att beskriva.

Just detta var min största tröskel när jag började med ARM för ett antal år sen, ifrån att ha använt 8bit PIC.
Jag insåg inte att det fanns en referensmanual, utan jag kollade bara databladet som är väldigt knapphändigt på annan information än rent elektrisk. Sen hittade jag genom Google, en massa info om hur man gjorde saker medelst HAL-drivarna. Som måttligt erfaren programmerare så tyckte jag att dessa var superkrångliga, och där med blev även ARM väldigt krångligt...

Efter att ha hittat referensmanualen och börjat göra saker direkt mot hårdvara istället så släppte det hela ordentligt.


Men nu kommer ju du ifrån andra hållet. Jag kom ifrån 8bit PIC vilket jag lärde mig i Assembler, och sen gick över till C. Sen till ARM. Du verkar ju mer komma ifrån högnivåspråk och gå nedåt, så då kanske det å andra sidan passar bättre att använda HAL-drivare och annat jox.

[Al_Bundy]

Det finns en gammal väletablerad sanning som går något i stil med "En genväg är ofta en senväg." och det gäller troligen Arduino, STCube och liknande.

Eller om man tar en annan gammal sanning "Det kan vara varmt och skönt att pissa på sig men efter ett tag blir det kallt och obehagligt.".

Man kan nästan tro att du är en japan från Amerikanska 90-tals filmer som hela tiden talar i gåtor1. Är STCube något som förenklar och förblindar?

[Al_Bundy]

Men nu kommer ju du ifrån andra hållet. Jag kom ifrån 8bit PIC vilket jag lärde mig i Assembler, och sen gick över till C. Sen till ARM. Du verkar ju mer komma ifrån högnivåspråk och gå nedåt, så då kanske det å andra sidan passar bättre att använda HAL-drivare och annat jox.

Jag är van med högnivåspråk då jag anser att man ska inte behöva uppfinna hjulet på nytt. Men ibland behöver man gå ned på de djupaste för att få saker och ting effektivt. Då är det C som gäller.

[Al_Bundy]

Ok, det låter som du redan växt ur Arduinomiljön alternativt gett upp för lätt (dvs förlitat dig på delay/sleep istf för köra event/timer-styrt).

Då är väl nästa steg att köra en gcc/g++ för AVR och en programmerare för AVR (vilket kan väl vara en Arduino om jag minns rätt)?

CAN: Det går säkert att bit-banga CAN men då du är snabbt tillbaka till tidsåtgången för att få något utfört men ifall du skulle ge dig på det så skulle du lära dig en massa och kanske tom kunna lösa en uppgift med halva hårdvarukostnaden vilket kan vara intressant ifall volymen är tillräckligt stor.

För att kunna ge bättre råd så skulle jag behöva veta syftet med kunskapstörsten. Vill du blir mer anställningsbar? I så fall av vem? Starta eget och göra egna produkter som säljs i 10-tal eller i 100000-tal? Bli konsult med specialisttimlön?

Jag jobbar redan som konsult inom hydraulikbranschen. Jobbar mycket åt Hydac.
Jag jobbar mycket inom experiment, väldigt mycket. Så här gäller det att hitta snabba lösningar till ett bra pris som ska verkligen fungera alla dagar.

Därför valde jag Java. Men Java är inte det snabbaste. Kanske en AVR hjälper mig då, tänkte jag.
Då tänkte jag att om jag använder Java för huvudenheten och AVR som gör det tråkiga jobbet som kräver snabbhet?

[mankan]

Experiment och snabba lösningar tolkar jag som du inte har tid att optimera kod för att använda mindre RAM eller flash. Mao så ändrar jag min rekommendation till ARM/STM32 före AVR alla dagar i veckan.

Ett annat alternativ är att förstås göra egna C/C++-utökningar till miljön som redan kör Java.

[Al_Bundy]

Okej. Så utvecklingstiden är kortare i STM32 jämfört med AVR?

[mankan]

Hur långt är ett snöre?

Det beror på helt din förmåga och problem du ska lösa.

Som sagts tidigare det är svårare att sätta upp en STM32 helt själv från C/C++ eller lära sig STs jox för HAL-setup jämfört med att åstadkomma samma sak på en AVR. Men om din "bloatiga" kod inte får plats i AVR:n får du spendera massa tid på att förstå vilka kodkonstruktioner som kostar flash och RAM och det kommer ta en hel del tid för dig som kommer från Javahållet.

Förresten vilken Arduinomiljö har du kört? Den klassiska Atmega328p? Eller något mer kraftfullt?

[Al_Bundy]

ATmega328 körde jag. Tyckte det var bra minne där. Jag hade en stor LCD 128x64 led + massa givare + massa relän osv. Fick plats.

Jag hade mest tänkt att använda AVR som gör det tråkiga jobbet t.ex PID reglering eller annat monotona arbeten t.ex en liten LCD 16x2 som visar temperatur.

Varför ens ska jag belasta huvudenheten med sådant?

[Glattnos]

Jag vet inte men om det är experiment och viktigt att det är driftsäkert så är väl AVR 8-bit inte så dumt? Går på 5V och tål rätt mycket stryk på I/O-pinnarna. Kan även driva 20mA direkt på pinnarna.

[Al_Bundy]

Ja. AVR är inte dumt. Lite tråkigt att det är 8 bit på PWM och 10 bit på ADC, men sådant är sådant man får leva med? Om det inte finns nya AVR kretsar som erbjuder lite bättre precision?

[Micke_s]

Kör avr om det passar.

https://www.conrad.se/p/plc-styrningsmo ... 4&vat=true

[Al_Bundy]

Eller detta?
https://www.wish.com/search/stm32/produ ... rce=search

[Al_Bundy]

Kör avr om det passar.

https://www.conrad.se/p/plc-styrningsmo ... 4&vat=true

Jag ska inte implementera något Jag jobbar med utveckling och då är det viktigt att det är fungerar och det går att utveckla snabbt. Arduino är ett alternativ, men i detta fall är Arduino för segt för mig. Därför har jag gått ifrån det.

Raspberry Pi med Java har jag lyckats att sälja åt mina kunder. Så jag fortsätter med det.
Nu är det kunder som vill ha en CAN bus styrning och det ska vara specialanpassat. Då tror jag att jag måste använda mig av C och köra på djupet för att få det snabbt. När jag menar snabbt så menar jag att om jag säger att uC: ska göra 50 ms paus, så ska den göra det. Arduino gör mer än 50 ms paus. Bara det säger att Arduino lämpar sig inte för precision.

AVR och STM32 är goda alternativ för mig. SMT32 har dessutom CAN bus inbyggt, vilket låter lockande.
Men samtidigt så tar AVR mycket liten plats jämfört med ett fett STM32 kort och AVR är mer enklare att jobba med, enligt vad högre makter på forumet säger. Men samtidigt så finns det IC-kretsar som kan det där med CAN.

Så mitt val blir AVR av just att jag behöver något litet att arbeta med.

[Micke_s]

STM32 behöver inte ta så mycket plats.

48UQFN 7x7mm
https://www.digikey.com/product-detail/ ... ND/6621834

[Al_Bundy]

Jag kan ändra mig (som vanligt) om någon annan har bättre alternativ. Men ditt alternativ kräver att jag börjar löda fast denna uC också. Jag vill helst ha DIP-format, men jag kan acceptera SODIP eller vad dem kallas, på ett kretskort som man sedan löder fast, vilket inte blir snyggt alls. Men vadå? Det är ju bara utveckling.

Jag tror fortfarande att AVR är rätt för mig. Dels för att det är viktigt att lära sig den teoretiska grunden hur en uC fungerar, samt att AVR är rätt så kompakt och man kan in princip köra en helt naken AVR utan kristall eller något annat störande så som resistorer och kondensatorer. Men visst, AVR är segare och trögare än en ARM samt ARM är mer "modern" och har bättre precision än AVR.

Men jag är bara ute efter liten styrning som ska göra det tråkiga jobbet. Motivera om jag har fel.