Mikrocontroller mit DAC?

Dieter H. schrieb:
> Kann ich einfach einen PWM Ausgang mit einem Tiefpass (RC) glätten?

Ja, das ist eine durchaus übliche Variante.

Es gibt aber auch ausreichend Controller mit parallelem DAC.

Jörg W. schrieb:
> Dieter H. schrieb:
>> Kann ich einfach einen PWM Ausgang mit einem Tiefpass (RC) glätten?
>
> Ja, das ist eine durchaus übliche Variante.
>
> Es gibt aber auch ausreichend Controller mit parallelem DAC.

Kannst du mir ein paar uCs nennen? Gibt es da AVRs oder PICs? STMs 
kriegt man ja gerade gar nicht.

Dieter H. schrieb:
> Kannst du mir ein paar uCs nennen?

Wenn es keine STMs gibt, dann schau dich einfach bei anderen Herstellern 
um. Spontan fiele mir SAMD21 und dessen Verwandte ein, aber das liegt 
jetzt auch nur daran, dass ich da schon mal irgendwann das Datenblatt 
vor der Nase hatte und mich daher dran erinnern kann.

Hallo,

AVR DA Serie ... 10Bit
AVR DB Serie ... 10Bit
AVR tinyAVR 1er Serie ...8Bit
Oder externen DAC mittels I2C oder SPI.
Tiefpass geht natürlich auch, wenn die Anforderung moderat ist.

AVR XMEGA mit 12 Bit DAC 
http://ww1.microchip.com/downloads/en/appnotes/doc8033.pdf

Und die MSP430 bei TI können dies alle auch ;-)

Und wenn du es Richtig machst giebt's Einzelstücke sogar direkt bei TI 
als Free sample.
[Humor]
Bitte nicht Schlagen wenn ich nicht auch AVR oder PIC schreie ..GRINS..
[/Humor]
Aber es gibt auch die allseits beliebten TI-Launchpads ;-)

Patrick L. schrieb:
> Und die MSP430 bei TI können dies alle auch ;-)

Bei denen muss man aber erstmal ein paar Dutzend Seiten Errata 
studieren, ob davon der konkrete Anwendungsfall vielleicht jetzt 
betroffen ist.

Das hat mich schon etwas geschockt, als ich das erste Mal mit den Teilen 
zu tun hatte.

Jörg W. schrieb:
> Das hat mich schon etwas geschockt, als ich das erste Mal mit den Teilen
> zu tun hatte.

Na es Gibt wenigstens dank den XMSP's auch Errata's, bei vielen anderen 
MPU's geht's einfach nicht und keiner weis warum ;-)
Dazu sind wir als Fremdfirmen-Betatester da, die von TI im 
Unterstützerteam sind;-)

Nee wenn man ein Aktuellen und von TI supported Kompiler verwendet, muss 
man sich nicht um die Errata kümmern, denn das macht der Kompiler für 
dich.

Natürlich nur wenn man auch eine aktuelle Version hat.

Patrick L. schrieb:
> Nee wenn man ein Aktuellen und von TI supported Kompiler verwendet, muss
> man sich nicht um die Errata kümmern, denn das macht der Kompiler für
> dich.

Wie kümmert sich ein Compiler drum, wenn man einen Timer nicht während 
des Betriebs sicher auslesen kann, ohne ihn vorher anzuhalten? Baut der 
Compiler dann automatisch Code ein, der den Timer kurz stoppt? Das würde 
mir anders über die Hutschnur gehen …

Jörg W. schrieb:
> Wie kümmert sich ein Compiler drum,

Je nach Errata bzw Bug.
IAR zum Beispiel, aus Erfahrung:
BUG "insert a Nop bevore Set General Interrupt Enable bit"
generierter Code:

1

NOP                       ; If important on Architectur of MSP430FR2355 boefore GIE set!

2

bis.b   #GIE+CPUOFF,SR    ; Set General Interrupt Enable bit

Sprich Kompiler fügt es selber ein

Dein genanntes oder ähnliches:
Kompiler gibt Warnung aus und macht dich auf den Bug aufmerksam.
Schlägt oft wen möglich, auch grad Lösung vor.

In den Errata's steht das übrigens auch welche Kompiler diesen Bug 
selber und wie lösen, oder dir ein Lösungsvorschlag unterbreiten.

Mittlerweile sind da sogar auch GNU Kompiler mit erwähnt.

Ich für mein Teil lese aus Prinzip zuerst Datenblatt und allenfalls das 
Errata wenn ich ein "Livesupported Design" mache, ansonsten würde mir 
der QM was Husten.

Jeder  MPU Kennt Bug's
In PIC wimmelte es, als ich den noch verwendete und ein Errata gab's in 
dem sinne noch nicht. AVR's kennen auch längere Erratas (Wurde an 
anderer Stelle hier im Forum aber auch schon von Nutzern Zitiert)
Ja selbst in Intels usw.

