Ich möchte ein Signal aufzeichnen um es später in einer Endlosschleife wiederzugeben. Das Signal ist 8min lang. 20kHz Abtastung mit 12bit wäre ok. Denkbar sind Lösungen mit PC oder autark mit Mikrocontroller und Speicher. Das Ziel ist es die grundsätzlichen Möglichkeiten näher zu beleuchten um auf dieser Basis dann zu entscheiden. An Messkarten habe ich im Info-Fundus gefunden: USB AD14f. ADC 14bit 20kHz. DAC 12bit. Unklar welche Rate der DAC kann. DT9812-10V. ADC 12bit 50kHz. DAC 12bit 50kHz. RedLab 1408FS. ADC 14bit 48kHz. DAC 12bit 250kHz. MI16080. ADC 12bit 100kHz. DAC 12bit. Unklar welche Rate der DAC kann. CEBO LC. ADC 16bit 85kHz. DAC 12bit. Unklar welche Rate der DAC kann. PCMCIA-Karte mit ADC/DAC. DataTranslation etc. Natürlich braucht es dazu jeweils eine passende Software. Keine Ahnung wie einfach es ist sich hier selbst ein paar Zeilen zu schreiben um das so anzupassen wie man es haben möchte. Ggf. könnte eine Mikrocontroller-Lösung vorteilhaft sein. Mikrocontroller mit integriertem 12bit ADC und 12bit DAC. Mikrocontroller mit externem 12bit ADC und 12bit DAC. Mikrocontroller mit internem 12bit ADC und externem 12bit DAC. ADuC7020, 7021, 7024, 7026: ADC 12bit 1Ms, DAC 12bit 10us ADuC848BSZ8-5: ADC 16bit, DAC 12bit und 16bit STM32L05x: ADC 12-16bit, DAC 12bit STM32L4: ADC 16bit, DAC 12bit MSP430F478: ADC 16bit, DAC 12bit MSP430FG477: ADC 16bit, DAC 12bit MSP430FG478: ADC 16bit, DAC 12bit MSP430FG4619: ADC12bit, DAC 12bit MSP430F5418: ADC 12bit AVR: externer ADC, externer DAC natürlich ist es für mich einfacher einen AVR nehmen wo ich die GCC-Entwicklungsumgebung kenne statt mich in eine andere Umgebung wie z.B. MSP430 einzulernen.
Hat dein Eingangssignal 20kHz Maximalfrequenz oder willst du mit 20kS/s abtasten? Wenns um 20kHz Audio geht: Mit nem AVR nur gerade so machbar.
Matthias W. schrieb: > 20kHz Abtastung mit 12bit wäre > ok. Das sind also pro Sekunde 30000 Bytes. Wenn wir das jetzt mal mit den 480 Sekunden multiplizieren sind das 14400000 Bytes - die Adressierung wird einem Mikrocontroller etwas schwerfallen, wenn es nicht die 32 Bit Klasse a là STM32 ist, m.E. fällt ein normaler AVR hier aus (oder man nimmt einen XMega mit externem SDRAM). Entweder komprimierst du schon bei der Aufnahme oder du hängst ein 16Mb RAM an deinen Papagei.
ATXMega gibts einige, die das können. Interessanter ist die Frage - wohin mit den Daten? Ohne Kompression sind es knappe 20MByte.
Evtl. ist es sinnvoll, das Signal mit einem z.B. PC aufzuzeichnen und in OGG oder MP3 zu komprimieren. Ein STM32 kann es dann abspielen.
Sascha schrieb: > Hat dein Eingangssignal 20kHz Maximalfrequenz oder willst du mit 20kS/s > abtasten? 20kS/s Abtastung. > Wenns um 20kHz Audio geht: Mit nem AVR nur gerade so machbar. 2OkS/s reicht. das wären dann 40000byte/s über seriell. Das könnte noch gehen. Die Daten müssten beim Lesen vom AVR zum PC-Terminalprogramm geschickt werden. Wenn alles komplett da ist kann man das auf eine Chipkarte schreiben und den AVR von dort auslesen lassen um es per ISR auf den DAC zu schreiben. Soweit die Idee. Auch mehr als 8min sind so denkbar. Es gibt ja auch recht große Chipkarten.
Klassische Lösung wäre die Aufzeichnung mit Mikrocontroller auf eine SD-Karte und spätere Wiedergabe. Ist klein und billig, und mithilfe von Libraries sollte sich der Programmieraufwand in Grenzen halten. Ein STM32 mit SDIO-Interface kann das locker.
Matthias S. schrieb: > Das sind also pro Sekunde 30000 Bytes. Danke Matthias ! wenn man je 2byte nimmt für die 12bit sind es sogar 40000byte. Das sollte trotzdem noch gehen. > Wenn wir das jetzt mal mit den > 480 Sekunden multiplizieren sind das 14400000 Bytes - die Adressierung > wird einem Mikrocontroller etwas schwerfallen, ja. Daher würde ich es einfach per seriell/USB zum Terminalprogramm senden und den PC die Aufzeichnung machen lassen. > wenn es nicht die 32 Bit > Klasse a là STM32 ist, m.E. fällt ein normaler AVR hier aus (oder man > nimmt einen XMega mit externem SDRAM). Entweder komprimierst du schon > bei der Aufnahme oder du hängst ein 16Mb RAM an deinen Papagei. Zum Auslesen brauche ich den Speicher natürlich. Sonst kann das nicht autark laufen. Es gibt doch Kartenlese-Interfaces günstig. So etwas müsste ich an den AVR doch anhängen können.
Matthias S. schrieb: > Evtl. ist es sinnvoll, das Signal mit einem z.B. PC aufzuzeichnen und in > OGG oder MP3 zu komprimieren. Ein STM32 kann es dann abspielen. Danke für den Vorschlag. Komprimieren möchte ich ungerne in diesem Fall weil es kein Soundsignal ist.
Dr. Sommer schrieb: > Klassische Lösung wäre die Aufzeichnung mit Mikrocontroller auf eine > SD-Karte und spätere Wiedergabe. Ist klein und billig, und mithilfe von > Libraries sollte sich der Programmieraufwand in Grenzen halten. Ein > STM32 mit SDIO-Interface kann das locker. gute Idee. Klappt das auch mit einem AVR noch gut? Hier gibt es ja eine Reihe von Bibliotheken: https://www.mikrocontroller.net/articles/MMC-_und_SD-Karten FAT(12,16,32)-Dateisystem. Sehr klein. Beispiele für AVR. Holger Klabundes FAT16/32 mit Beispielen für AVR MMC/SD und CF, LPC2k mit SPI keine Ahnung was da am einfachsten in Betrieb zu bekommen ist.
:
Bearbeitet durch User
Hier gibts eine Platine mit Pegelwandler: http://www.shop.display3000.com/elektronikmodule/sd-speicherkartenplatine.html "Aufwändige Elektronik mit bidirektionalem Pegelwandler und Tristate Leitungen. Für 3V und 5 V-Systeme." "beim C-Compiler WinAVR gibt es diverse Open Source Software." "Bislang hat noch keine gestestete SD Karte versagt und noch kein einziger User hat jemals ein Problem reported."
Matthias W. schrieb: > gute Idee. Klappt das auch mit einem AVR noch gut? Ich meine mich zu erinnern, dass Leute derartige Datenraten mit einem AVR geschafft haben. Da kannst du ja mal nach recherchieren. Das Problem wird sein, dass du einiges an RAM brauchst, um die Daten zu puffern, während die SD-Karte arbeitet. Moderne Kandidaten wie die STM32 sind da tendentiell um einiges besser bestückt. z.B. ein STM32F4-Discovery (ca. 15€) plus etwas Löterei um die Karte anzubinden schafft noch viel höhere Datenraten, bei der Auswahl guter Karten. Da gibts eigentlich wenig Grund das irgendwie mit nem AVR hinzubiegen...
PS: Beitrag "Re: SD-Karten Extender Leitung" Anschluss des STM32F4-Discovery an eine SD-Karte. Keinerlei zusätzliche elektrische Komponenten (wie Pegelwandler) benötigt, lediglich ein einfacher mechanischer Adapter. Sollte natürlich so ähnlich auch mit anderen STM32-Eval-Boards gehen. Beim F7-Discovery braucht man gar nix zu löten, aber das ist auch ziemlicher overkill und teuer (ca. 50€).
Dr. Sommer schrieb: > Beitrag "Re: SD-Karten Extender Leitung" > Anschluss des STM32F4-Discovery an eine SD-Karte. Keinerlei zusätzliche > elektrische Komponenten (wie Pegelwandler) benötigt, lediglich ein > einfacher mechanischer Adapter. Vielen Dank !
Frage: Was ist zu solchen Billiglösungen zu sagen? http://www.ebay.de/itm/like/151249498492?ul_noapp=true&chn=ps&lpid=106 http://www.ebay.de/itm/like/141902997711?ul_noapp=true&chn=ps&lpid=106 SD Memory Card Module Slot SPI Reader 3.3V/5V- Arduino / ARM / MCU SD Card Cardreader Writer f. Arduino Interface Reader Cardwriter Bekommt man so etwas problemlos an einem AVR in Betrieb? Hat jemand damit Erfahrungen gesammelt?
Matthias W. schrieb: > Mikrocontroller mit integriertem 12bit ADC und 12bit DAC EFM8LB für 1.50 EUR: 14-bit ADC 900 ksps / DMA und 4x 12-bit DAC 200 ksps EFM8BB für 1.00 EUR: 12-bit ADC 200 ksps / DMA und 2x 12-bit DAC 200 ksps Matthias W. schrieb: > natürlich ist es für mich einfacher einen AVR nehmen Da der EFM8 so billig ist und die DMA automatisch läuft könnte man den auch als günstigen externen ADC DAC per SPI I2C / UART für einen AVR nehmen, wenn man gegen 8051 allergisch ist.
Lothar schrieb: > EFM8LB für 1.50 EUR: 14-bit ADC 900 ksps / DMA und 4x 12-bit DAC 200 > ksps > EFM8BB für 1.00 EUR: 12-bit ADC 200 ksps / DMA und 2x 12-bit DAC 200 > ksps Danke Lothar. Das ist natürlich ein Argument. Preisgünstiger geht es kaum. Bis 3Mbd sollten reichen. Damit wären 40kS/s wohl auch möglich. DIL-Gehäuse gibt es nicht. Dafür kann man das noch löten. Es gibt offenbar eine Software-Entwicklungsumgebung gratis dazu. Debug-Adapter kann man wohl kaufen. Um die Teile brauchbar zu nutzen - reicht da das recht knappe Datenblatt zusammen mit der Software? Oder gibts da noch extra Dateien mit Beispielen? Mit diesen Teilen habe ich keinerlei Erfahrung. Ich weiß nicht wie viele Klippen da auftauchen können und wie viel Hilfe man wo ggf. bekommen kann wenn es klemmt. Das ist der Nachteil wenn man Controller nimmt die wohl eher selten bei Hobbyisten zu finden sind. > Da der EFM8 so billig ist und die DMA automatisch läuft könnte man den > auch als günstigen externen ADC DAC per SPI I2C / UART für einen AVR > nehmen, wenn man gegen 8051 allergisch ist. man kommt wohl nicht umhin den EFM8 erst mal so weit zu programmieren daß er die Grundfunktionen für ADC und DAC macht. Der DAC per DMA ist natürlich gut. 72MHz intern klingt schnell. Man muss halt schauen daß der DMA rasch genug brauchbar gefüttert wird. Vermutlich liest er ja einen Puffer aus. Dieser muss geeignet gefüllt werden. Idealerweise könnte der DMA direkt aus dem externen SD-Speicher lesen, wenn das machbar ist. Sonst braucht es eine Routine die einen Zwischenspeicher mit dem Inhalt der SD-Karte füllt. Und der DMA arbeitet dann den Zwischenspeicher ab. Keine Ahnung wie einfach so etwas bei dem EFM8 ist.
Für Test-Einzelstücke sind die 20€ Handlinggebühr bei Mouser natürlich etwas störend.
Matthias W. schrieb: > Es gibt offenbar eine Software-Entwicklungsumgebung gratis dazu. Für den STM32 gibts gleich mehrere > Debug-Adapter kann man wohl kaufen. Ist z.B. beim STM32F4 Discovery integriert in den 15€ > > Um die Teile brauchbar zu nutzen - reicht da das recht knappe Datenblatt > zusammen mit der Software? Oder gibts da noch extra Dateien mit > Beispielen? Beim STM32 ist das ausführlich, und Beispiele gibts jede Menge > > Mit diesen Teilen habe ich keinerlei Erfahrung. Ich weiß nicht wie viele > Klippen da auftauchen können und wie viel Hilfe man wo ggf. bekommen > kann wenn es klemmt. Die STM32 sind mittlerweile recht bekannt hier im Forum. > Idealerweise könnte der DMA direkt aus dem externen SD-Speicher lesen, > wenn das machbar ist. Beim STM32 - ja, über die SDIO bzw. SPI -Peripherie. Du kannst quasi den ganzen RAM des Controllers füllen/leeren ohne dass die CPU zwischendurch irgendetwas tun müsste. Gleiches gilt für die Ausgabe per DAC.
Matthias W. schrieb: > Es gibt offenbar eine Software-Entwicklungsumgebung gratis dazu. > Debug-Adapter kann man wohl kaufen. Das Eval-Board SLSTK2030A für 27 EUR hat einen J-Link Debugger drauf. Der kann auch externe uC debuggen. Die EFM8 kommen werkseitig mit UART Bootloader und können auch per USB-seriell Kabel geflasht werden. Die IDE kommt mit einem gratis Keil Compiler. Man merkt hier dass die EFM8 mit aus den Erfahrungen mit den EFM32 ARM entwickelt wurden, so bin ich auch dazu gekommen, hatte vorher nur ARM genutzt. > DIL-Gehäuse gibt es nicht. Dafür kann man das noch löten. Die QFP-32 0.8 mm sind gut zu löten. Die SOP-24 weniger, irregulär 0.635 mm > man kommt wohl nicht umhin den EFM8 erst mal so weit zu programmieren > daß er die Grundfunktionen für ADC und DAC macht Demos sind bei der IDE reichlich dabei (ADC DAC ohne mit IRQ / DMA etc). Der DMA kann sogar akkumulieren, averagen, filtern ohne CPU > wie viel Hilfe man wo ggf. bekommen kann Das Forum ist im Vergleich zu Atmel sehr ordentlich, mit Antworten von Mitarbeitern: http://community.silabs.com/t5/8-bit-MCU/bd-p/1
Dr. Sommer schrieb: > Matthias W. schrieb: >> Es gibt offenbar eine Software-Entwicklungsumgebung gratis dazu. > Für den STM32 gibts gleich mehrere vielen Dank. Die Umgebung scheint wirklich günstig. Der Pin-Abstand ist halt sehr eng zum Löten. Sind viele Pins.
Lothar schrieb: > Das Eval-Board SLSTK2030A für 27 EUR hat einen J-Link Debugger drauf. > Der kann auch externe uC debuggen. Die EFM8 kommen werkseitig mit UART > Bootloader und können auch per USB-seriell Kabel geflasht werden. Die > IDE kommt mit einem gratis Keil Compiler. ok. Ein Tutorial gibts wohl nicht zufällig irgendwo? > Die QFP-32 0.8 mm sind gut zu löten. Danke Lothar. Das ist noch machbar. > Demos sind bei der IDE reichlich dabei (ADC DAC ohne mit IRQ / DMA > etc). Der DMA kann sogar akkumulieren, averagen, filtern ohne CPU ok. > Das Forum ist im Vergleich zu Atmel sehr ordentlich, mit Antworten von > Mitarbeitern: > http://community.silabs.com/t5/8-bit-MCU/bd-p/1 Danke.
Matthias W. schrieb: > Ein Tutorial gibts wohl nicht zufällig irgendwo Also ich habe mich so "eingearbeitet" dass ich halt alle Beispiele durchgegangen bin (Blinky, UART usw) und im Manual nachgeschaut was die Register / Bits so bedeuten. Anders als beim AVR gibt es ein Datenblatt (für das Elektrische) und ein separates Manual (für die Programmierung). Wenn Du unbedingt ein Tutorial brauchst: das ist ein ganz normaler 8051 da gibt es reichlich z.B. http://learn.mikroe.com/ebooks/8051programming/ (ist aber wirklich für "Anfänger") Folgende Nachteile haben die EFM8 gegenüber "echten" 8051: die Demos nutzen größtenteils eine Library ähnlich CMSIS oder Atmel ASF was aus meiner Sicht den Durchblick nicht erhöht. Ich habe das alles rausgeworfen und durch direktes Register beschreiben ersetzt. Und die EFM8 haben eine Switch-Matrix d.h. man kann jedem Pin jede Funktion beliebig zuweisen. Dafür gibt es ein grafisches Tool. Das ist zwar beim Layout sehr hilfreich, für den "Anfänger" ist es aber Mist. Bevor man auch nur z.B. UART machen kann, muss man erst RX / TX an zwei Pins routen: http://community.silabs.com/t5/Video-Tutorials/The-Configurator-Tool-Simplicity-Studio-User-Guide/td-p/130402
Lothar schrieb: > Also ich habe mich so "eingearbeitet" dass ich halt alle Beispiele > durchgegangen bin (Blinky, UART usw) und im Manual nachgeschaut was die > Register / Bits so bedeuten. Anders als beim AVR gibt es ein Datenblatt > (für das Elektrische) und ein separates Manual (für die Programmierung). vielen Dank Lothar. > Wenn Du unbedingt ein Tutorial brauchst: das ist ein ganz normaler 8051 > da gibt es reichlich z.B. > http://learn.mikroe.com/ebooks/8051programming/ (ist aber wirklich für > "Anfänger") Danke. Meine 8051-Seiten liegen lange zurück. Als um 1990 der 80C166 kam und der Motorola 68F333 schien der 8051 für manche Anwendungen in der Automobilindustrie nicht mehr so interessant. Eher 16bit bis hin zu PowerPC war bald gefragt. Für einfache performante Anwendungen scheinen mir modernisierte 8051 mit on chip Peripherie sehr wohl interessant. > Folgende Nachteile haben die EFM8 gegenüber "echten" 8051: die Demos > nutzen größtenteils eine Library ähnlich CMSIS oder Atmel ASF was aus > meiner Sicht den Durchblick nicht erhöht. Ich habe das alles > rausgeworfen und durch direktes Register beschreiben ersetzt. Danke für den Hinweis. Das macht aus meiner Sicht Sinn. Erinnert mich an die Arduino-Umgebung. > Und die > EFM8 haben eine Switch-Matrix d.h. man kann jedem Pin jede Funktion > beliebig zuweisen. Dafür gibt es ein grafisches Tool. Das ist zwar beim > Layout sehr hilfreich, für den "Anfänger" ist es aber Mist. Bevor man > auch nur z.B. UART machen kann, muss man erst RX / TX an zwei Pins > routen: > > http://community.silabs.com/t5/Video-Tutorials/The-Configurator-Tool-Simplicity-Studio-User-Guide/td-p/130402 Danke. Ist klar. Solche Features sind zwar schön - erhöhen aber die Komplexität bei der Programmierung und sind für manchen eine Hürde.
Lothar schrieb: > Also ich habe mich so "eingearbeitet" braucht man aus Deiner Sicht so ein Starterkit oder geht es auch einfacher mit einer CPU - aufgelötet auf eine Adapterplatine und dann Fädeldrähte oder Steckbrett? Bei den AVR fand ich gut daß man so anfangen kann. Eine CPU - und darum eine Minimalbeschaltung. Eine einfache Programmiermöglichkeit dazu - so wie damals PonyProg. So in etwa sollte doch so ein 8051 auch in Betrieb zu bekommen sein? Für Anfänger die etwas mit ADC und DAC machen wollen wäre das doch ggf. einfacher und kostengünstiger als an einen AVR einen externen DAC anzuschließen. Zudem ist 12bit mit 4096 Stufen für bestimmte Anwendungen günstiger als nur 10bit (1023 Stufen). DAC ist manchmal besser als eine PWM deren Filter einen Ripple hat und erst noch einschwingen muss. Anfänger kommen mit dem 32pin-Gehäuse mit dem größeren Pinabstand besser zurecht als mit so einem 64-pin-Gehäuse wie es die MSP430-Serie bei den DAC-Modellen hat.
Für Anfänger wäre es auch besser wenn Firmen wie z.B. Reichelt die benötigten Teile nebst einfachem Programmieradapter anbieten würden damit nicht jedesmal Einmalkosten von 20.- für Mouser entstehen. Solche Hürden könnte man abbauen.
Matthias W. schrieb: > Danke. Meine 8051-Seiten liegen lange zurück. Als um 1990 der 80C166 kam > und der Motorola 68F333 schien der 8051 für manche Anwendungen in der > Automobilindustrie nicht mehr so interessant. Eher 16bit bis hin zu > PowerPC war bald gefragt. Der 8051 ist wie der Z80 ein Zombie - alle paar Jahre kommt wieder ein Projekt mit den Teilen. Ich habe mich bei meinem letzten BLE-Projekt auch gefragt, warum ausgerechnet TI einen 8051-Kern für Ihre CC25xx verwendet.
Marcus H. schrieb: > Der 8051 ist wie der Z80 ein Zombie - alle paar Jahre kommt wieder ein > Projekt mit den Teilen. ja. Scheint nicht totzukriegen. Auf der anderen Seite ist es ja nicht immer schlecht etwas das mal gut war weiter verbessert wieder neu anzubieten. Der Markt kann ja entscheiden. > Ich habe mich bei meinem letzten BLE-Projekt auch gefragt, warum > ausgerechnet TI einen 8051-Kern für Ihre CC25xx verwendet. aus meiner Sicht wäre auch nichts einzuwenden wenn mal jemand einen 8bit-AVR mit 12bit ADC, 12bit DAC und DMA im DIL-Gehäuse oder mit 32pins und somit etwas mehr Abstand zwischen den Pins brächte. Es wird wohl Gründe geben warum TI das so gemacht hat. Es gab auch Gründe warum die AVR so anders gemacht worden sind.
@ Matthias W. (matt007) >> Der 8051 ist wie der Z80 ein Zombie - alle paar Jahre kommt wieder ein >> Projekt mit den Teilen. >ja. Scheint nicht totzukriegen. Auf der anderen Seite ist es ja nicht >immer schlecht etwas das mal gut war weiter verbessert wieder neu >anzubieten. Der Markt kann ja entscheiden. Naja, irgendwann ist der Zug einfach abgefahren. Und es gibt je nun weiß Gott reichlich neue CPUs. >aus meiner Sicht wäre auch nichts einzuwenden wenn mal jemand einen >8bit-AVR mit 12bit ADC, 12bit DAC und DMA im DIL-Gehäuse oder mit 32pins >und somit etwas mehr Abstand zwischen den Pins brächte. Kauf dir einen ATXmega auf einem Breakout Board. Oder lern SMD Löten.
Matthias W. schrieb: > Eine CPU - und darum eine Minimalbeschaltung. > Eine einfache Programmiermöglichkeit dazu - so wie damals PonyProg. > > So in etwa sollte doch so ein 8051 auch in Betrieb zu bekommen sein? Das billigste ist für 3 EUR auf Ebay ein USB seriell Adapter z.B. 3.3V/5V PL2303 USB to Serial Board oder USB Serial TTL PL2303HX Kabel Die "Minimalbeschaltung" eines EFM8 wäre dann die 3.3V / GND vom Adapter plus RX / TX zum Flashen und ein Draht zum GND anlegen am ISP Enable Pin. Wie gesagt die EFM8 kommen werksseitig mit Bootloader und zum Flashen gibt es ein (leider) Kommandozeilen-Tool (in Python, läuft somit auch auf Mac / Linux) Für ADC / DAC Anwendungen sollte man aber noch das übliche machen: getrennte Versorgung digital / analog, Abblock-Kondensatoren, eventuell Filter für den ADC und ADC Referenz. Temperatur-Kompensation kann man sich sparen da interner Sensor vorhanden.
Lothar schrieb: > Das billigste ist für 3 EUR auf Ebay ein USB seriell Adapter z.B. > 3.3V/5V PL2303 USB to Serial Board Danke Lothar. 5,45€ sind machbar. > Die "Minimalbeschaltung" eines EFM8 wäre dann die 3.3V / GND vom Adapter > plus RX / TX zum Flashen und ein Draht zum GND anlegen am ISP Enable > Pin. hört sich machbar an wenn es dazu eine kleine Beschreibung gibt. > Wie gesagt die EFM8 kommen werksseitig mit Bootloader und zum > Flashen gibt es ein (leider) Kommandozeilen-Tool (in Python, läuft somit > auch auf Mac / Linux) kein Problem. Mir ist so was lieber als eine Oberfläche die an zig Stellen Einstellungen braucht die man dann nur schwer versteht und das eine oder andere vergisst. > Für ADC / DAC Anwendungen sollte man aber noch das übliche machen: > getrennte Versorgung digital / analog, Abblock-Kondensatoren, eventuell > Filter für den ADC und ADC Referenz. so wie bei AVR etc. ja auch. > Temperatur-Kompensation kann man > sich sparen da interner Sensor vorhanden. per Software muss dann ggf. dann halt was machen wenn man weiß wie da was wegläuft. Es könnte ggf. sein daß externe Wandler stabiler sind. Du meinst also daß man so ein Starterkit eher nicht braucht? Die Software kann man sich vermutlich auch so irgendwo laden?
Uwe B. schrieb: > Was spricht gegen eine Loesung mit der PC Soundkarte? Danke Uwe ! prinzipiell nichts. Das war die erste Idee. Beitrag "Signal mit DC-Anteil mit 20kHz, 12bit abtasten" Das Signal ist jedoch nicht symmetrisch zur Null-Linie, hat sehr niederfrequente Anteile und sollte daher besser DC-gekoppelt aufgezeichnet werden. Die üblichen Soundkarten sind AC-gekoppelt. Man müsste daher eine Karte finden die trotz allem ohne größere Veränderungen sauber aufzeichnet und das so auch wiedergeben kann.
Matthias W. schrieb: > hört sich machbar an wenn es dazu eine kleine Beschreibung gibt Wenn man schon ARM kennt (LPC STM32 etc) ist es genauso. Ansonsten: AN945: EFM8 Factory Bootloader User Guide Matthias W. schrieb: > Du meinst also daß man so ein Starterkit eher nicht braucht Nicht unbedingt. Aber auch wenn hier alle Experten behaupten, nie einen Debugger zu brauchen: es kann schon manchmal hilfreich sein. Falk B. schrieb: > Kauf dir einen ATXmega auf einem Breakout Board Also der Zug ist doch auf jeden Fall abgefahren. Wann gab es denn einen neuen ATXmega? Wird zudem bestimmt von Microchip eingestampft. Und was die AVR angeht, jeder neue 8051 hat z.B. programmierbare PLL und Security Bits also kein Fuse Mist mehr.
Danke Lothar für den hilfreichen Beitrag. Ich stelle das Thema erst mal zurück, behalte es jedoch im Auge. Mir gefallen diese Teile. Natürlich kann ein Debugger hilfreich sein. Es ist halt die Frage wie viel zusätzlichen Aufwand, Ärger und Kosten man sich damit einhandelt. Noch dazu wenn es ein privates Projekt ist. Ich hatte ein etwas größeres Programm mit AVR und Assembler gemacht. Es war sehr lästig da Fehler zu finden. JTAG hätte wohl geholfen, hatte ich damals aber nicht. Viel lässt sich über die serielle Schnittstelle machen. Da kann man auch Ausgaben machen die beim Debuggen helfen. Dazu braucht es wenig Kosten und wenig Lernaufwand.
in memoriam KLEN
BUG-KILLING
Palmström schlägt als nächstes vor sodann
ein debugging-Fehler-kill-Programm.
Und in seinen Träumen: ohne Mühn
sieht er fehlerfrei Programme blühn.
Mit v. Stumm sitzt er halbnächtelang
programmierend, ändernd, sinnend bang.
Leider ('s war nicht bugfrei programmiert)
hat's Programm sich selbst - eliminiert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.