Förslag på PWM, ADC, I/O och DAC IC kretsar med SPI?

[Janson1]

Daniel: I inlägg 1255 så frågar du dels om ett par grafer, kan du förtydliga det lite bättre och varifrån du hittat det. Och en annan grej är att inte redigera en eller flera gånger så dess faktiska innehåll ändras så mycket att nästkommande svarinlägg blir konstiga pga att inlägget innan är ändrat. Denna gången är det bara tillagt en LED-driver transistor, men gör hellre ett till inlägg än ändra. Ändra bara rena felstavningar/felsyftningar och ange vad som är ändrat per redigeringstillfälle.

[rvl]

inlägg 1255

Det blir Daniels senaste inlägg, just nu, men är inget fungerande sätt att syfta på ett spesifikt inlägg.
Räknaren till vänster anger alltså användarens totala inlägg.

[Janson1]

å f*n det var ju obra... Hur gör man då för att hålla reda på inlägg? ok 2021-03-22 kl 15:07:34 postade Daniel ett inlägg eller redigerade det. Det är detta jag menar.
(Det verkar som forumet saknar numrering av inläggen, bara totalen per användare...) Eller?

[Klas-Kenny]

Hur gör man då för att hålla reda på inlägg?

Använd citat-funktionen. Ger notis till den som blir citerad, och innehåller en länk till det citerade inlägget.
Såklart redigerar man bort allt irrelevant ur citatet, citera inte hela inlägg.

[DanielM]

Daniel: I inlägg 1255 så frågar du dels om ett par grafer, kan du förtydliga det lite bättre och varifrån du hittat det. Och en annan grej är att inte redigera en eller flera gånger så dess faktiska innehåll ändras så mycket att nästkommande svarinlägg blir konstiga pga att inlägget innan är ändrat. Denna gången är det bara tillagt en LED-driver transistor, men gör hellre ett till inlägg än ändra. Ändra bara rena felstavningar/felsyftningar och ange vad som är ändrat per redigeringstillfälle.

Jag sökte bara på "first order system". Jag antar att en OP-amp är uppbygt på ett sådant beteende.

[Janson1]

Jag vet faktiskt inte vad som avses med dom graferna och om man behöver ta hänsyn det? Eftersom det är flera sekunder som avhandlas så skulle det kunna vara utgången på en OP med mosteknik och full ström som visas? Någon som vet?

[TomasL]

Så länge som vi inte vet varifrån bilderna kommer är det ju omöjligt att veta vad de hänsvisar till, kan vara ett stegsvar från precis vad som helst.

[DanielM]

Jag vet faktiskt inte vad som avses med dom graferna och om man behöver ta hänsyn det? Eftersom det är flera sekunder som avhandlas så skulle det kunna vara utgången på en OP med mosteknik och full ström som visas? Någon som vet?

För en erfaren reglertekniker så förstås det att dessa bilder illustrerar bara ett andra och ett första grads stegsvar. Jag tänkte att OP-amp har väll samma utgångstyp som svar.

Om jag har +24 och -24 som gränsnivåer på min Op-amp, då borde jag väll få högre linjäritet nära 0? För en Op-amp har väll den lilla "svansen" vid varje gränsnivå?

[TomasL]

Jag tänkte att OP-amp har väll samma utgångstyp som svar.

Vad får dig att tro det, lär dig hur en OP fungerar, och sluta gissa.

[Rick81]

Om jag har +24 och -24 som gränsnivåer på min Op-amp, då borde jag väll få högre linjäritet nära 0? För en Op-amp har väll den lilla "svansen" vid varje gränsnivå?

Jag förstår inte vad du menar med varje gränsnivå? För OP är 0-48 V samma sak om -24V till +24V bara att potentialen är förflyttad. Överslängen vid stegsvar är beroende på förstärkningen och inte matningsspänningen...

Sen undviker man helst negativa spänningar för de blir krångligare i praktiken.

[DanielM]

Jag menar att det brukar se ut så här. Nu är detta kraftigt överdrivet. Speciellt lutningen.
Så om man navänder V- med negativ spänning, så är man mer inom det linjära området. Jag kan ha fel på detta.

sfd.png

En annan fråga!

Tycker ni att jag ska skriva koden till detta projekt med enbart register, HAL eller CubeMX?
Jag har som mål att lära mig, men om det skiljer sig så mycket med registerprogrammering för alla plattformar så anser jag att det finns ingen motivering att lära sig register då HAL eller CubeMX uppfanns av just den anledningen.

Jag menar, låt oss säga att ena månaden sitter man med Atmel, andra månaden är det STM32 och kanske en annan månad är det ett märke som man inte ens har hört talas som.
Det kanske inte är så i praktiken? Man väljer sin plattform och sedan behåller man den? Det kanske inte finns sådan lyx i verkligheten? Lika väl som programmeringsspråk?
TomasL kör ju bara PIC som jag fick höra från han och PIC är också en utmärkt plattform. Jag kör bara STM32 för jag kan inget annat

Jag har haft en lyx att jag själv får välja verktyg och plattformar, då mina "kunder" eller vad man ska säga, är bara intresserad utav "få igång skiten bara", som de uttryckte en gång
Men min verklighet är inte allas verklighet.