Es ist nicht Grundlos das die TI MSP430 zu den wenigen MPU's gehören die 
FDI Zulassungen haben. Ein PIC würde es beispielsweise wohl eher nicht 
in einen Herzschrittmacher schaffen.

PSoC schrieb:
> Zwar nicht der günstigste aber sehr komfortabel bzgl. DAC sind auch die
> PSoc5LP von Infineon/Cypress.

Konfortabel >> Voellig einverstanden
Nicht der Günstigste >> Fuer einige exempleren sehr billig

Also fuer $10 bekommt man ein kit genennt CY8CKIT059, processorboard 
PSOC-5lp MIT abbrechbaren Programmer. Enthaelt ARM prozessor 4 Voltage 
DACs, 4 Strom-DACs, 2 SAR-ADCs, 1 High-precision Delta-Sigma ADC der an 
jedem Pin gemultiplexed werden kann und noch viel mehr. Alles on-board 
ohne zusatzliche Komponenten.

Ja, teuerer wird es wenn man der processor auf eine eigene platine haben 
woll, dann kostet er wahrscheinlich mehr als $10 aber fuer hobbie reicht 
oft der CY8CKIT059 (oder einer der andere developer-boards, auch 
verfuerbar mit Anschlusz fuer Arduino-shields)

Patrick aus die Niederlaende.

Patrick L. schrieb:
> Dein genanntes oder ähnliches:
> Kompiler gibt Warnung aus und macht dich auf den Bug aufmerksam.

Na gut, das geht noch.

Allerdings fand ich den Bug selbst (und dass er auf der ewigen 
Weltbestenliste verblieb, ohne Chance, ihn zu reparieren) arg 
bescheuert. Wenn ich einen Timer erst anhalten muss zum sicheren 
Auslesen, dann hat der Hardwaredesigner schlicht was vergeigt 
(Synchronizer verpasst). Das gehört repariert und nicht nur 
dokumentiert.

Damit war das Teil damals für uns praktisch unbrauchbar, denn weder 
zwischenzeitliches Anhalten noch dreimaliges Auslesen wären in dieser 
Anwendung machbar gewesen. Der Kunde, der da unbedingt einen MSP430 drin 
haben wollte, war dann aber eh abgesprungen.

[OT]
Jörg W. schrieb:
> Damit war das Teil damals für uns praktisch unbrauchbar, denn weder
> zwischenzeitliches Anhalten noch dreimaliges Auslesen wären in dieser
> Anwendung machbar gewesen.

Ja tut mir Leid für Dich, hättest du mich gefragt hätte ich dir eine 
bessere Lösung gehabt.
War Tatsächlich da ein Betatester hab noch von den XMSP dieses Bugs hier 
;-)

Beste Lösung (Etwas verrückt aber ging) Timer nicht in RAM oder Register 
Kopieren, sondern in eine andere Pheripherie die du nicht brauchst und 
von dort dann abholen. Ist zwar ein Undokumentierter Workaround (Auf 
mein Vorschlag diesen aufzunehmen Antwort von TI "Zu Komplex für den 
Nutzer")

Ich habe Hier einer mit Integriertem LCD Kontroller, da nutze ich LCD 
Segmentspeicher für solche Sachen, von Pins die eh nicht ausgeführt 
sind.
Obendrein sind die Befehle auch meist schneller als zuerst in ein RAM zu 
kopieren. Manchmal nutze ich auch PIN I/O Pheripherien von nicht 
ausgeführten Pins, für solche (Makaberen Zwischenspeicher) man kann sich 
so ein paar Byte mehr RAM "Ergattern" da ja jeder Befehl der auf RAM 
passt, passt auch auf Pheripherie.
Auch wen MPY vorhanden ist, mache ich Oft über Berechnungen 
Speicherzugriffe und verwende dann je nach art der Adressierung eines 
der Res(8bit) oder Res(16bit) Register. Sehr schnelle Zugriffe lassen 
sich so auch mit dem MAC der MPY32 machen ;-)
"Multiplikation und automatisches Addieren, über einen DMA Kanal 
ersetzen den von mir aus der Z80er zeit fehlenden LDIR Befehl" eignet 
sich hervorragend für Tabellen.

Der Bug war ähnlich sch...e wie der Coproz Bug von Intel damals.

Also wenn wer Probleme mit Erratas hat, mich fragen.
Wen ich den XMSP dieses MPU's besitze weis ich in der Regel auch ne 
Lösung.
[/OT]

Patrick L. schrieb:
> Also wenn wer Probleme mit Erratas hat, mich fragen

Ja, wenn sie mir nochmal übern Weg laufen. ;-)

Später haben wir dann aber auch die Xmegas durch ARM ersetzt, da wurde 
vieles unkritischer. Auch die Portierung von Atmel-ARM auf STM32 war so 
kompliziert nicht, am meisten Aufwand hat der völlig andere 
Extern-Interrupt-Kram gebraucht.

Aber ja, OT, außer dass es natürlich massig ARMs mit integriertem 
(Parallel-)DAC gibt. Aber Dieter ist sowieso verschwunden.

Loxo schrieb:
> Hast du einen Link wo dieses Kit zu dem Preis noch zu bekommen ist?

Sorry ich sehe jetzt das das in der Tat schwierig wird. Habe selber noch 
10 davon liegen, vor 2 jahren gekauft ich denke bei Cypress selber.

Jörg W. schrieb:
> Damit war das Teil damals für uns praktisch unbrauchbar,

Noch mal's Kurz ein [OT]
Habe nachgeschaut warum der Bug so lange Bestand:
Ursache trat nicht immer auf, es wurde am Stärksten wenn der Timer 
Asynchron zur CPU läuft. dan konnte tatsächlich wärend des Auslesen ein 
paar Bit Instabil werden und das Ausgelesene meist in den unteren 4 Bit 
Nibbles irgend was drin haben, nur nicht dass was im Timer stand.

Nachvolgende Timer die dann Ohne diesen Bug waren, Haben ein 
Zusätzliches Shadowregister bekommen (Was eine massive Layoutänderung 
des Die bedeutete) was dann aber der CPU ermöglichte den Timer Synchron 
auszulesen.
Deshalb blieb der Bug, über mehrere Versionen bestehen und auch auf 
mehreren Typen vorhanden.

Im übrigen ist mit genau diesem Bug (Der ja Logisch ist wen CPU und 
Timer asynchron getaktet werden) auch bei einigen Anderen MCU's 
vorhanden (Nicht TI) aber oft nicht dokumentiert. und sorgt in der 
Realen Welt immer wieder zu Kuriosen Verhalten von Programmen, auf 
Verschiedenen MCU's und Hersteller.
Einige haben dies sogar damit gelöst das die CPU Kurzzeitig angehalten 
wird, um Timer auszulesen, was ich speziell als schlechtere Variante 
ansehe als das Shadow Register.
[/OT]

Dieter H. schrieb:
> Gibt es da AVRs oder PICs? STMs kriegt man ja gerade gar nicht.

Mit dem Argument nimmt man doch auf jeden Fall einen externen DAC. Wenn 
man 2 oder mehr Kanäle braucht, spart I2C sogar Pins. Mit SPI sind auch 
20MHz Abtastrate möglich. Und bei Reichelt gibt's jede Menge Auswahl ab 
0.53€

https://www.reichelt.de/signalwandlung-c8710.html?&nbc=1

Patrick L. schrieb:
> Ursache trat nicht immer auf, es wurde am Stärksten wenn der Timer
> Asynchron zur CPU läuft.

Das war auch bei uns der Fall.

Allerdings: andere Architekturen synchronisieren in diesem Fall den 
Timer-Takt mit dem CPU-Takt (was natürlich zur Folge hat, dass er 
maximal halb so groß werden kann, hätte uns aber genügt), um genau das 
Problem zu vermeiden. Oder aber, gängige Methode beim mit dem 
32-kHz-Quarz getakteten Timer, man hat ein "busy"-Flag, auf das man 
warten muss.

Alex schrieb:
> Die DACs sind eher dazu gedacht,
> die Referenzspannungen für den ADC zu erzeugen.

Ja 5 oder 6 Bit ist gar nicht unüblich zu dem Zweck.
Auch für Komparatoren werden in MCU's oft 6 Bit DAC's verwendet.
Siehe Da: 
https://www.mikrocontroller.net/articles/MSP430#Analog_Peripherie

Alex schrieb:
> wäre das R/2R-Netzwerk eine Notlösung.

Habe ich gaaaanz früher noch bei GA's so ALTERA EPM-MAX7032 & Co 
gemacht.
(PS: Nicht mit MAXIM MAX7032 verwechseln das ist ganz was anderes)
Habe aber dazu R/2R Netzwerke im SIP genommen, die waren extra für das 
gemacht.
Ich glaube habe da sogar noch etliche von im Ersatzteillager :-D

Patrick C. schrieb:
> Loxo schrieb:
>> Hast du einen Link wo dieses Kit zu dem Preis noch zu bekommen ist?
>
> Sorry ich sehe jetzt das das in der Tat schwierig wird. Habe selber noch
> 10 davon liegen, vor 2 jahren gekauft ich denke bei Cypress selber.

Update : Es gibt noch andere kits die einen PSOC-5LP CY8C5868LTI-LP039 
benutzen als abbrechbarer programmer, die kann man auch 
neu-programmieren mittels USB-bootloader.
zB die folgende kits :
CY8CKIT-043
CY8CKIT-146

Beiden haben sowohl der programmer als auch irgendeinen PSOC4 drauf.
Preise  unter 10 euro (Lieferanten u.a. Farnell, RS, Digikey, Mouser)

Solange es noch verfuerbar ist... Ich habe mir gleich einige davon 
bestellt

Patrick aus die Niederlaende