Jag får känslan att skulle jag lära mig programmera register på STM32 så är jag lika grön om jag går över till SiliconLabs, då SiliconLabs kör alltid med HAL verkar det som. Besvärlig HAL dessutom som är konstigt skrivet. Skapade ett Blåtandsprojekt med SiliconLabs...hemskheter vad deras C-kod är rent av dåligt skrivet. Nästan som man får känslan att en nyexaminerad ingenjör ville visa all sin kunskap och därmed överbearbetade HAL-biblioteket för att sedan kunna titta sig i spegelen "Duktig jag är! Jag har skapat ett avancerad biblitek som ingen förstår sig på". Det tog 1 månad innan jag fick biblioteket att fungera.

[mankan]

Jag föreslår att du börjar med CubeMX och sedan bantar ned det till registerskrivningar på de områden du anser att STs HAL inte duger eller de du vill lära dig. Då kan du få igång något snabbt och sedan har du en referens du vet funkar på hårdvaran när du sedan sitter och registeroptimerar. Så gjorde jag för att snabba upp flashskrivning för STM32L031.

[Mr Andersson]

Det som tar längst tid, men som enligt mig ger bäst platformsoberoende kod, är att göra sin egen HAL.
Sen om din HAL använder tillverkarens egna HAL under skalet eller går direkt på register väljer du själv.
Oftast kan man enligt min erfarenhet använda stora delar av tillverkarnas kod, men gör först några sökningar på google och deras egna supportforum om funktionerna du har tänkt använda har några kända buggar och skriv egen kod för att komma runt dem i så fall. Bara för att buggarna är rapporterade betyder det inte att de snabbt blir fixade.

Då kan du ta samma applikationskod och köra på valfri mcu med minimala ändringar.
Det tar som sagt mer tid, men det är en engångsinvestering. Sen går det mycket fortare att porta själva applikationen.

Eller så bestämmer du att du alltid kommer köra ST och anpassar koden efter det. Risken att ST kommer sluta tillverka STM32 är nog ganska liten. Dock inte obefintlig. Kommer bli intressant att se vad som händer i ARM-jungeln om nvidia-affären blir godkänd.

[DanielM]

Jag föreslår att du börjar med CubeMX och sedan bantar ned det till registerskrivningar på de områden du anser att STs HAL inte duger eller de du vill lära dig. Då kan du få igång något snabbt och sedan har du en referens du vet funkar på hårdvaran när du sedan sitter och registeroptimerar. Så gjorde jag för att snabba upp flashskrivning för STM32L031.

Jag har kört mycket med CubeMX. Jag gillar det. Så enkelt och koden blir så ren.
Fast om man ska optimera för att få snabbhet, är det inte bättre att börja då med en snabbare processor?

Det som tar längst tid, men som enligt mig ger bäst platformsoberoende kod, är att göra sin egen HAL.
Sen om din HAL använder tillverkarens egna HAL under skalet eller går direkt på register väljer du själv.
Oftast kan man enligt min erfarenhet använda stora delar av tillverkarnas kod, men gör först några sökningar på google och deras egna supportforum om funktionerna du har tänkt använda har några kända buggar och skriv egen kod för att komma runt dem i så fall. Bara för att buggarna är rapporterade betyder det inte att de snabbt blir fixade.

Då kan du ta samma applikationskod och köra på valfri mcu med minimala ändringar.
Det tar som sagt mer tid, men det är en engångsinvestering. Sen går det mycket fortare att porta själva applikationen.

Eller så bestämmer du att du alltid kommer köra ST och anpassar koden efter det. Risken att ST kommer sluta tillverka STM32 är nog ganska liten. Dock inte obefintlig. Kommer bli intressant att se vad som händer i ARM-jungeln om nvidia-affären blir godkänd.

Plattformsoberoende kod? För alla ARM eller för alla STM32?

ST har själv sagt att dom rekommenderar CubeMX istället för att skriva egen HAL.

ST har även STM8 för CubeMX

ARM-jungel och Nvidia-affären? Jag har hört att Nvidia vill köpa ARM, men hur ska det påverka STM32? En STM32 är en STM32, oavsett om det är ARM eller inte.

Hur brukar det se ut i verkligheten för de som programmerar mycket hårdvara? Är det registerprogrammering eller finns det färdigt HAL för varje processor?

[Mr Andersson]

> Plattformsoberoende kod? För alla ARM eller för alla STM32?
Alla mcu:er. Byter du processor portar du din HAL och lämnar applikationskoden som den är.
Det kan tyckas vara ett jättejobb att göra en egen om man ser på hur mycket som brukar finnas i tillverkarnas egna, men det räcker ju att skriva kod för de funktioner man faktiskt använder. Det går alltid att lägga till nya funktioner senare om de behövs.

> ST har själv sagt att dom rekommenderar CubeMX istället för att skriva egen HAL.
Självklart säger de (och andra tillverkare) så. Ju mer investerad i deras kod man är desto mindre risk för dem att man byter märke till nästa projekt.
Kolla valfri tillverkares supportforum för buggrapporter i deras kod. Det är ofta skrämmande många.
Tillverkarkod skrivs primärt för att vara lättanvänd för att en användare snabbt ska komma igång. Optimering och korrekthet kommer i andra hand.

> ARM-jungel och Nvidia-affären? Jag har hört att Nvidia vill köpa ARM, men hur ska det påverka STM32? En STM32 är en STM32, oavsett om det är ARM eller inte.
Den som äger ARM styr vem/vilka som får IP-licenser samt hur mycket de kostar. Det kommer inte påverka redan existerande mcu:er men det kan påverka om framtida produkter kommer vara bakåtkompatibla eller inte.