Ich weiss die Frage kommt oft, ich habe aber genaue Vorstellungen was ich brauche. Ich habe mich schonmal an das stm32 probiert doch erfolglos aufgegeben. Mit dem 8051 kam ich gut klaar. Ich brauche i2c, spi uart, AD-Wandler und das man das teil in der Schaltung programmieren kann. Am besten ist noch ein lötfreundliches Gehäuse. Zudem sollte es eine comunity geben oder gute Dokumentation, ich meine nicht 2000 Seiten wie bei stm32. Programmiert wird in C.
lowpow schrieb: > Mit dem 8051 kam ich gut klaar. Dann nimm den doch. Lothar schrieb im Beitrag "Re: Kit gut für einen Einsteiger?" > Dieses 8051 Board z.B. hat für 25 EUR einen Debugger drauf Lothar schrieb im Beitrag "Re: Kit gut für einen Einsteiger?" >> Ist der µC von Silicon Labs für Anfänger einfacher? > > Auf jeden Fall. Einfacher als die 8051 Basis Peripherie geht kaum. Und > die Probleme macht ja nie der Kern, auch ARM nicht, aber bei ARM wird > meist die Peripherie unnötig komplex gemacht. Die Unterschiede gibt es > sogar innerhalb der Hersteller, nach meiner Meinung: > > EFM8 Silabs einfach / 8051 Atmel kompliziert > LPC ARM einfach / STM32 komplexer EFM32 Silabs kompliziert SAM Atmel > sehr kompliziert > > Einen Nachteil hat EFM8 allerdings. Die neue IDE ist Eclipse und völlig > überladen. Zwar gibt es für alles Youtube Tutorials, aber für den > Anfänger ist nicht sofort zu erkennen, was davon wirklich nützlich ist.
:
Bearbeitet durch User
lowpow schrieb: > Ich brauche i2c, spi uart, AD-Wandler und das man das teil in der > Schaltung programmieren kann. Am besten ist noch ein lötfreundliches > Gehäuse. Zudem sollte es eine comunity geben oder gute Dokumentation, > ich meine nicht 2000 Seiten wie bei stm32. Du hast selbst gerade den AVR beschrieben. Sieh dir mal das Tutorial an: https://www.mikrocontroller.net/articles/AVR-Tutorial Die AVRs gibts vom kleinsten Tiny mit 6poligem SOT-Gehäuse bis zum Mega2560 im 100poligen TQFP. Von klein bis groß, auch viele im DIL-Gehäuse, du hast die Auswahl :-)
lowpow schrieb: > Ich brauche i2c, spi uart, AD-Wandler und das man das teil in der > Schaltung programmieren kann. Am besten ist noch ein lötfreundliches > Gehäuse. Zudem sollte es eine comunity geben oder gute Dokumentation, > > Programmiert wird in C. https://www.mikrocontroller.net/articles/AVR https://www.mikrocontroller.net/articles/AVR-Tutorial https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial https://www.mikrocontroller.net/articles/AVR_Typen
lowpow schrieb: > Welcher µC ist einfach zu programmieren Meinst du jetzt das Programm schreiben, zu compilieren, debuggen, oder den Controller mit dem Code zu flashen?
Bei dem was du suchst, empfehle ich diese Seiten https://www.mikrocontroller.net/articles/Modulares_Board Dürfte so ziemlich alles dabei sein. Es gibt auch eine Menge Tuts dazu. Kann dir gern weiterhelfen achim
Da gibt's nur eins: PIC! Und wenn jetzt alle dagegen schreien, der Mainstream hatte noch nie recht! Chregu
Christian M. schrieb: > Da gibt's nur eins: PIC! Und damit wir komplett sind, schreie ich jetzt noch nach den MSP's von TI und dem LaunchPad.
Zu "komplett" gehören jetzt auch noch die STM8S mit dem sdcc...
@Achim Seeger (achims) >Bei dem was du suchst, empfehle ich diese Seiten >https://www.mikrocontroller.net/articles/Modulares_Board >Dürfte so ziemlich alles dabei sein. Es gibt auch eine Menge Tuts dazu. >Kann dir gern weiterhelfen Na das kann ja lustig werden ;-)
Torsten C. schrieb: > lowpow schrieb: >> Mit dem 8051 kam ich gut klaar > Dann nimm den doch >> Dieses 8051 Board z.B. hat für 25 EUR einen Debugger drauf Das dortige Forum ist wenigstens produktiv :-) http://community.silabs.com/t5/8-bit-MCU/bd-p/1
@ Torsten C. (torsten_c) Benutzerseite >> Na das kann ja lustig werden ;-) >Wie meinst Du das? Schon mal Achim's Beiträge hier im Forum gelesen? Schon mal über seinen Wissenstand und seine Fähigkeiten zur Wissenvermittlung nachgedacht?
lowpow schrieb: > ich habe aber genaue Vorstellungen was ich brauche. lowpow schrieb: > Ich brauche i2c, spi uart, AD-Wandler und das man das teil in der > Schaltung programmieren kann. Am besten ist noch ein lötfreundliches > Gehäuse. Zudem sollte es eine comunity geben oder gute Dokumentation, Das reicht wohl noch nicht um irgendeine uC-Familie auszuschließen ;-)
Hallo Falk egal was du schreibst, die Hardware geht, die Programme laufen. Denke dran, einiges dazu stammt auch von dir. achim
Volker S. schrieb: > lowpow schrieb: >> Mit dem 8051 kam ich gut klaar. >> Ich brauche i2c, spi uart, AD-Wandler und das man das teil in der >> Schaltung programmieren kann. Am besten ist noch ein lötfreundliches >> Gehäuse. Zudem sollte es eine comunity geben oder gute Dokumentation, > > Das reicht wohl noch nicht um irgendeine uC-Familie auszuschließen ;-) Genau damit ist Arduino ausgeschlossen :-) Ein 8051 z.B. EFMBB1 oder EFM8UB2 hat das alles, kommt mit UART bzw. USB Bootloader, ist mit SO-16 bzw. QFP-32 noch lötfreundlich und das Forum beanwortet prompt alle Fragen. IDE ist natürlich auch kostenlos.
Lothar schrieb: > Ein 8051 z.B. EFMBB1 oder EFM8UB2 hat das alles, Du bist ja sehr hartnäckig mit diesen EFM8, kennst den AVR8 aber wohl garnicht. Auf den ersten Blick raffe ich nicht so recht, welche IO-Funktionen sinnvoll auf die Pins gelegt werden sollen. Für einen Anfänger wäre eine vorgegebene, feste Zuordnung sicher sinnvoller. Allerdings den 8051 mit seinen schlaffen Ausgängen zu benutzen, hat noch nie Freude aufkommen lassen. Beispiel: 8051-Port -> ULN2803. Wie sieht es denn beim EFM8 mit seiner Taktfrequenz aus? Mit einem Quarz kommt man maximal wohl nur bis 25 MHz. Die 72 MHz Versionen kann man damit knicken, wenn man genaues Timing braucht und keinen stromfressenden ext. Taktgeber verwenden möchte, der auch nur bis 50 MHz zulässig ist. Lothar schrieb: > IDE ist natürlich auch kostenlos. Nach Deiner eigenen Einschätzung scheint diese ja wohl bescheiden zu sein.
m.n. schrieb: > Allerdings den 8051 mit > seinen schlaffen Ausgängen zu benutzen, hat noch nie Freude aufkommen > lassen. Schlaff sind höchstens deine Aussagen! Ich finde es gut wenn Leute wie Lothar(Gast) sich zu den 51'zigern bekennt. Das schließt ja nicht aus, dass er auch bereits ARM Erfahrung hat!! Ich kenne genug solche Leute.
lowpow schrieb: > Zudem sollte es eine comunity geben oder gute Dokumentation, > ich meine nicht 2000 Seiten wie bei stm32. > > Programmiert wird in C. So also! Der Inhalt deines Eröffnungspostes konterkariert die Überschrift. Zuerst dachte ich, du meintest tatsächlich einen µC, der einfach zu programmieren sei, aber das war ja wohl ein Ausrutscher oder ein Witz. Variante 1: Einfach zu programmieren = leicht zu beherrschender Assembler. Variante 2: Einfach zu benutzender fest eingebauter Bootlader. Aber das war ja wohl nix. Also, du bist zu bequem, um ein RefMan zu lesen. Deshalb willst du einen Reigen von Leuten, denen du auf den Wecker gehen kannst, weil du das RefMan nicht lesen willst. Was bittesehr soll man dir da raten? Ich wäre ja fast geneigt, dir zu raten, einen Pascal-Compiler von Mikroe anzuschaffen und dich auf einen Chip zu verlegen, der dort unterstützt wird. Das wäre in gewissem Sinne einfach. Aber es soll ja C sein. Also installiere dir nen GCC und such dir nen Chip heraus, der von diesem unterstützt wird. Das war's dann. Die "community" hast du hier. W.S.
Die IDE für EFM8 und EFM32 von Silicon Labs ist alles andere als bedienerfreundlich und anfängertauglich erst recht nicht. Die Controller selber sind noch recht einfach zu programmieren, aber gegen die AVR kommen auch sie nicht an. Eine eigene Entwicklungsumgebung für diese Controller zu stricken überfordert nicht nur Anfänger. Blackbird
W.S. schrieb: > Also, du bist zu bequem, um ein RefMan zu lesen. Deshalb willst du einen > Reigen von Leuten, denen du auf den Wecker gehen kannst, weil du das > RefMan nicht lesen willst. Ich schätze den TO schon so ein, dass er ein RefMan lesen kann und es tut. Die Frage ist halt wie 'flüssig' kann man so was lesen und wie schnell kann man sowas absorbieren. Da sind die SiLabs Dinger durchaus nicht zu verachten. Du gehörst wahrscheinlich zu denen die mit dem Sattelschlepper von der Wohnung zum Supermarkt fahren um ein Lolli zu kaufen.
Blackbird schrieb: > Die IDE für EFM8 und EFM32 von Silicon Labs ist alles andere als > bedienerfreundlich und anfängertauglich erst recht nicht. > Die Controller selber sind noch recht einfach zu programmieren, aber > gegen die AVR kommen auch sie nicht an. > Eine eigene Entwicklungsumgebung für diese Controller zu stricken > überfordert nicht nur Anfänger. Man sagt ja Raben nach, dass sie intelligent sind - aber bei dir? Das hier ist jedenfalls Schwachsinn.
lowpow schrieb: > Welcher µC ist einfach zu programmieren? Die Antwort lautet: "Derjenige, den man schon kennt." :-)
Blackbird schrieb: > Die IDE für EFM8 und EFM32 von Silicon Labs ist alles andere als > bedienerfreundlich und anfängertauglich erst recht nicht Die nennt sich "Simplicity Studio" und ich würde zustimmen. Für die EFM8 gibt es aber Keil C51 kostenlos und natürlich ohne Code-Begrenzung und das schlägt z.B. Atmel Studio um Längen. Hinzu kommt der TO hat ja geschrieben dass er 8051 kennt und damit wohl C51 auch. il Conte schrieb: > Ich finde es gut wenn Leute wie Lothar sich zu den 51'zigern bekennt > Das schließt ja nicht aus, dass er auch bereits ARM Erfahrung hat!! Ich habe mit dem ARM2 1989 angefangen und nutze heute hauptsächlich LPC CortexM aber für bestimmte analoge Anwendungen sind die EFM8 nicht zu schlagen. m.n. schrieb: > Du bist ja sehr hartnäckig mit diesen EFM8, kennst den AVR8 aber wohl > garnicht. Erst mal habe ich geantwortet weil ich ganz oben zitiert worden bin :-) Und eine Sache mit der ich häufig zu tun habe ist Redesign von ATmega auf ARM. Wer will denn noch einen 2560 für 15 EUR und out-of-IO-space wenn man für 4 EUR einen LPC11U68 haben kann. > Wie sieht es denn beim EFM8 mit seiner Taktfrequenz aus? Mit einem Quarz > kommt man maximal wohl nur bis 25 MHz. Die 72 MHz Versionen kann man > damit knicken Bitte was? Die haben mehrere interne Oszillatoren z.B. die 72 MHz Version eben 72 MHz und 50 MHz und 80 kHz die man im Programm umschalten kann - also nichts mit verfusen. EFM8 mit USB haben einen 48 MHz internen präzisen Oszillator - kein Quarz erforderlich.
Die Frage ist, soll ich wirklich mit dem 8051 weitermachen, oder dann lieber den Atemega mir anschauen, das soll "zukunftssicher" sein. In dem Sinne das es mir auch im Beruf weiter hilft. Ich denke da wird keiner einen 8051 sehen wollen auch wenn er in 90% der Fälle die Aufgabe lösen wird.
lowpow schrieb: > Ich habe mich schonmal an das stm32 probiert doch erfolglos aufgegeben. Vielleicht solltest Du Dich daran nochmal versuchen. Was war denn das Problem? Vor allem wenn es darum geht: lowpow schrieb: > Die Frage ist, soll ich wirklich mit dem 8051 weitermachen, oder dann > lieber den Atemega mir anschauen, das soll "zukunftssicher" sein. In dem > Sinne das es mir auch im Beruf weiter hilft. Sehr viele aktuelle Controller basieren auf einem ARM-Core. Erfahrungen damit dürften Dir also im Beruf vermutlich helfen. Ob das nun STM32, NXP, Infineon oder sonst ein Hersteller ist, ist erst mal zweitrangig. Das "erfolglos aufgegeben" ist für den Beruf aber das kritischste. Denn wenn Du an diesem einen Controller "gescheitert" bist, dann ist die Wahrscheinlichkeit sehr hoch daß auch ein anderer Controller ähnlicher Komplexität ein Problem wird. Da würde ich also umso mehr dran arbeiten den zu beherrschen.
lowpow schrieb: > Ich denke da wird keiner > einen 8051 sehen wollen auch wenn er in 90% der Fälle die Aufgabe lösen > wird. Meines Wissens sind die 51'er Derivate immer noch die meistverkauften uC, wohl auch deshalb weil sie in der weisen Ware verbaut werden. Wie oben schon ausgeführt besitzen die Derivate von SilAbs Eigenschaften die man bei der Konkurrenz eher nicht findet. Wer aber meint unter einem STM32F4xxx (mit FPU) geht's nicht, dann bitte - ich halte solche Leute gewiss nicht auf.
Gerd E. schrieb: > Das "erfolglos aufgegeben" ist für den Beruf aber das kritischste. Denn > wenn Du an diesem einen Controller "gescheitert" bist, dann ist die > Wahrscheinlichkeit sehr hoch daß auch ein anderer Controller ähnlicher > Komplexität ein Problem wird. Da würde ich also umso mehr dran arbeiten > den zu beherrschen. Deshalb ist es eventuell doch sinnvoller erst mal klein (mit 8051 / AVR) anzufangen.
Lothar schrieb: >> Das reicht wohl noch nicht um irgendeine uC-Familie auszuschließen ;-) > > Genau damit ist Arduino ausgeschlossen :-) Arduino ist doch keine uC-Familie. lowpow schrieb: > das soll "zukunftssicher" sein. Vergiss den Sch*iss. Mach einfach jetzt das, was jetzt erforderlich ist und der Zukunft das, was da erforderlich ist Das wirst du est dann wissen, wenn es soweit ist ;-)
vloki schrieb: > wirst du erst dann wissen, wenn es soweit ist Eben. Im Automotive-Bereich werden z.B. oft Renesas RH850 eingesetzt. Damit würde sich privat niemand beschäftigen.
@il Conte (Gast) schrieb:
>> Das hier ist jedenfalls Schwachsinn.
Erkläre es der Forengemeinde.
Und Blackbird ist die Amsel.
Blackbird
il Conte schrieb: > weil sie in der weisen Ware verbaut werden. ...im Gegensatz zu denen, die in der dummen Ware verbaut sind? ;-)
Blackbird schrieb: > Und Blackbird ist die Amsel. Das macht die Sache ja noch schlimmer. Zieh dir mal die 'Long Line' von Gerhard Polt rein und warte bis zum Schluss wo's dann so richtig losgeht. Da kommt die 'AMSEL' aber gar nicht gut weg :-((
@il Conte, nicht abschweifen, keine Beleidigungen und keine Unterstellungen. Komm zur Sache. Blackbird
lowpow schrieb: > den Atemega mir anschauen, das soll "zukunftssicher" sein Da wird schon seit Jahren nichts mehr neu entwickelt und nachdem Microchip Atmel übernommen hat wird das sicher so bleiben: Beitrag "ATMEL verändert einige Dinge im ATMega" Bei 8051 ist erst Anfang 2016 eine ganz neue Familie rausgekommen: http://www.silabs.com/products/mcu/8-bit/efm8-laser-bee/Pages/efm8-laser-bee.aspx Außerdem kommen in allen stromsparenden SoC oder SiP 8051 zum Einsatz - keine AVR o.ä. https://www.elektormagazine.de/news/gas-sensoren-in-smartphones-aber-mit-einem-8051
Lothar schrieb: > Bitte was? Die haben mehrere interne Oszillatoren z.B. die 72 MHz > Version eben 72 MHz und 50 MHz und 80 kHz die man im Programm umschalten > kann - also nichts mit verfusen. EFM8 mit USB haben einen 48 MHz > internen präzisen Oszillator - kein Quarz erforderlich. Dann habe ich das Datenblatt wohl richtig verstanden: selbst bei den 72 MHz Versionen kann ein Quarzoszillator nur bis 25 MHz verwendet werden. Der "interne, präzise Oszillator" bietet +/- 2% Drift. Das reicht für eine Eieruhr - mehr leider nicht. il Conte schrieb: > Schlaff sind höchstens deine Aussagen! Du meckerst nur rum, völlig ohne Begründung, ohne Substanz!
Ich rate dir, schau die mal die Kinetis Linie von NXP (Freescale) an. Und dazu das KDS Studio mit dem Prozessor Expert. Es ist wirklich genial wenn man für Bastlerprojekte schnell und einfach was machen will. Kurz zum Prozessor-Expert (PE). Es ist ein Treiber-Generator und Konfigurator womit du grafisch Treiber konfigurieren und erstellen kannst. Damit kannst du Timer, ADC, DAC, Uart, sogar DMA, SPI, I2C, dig I/Os, usw grafisch konfigurieren ohne selber auf registerebene zu gehen. Der PE stellt dir dann Methoden bereit, um auf die Peripherie zuzugreifen. Auch ISR werden generiert, die du dann selber mit Code erweitern kannst. Ich bin persönlich sehr angetan davon, und es läuft erstaunlich gut (relativ wenig bugs). Der PE generiert dann den C code und bindet den automatisch mit ein. Jedoch kannst du den immer noch verändern, bzw auf registerebene selbständig weiterkonfigurieren. Am Besten schau dir das mal im youtube oder so an und bilde deine eigene Meinung dazu.
:
Bearbeitet durch User
m.n. schrieb: > Dann habe ich das Datenblatt wohl richtig verstanden: selbst bei den 72 > MHz Versionen kann ein Quarzoszillator nur bis 25 MHz verwendet werden. Das ist wohl ein Fehler im Datenblatt es sollen 50 MHz sein, außerdem hat hier einer 200 MHz getestet, soll auch gehen: http://community.silabs.com/t5/8-bit-MCU/Bad-EFM8LB1-Laser-Bee-Bootloader/m-p/173276#U173276 > Der "interne, präzise Oszillator" bietet +/- 2% Drift. Das reicht für > eine Eieruhr - mehr leider nicht. Für welche Anwendung bitte? Und die EFM8 USB haben +/- 1.5% und die 8051 mit CAN +/- 0.5% sind aber auch teurer: http://www.silabs.com/products/mcu/8-bit/c8051f56x/pages/c8051f56x.aspx
m.n. schrieb: > Der "interne, präzise Oszillator" bietet +/- 2% Drift. Das reicht für > eine Eieruhr - mehr leider nicht. Ich wiederhole es hier gern nochmals: > il Conte schrieb: >> Schlaff sind höchstens deine Aussagen! Du stellst dich über diese Firmen die solche Controller in 100-tausender Stückzahlen herstellen und verkaufen. Für eine stabile rs232, i2c, und CAN Verbindung reicht das allemal! Du machst dich hier nur lächerlich zur Belustigung der Mitleser.
In der Tat reichen 2% Drift für eine stabile UART Verbindung nicht aus. Es mag ja schon sein dass der µC bei normalen Temperaturen recht genau in der Frequenz ist, wird es mal kälter oder wärmer so vergrößert sich die Drift, kommt an die 2% Marke heran und die Geräte fangen an zu "Spinnen". Für einen Toaster mit Eieruhr-Funktion oder einer Waschmaschine mag der µC ja ok sein, aber nicht wenn man die Kommunikationsschnittstellen während dem Betrieb auch tatsächlich braucht.
Dorian H. schrieb: > ch rate dir, schau die mal die Kinetis Linie von NXP (Freescale) an. > Und dazu das KDS Studio mit dem Prozessor Expert. PE wird leider im neuesten KSDK nicht mehr unterstützt. Man kann den PE wohl manuell wieder kompatibel machen, sieht aber nicht so überzeugend aus.
Markus M. schrieb: > In der Tat reichen 2% Drift für eine stabile UART Verbindung nicht aus. Woher kommt das Gerücht schon wieder? Schau dir ein UART-Frame an und rechne aus, wie groß die relative Abweichung sein darf. Dann wirst du merken, dass 2%/µC (hier in Summe 4%) und sogar noch ein wenig mehr für eine stabile Kommunikation ausreichen. Und bitte keine andere Begründung. Nur weil viele Leute meinen, sie wüssten es besser, ist die Mathematik nicht falsch.
Lothar schrieb: > Das ist wohl ein Fehler im Datenblatt es sollen 50 MHz sein, außerdem > hat hier einer 200 MHz getestet, soll auch gehen: Vermutlich meinst Du einen ext. Quarzoszillator, der bis 50 MHz gehen darf. Dieser hat aber immer einige mA Stromaufnahme. Ich interessiere mich für einen einfachen Quarz, den man stromsparend auch abschalten kann. Lothar schrieb: >> Der "interne, präzise Oszillator" bietet +/- 2% Drift. Das reicht für >> eine Eieruhr - mehr leider nicht. > > Für welche Anwendung bitte? Für jegliche Art von Zeitmessung, die diesen Namen auch verdient.
avr schrieb: > Nur weil viele Leute meinen, sie wüssten es besser, ist die > Mathematik nicht falsch. Wo er recht hat, hat er recht.
m.n. schrieb: > Lothar schrieb: >>> Der "interne, präzise Oszillator" bietet +/- 2% Drift. Das reicht für >>> eine Eieruhr - mehr leider nicht. >> >> Für welche Anwendung bitte? Das hier ist richtig peinlich für dich. Du zitierst falsch! :-((((( Nicht von Lothar stammt diese Feststellung sondern von dir selber!! So was nennt man anderen Leuten was in die Tasche schieben.
Ein UART, 2% Drift. Nach 50 Bit ist das ganze schon um 1 Bit verschoben. Bei einem Datenstrom ohne Lücke kann es je nach dem ob der µC eine tolerante oder starre Synchronisierung hat schon zu Problemen kommen. Ich hatte schon das Problem, dass ab 0,5% es bei großen Datenmengen zu Aussetzern kam - je nach Inhalt vom Datenpaket!. Ein Uart funktioniert nur dann 100% Stabil bei <0,2% Fehler der Baudrate. Es gibt manche Peripherie Module die Synchronisieren bei jedem Bit, manche nur zu Anfang beim Start-Bit, manche nur bei Start-Bit wenn zuvor eine Übertragungspause war. CAN beispielsweise überträgt ca. 130 Bit in einem Frame, da werden 2% garantiert zum Fehler führen wenn man z.B 8x 0x00 im Datenpaket überträgt. Meine Erfahrungen aus der Praxis - kann mathematisch auch gerne anhand der unterschiedlichen Bit-Möglichkeiten der Daten-Byte im Paket auch selbst nachgerechnet werden.
m.n. schrieb: > Für jegliche Art von Zeitmessung, die diesen Namen auch verdient. Da bleibt dann wohl nur die Atomuhr übrig, wenn du solche Anforderungen stellst.
PS: +2% vom einen µC und -2% vom anderen µC = 4% Differenz! Wer für 2% Toleranz ist sollte das dann mathematisch gleich mit 4% Differenz durchrechen ;-)
Karl alias il conte nichts Gibt es wieder eine Hitzewelle? Ah, Ferienanfang!
Universal Asynchronous Receiver Transmitter mit Betonung auf A wie asynchron !!! @MM: Wenn deine Frickelei am UART mit 2% Abweichung nicht klar kommt, dann suche den Fehler lieber bei dir (und deiner SW) als der HW.
:
Bearbeitet durch User
Markus M. schrieb: > CAN beispielsweise überträgt ca. 130 Bit in einem Frame, da werden 2% > garantiert zum Fehler führen wenn man z.B 8x 0x00 im Datenpaket > überträgt. Ohne Bitstuffing wäre das sicher so. So! Und jetzt stelle ich meine Senfflasche wieder in den Kühlschrank ;-)
Markus M. schrieb: > Ein UART, 2% Drift. Nach 50 Bit ist das ganze schon um 1 Bit verschoben. Das erschreckt mich aber, du hast recht beim nächsten Design mit UART Anbindung werde ich einen temperaturgesteuerten Ofen-Quarz verwenden. Danke für den Hinweis.
Markus M. schrieb: > Ein UART, 2% Drift. Nach 50 Bit ist das ganze schon um 1 Bit verschoben. Ein normaler UART synchronisiert nach 1 Wort, was meist 7-9 Bits beträgt. Also was soll die Aufregung? 3-4% Fehler verkraftet so ein UART ohne Probleme.
Markus M. schrieb: > Ich hatte schon das Problem, dass ab 0,5% es bei großen Datenmengen zu > Aussetzern kam - je nach Inhalt vom Datenpaket!. Das ist auch meine Erfahrung. Ein AVR ist beim Synchronisieren ziemlich tolerant. Nach 10/16 (U2X = 0) bzw. 5/8 (U2X = 1) des Stopbits akzeptiert er bereits wieder die fallende Flanke des folgenden Startbits. Das kann man aber nicht auf alle anderen Uarts verallgemeinern, ein um 2% zu schneller mc-Sender führt bei vielen Geräten zu korrupten Daten. Zudem sollte man sich genau ansehen, in welchem Spannungs- und Temperaturbereich der interne Oscillator spezifiziert ist. Viele Grüße, Stefan
Cyblord -. schrieb: > 3-4% Fehler verkraftet so ein UART > ohne Probleme. Genauer: 3-4% Fehler verkraftet eine serielle Übertragungsstrecke ohne Probleme. Die besteht aber aus Sender, Strecke und Empfänger. Deshalb muss der Fehler mindestens auf Sender und Empfänger aufgeteilt werden, was einen zulässigen Einzelfehler von 2% (U2X = 0) bzw. 1,5% (U2X = 1) ausmacht. Wobei beide Geräte moderne, Sync-tolerante Uarts besitzen müssen. Diese Werte entsprechen auch den von Atmel angegebenen Recommended Max Receiver Error (%) von 2% (U2X = 0) bzw. 1,5% (U2X = 1) für 8 Bits / no parity (Atmega32 datasheet). Viele Grüße, Stefan
Um BTT zu kommen: Ein 32-bit µC (hier: ARM Cortex) hat auch seine Vorteile in Sachen "einfach". - Keine Gedanken um die "richtige" Bitanzahl einer Variable - keine nicht-Atomaren Zugriffe auf alles > 8 Bit - Vernünftiges, automatisches IRQ-Handling - ***Source-Level Debugger*** für fast lau - einfach Rechnen was man braucht (und nicht was der µC kann) - Kein Gehampel mit verschiedenen Speichersegmenten Klar ist die Peripherie umfangreicher, aber wer eine UART z.B. beim STM32 nicht in den Griff bekommt beschäftigt sich nicht annähernd mit dem µC. LPCs sind idR noch etwas einfacher.
Karl schrieb: > Ein 32-bit µC (hier: ARM Cortex) hat auch seine Vorteile > - ***Source-Level Debugger*** für fast lau Der Vorteil ist weg seit Silabs auf den Eval Boards für EFM8 8051 und EFM32 ARM für 25 EUR einen J-Link drauf hat - der J-Link übrigens mit STM32 realisiert :-) Markus M. schrieb: > CAN beispielsweise überträgt ca. 130 Bit in einem Frame, da werden 2% > garantiert zum Fehler führen wenn man z.B 8x 0x00 im Datenpaket > überträgt Wie gesagt daher haben die Silabs 8051 mit CAN auch einen +/- 0.5% internen Oszillator.
m.n. schrieb: > Ich interessiere > mich für einen einfachen Quarz, den man stromsparend auch abschalten > kann. EFM32LGxxx (EFM32WG, EFM32GG, u.a.) können das. 32kHz-Uhrenquarz und (32MHz) 48MHz-Quarz. können zu- und abgeschaltet werden. Blackbird
Blackbird schrieb: > EFM32LGxxx (EFM32WG, EFM32GG, u.a.) können das. 32kHz-Uhrenquarz und > (32MHz) 48MHz-Quarz. können zu- und abgeschaltet werden EFM8SB kann auch mit 32kHz-Uhrenquarz aber wenn ich das richtig verstanden habe ist User m.n. das nicht schnell genug für seine "Zeitmessung". Ansonsten können alle EFM8 nur mit max. 25MHz-Quarz das macht aber auch Sinn weil der Flash >25MHz einen Wait State braucht und dann kann man gleich den "ungenauen" internen 50MHz oder 72MHz Oszillator nehmen. Für ARM ist aber doch eigentlich 12MHz-Quarz üblich, man kann ja über PLL den erforderlichen Takt erreichen. Die LPC ARM mit USB oder CAN nutzen jedenfalls 12MHz-Quarz
Blackbird schrieb: > EFM32LGxxx (EFM32WG, EFM32GG, u.a.) können das. 32kHz-Uhrenquarz und > (32MHz) 48MHz-Quarz. können zu- und abgeschaltet werden. Schon klar, die Cortex-Mx können das wohl alle. Ich wollte es beim EFM8 wissen. Zwischenzeitlich habe ich das Simplicity Studio mal angeworfen: *.LST, *.A51 und *.M51 sehen ja aus wie vor 30 Jahren ;-) Auch bei den Control-Registern sieht man sehr deutlich, daß die Erweiterungen zum 8051 dazugefrickelt sind. Elegant geht anders. Lothar schrieb: > Ansonsten können alle EFM8 nur mit max. 25MHz-Quarz das > macht aber auch Sinn weil der Flash >25MHz einen Wait State braucht und > dann kann man gleich den "ungenauen" internen 50MHz oder 72MHz > Oszillator nehmen. Ah, Waitstates, der Teufel höchstpersönlich ;-) Das relativiert natürlich wieder die interne Geschwindigkeit. Ohne Frage, die Teile sind billig. Wer schön und teuer mag, der greife gleich zu Renesas' RX ;-)
Lothar schrieb: > Der Vorteil ist weg seit Silabs auf den Eval Boards für EFM8 8051 und > EFM32 ARM für 25 EUR einen J-Link drauf hat - der J-Link übrigens mit > STM32 realisiert :-) Es gibt ja nicht nur den EFM8. Ich behaupte, dass Source-Level Debugging in der 32-bit Welt häufiger und günstiger ist als in der 8-Bit Welt. Natürlich gibts auch JTAG für AVR und Co, aber so richtig überall dabei ist das nicht. Der EVAL-J-Link ist auch nur genau dazu gut, was der Name schon sagt. Die Lizenzbestimmungen reichen genau bis zur Kante des Eval-Boards. Wer damit leben kann, gut. IdR kann/will ich das nicht. Mag für Frickelei im Keller aber gehen...
Karl schrieb: > Der EVAL-J-Link ist auch nur genau dazu gut, was der Name schon sagt. > Die Lizenzbestimmungen reichen genau bis zur Kante des Eval-Boards. Silabs bewirbt aber dass der Eval Board J-Link der reguläre Debugger für externe EFM8 ist. Ist somit kein Eval J-Link: http://community.silabs.com/t5/8-bit-MCU-Knowledge-Base/How-to-use-EFM8-Starter-Kit-on-board-debugger-to-debug-an/ta-p/143619 Der reguläre Debugger für alle Silabs 8051 der "Toolstick" kostet aber auch nur 16 EUR
Da sind hoffentlich nicht verschiedene Versionen drauf wie bei den EFM32-EVAL-Boards: Alle EFM32WG-EVAL-Boards (STK3800) lassen sich via J-Link vom IAR downloaden und debuggen. Alle EFM32GG-EVAL-Boards (STK3700) nicht. Die TinyGecko-Boards (STK3600) funktionieren auch mit IAR. Vom Simplicity-Studio können alle EVAL-Boards via J-Link angesprochen werden. Verstehe es wer will. Blackbird
Hallo einen Preis für einen Satz Platinen kann ich dir leider nicht sagen. Das Board 1 mit dem ATmega 1284p wird bereits angeboten. Dazu auch ein Netzteil und einige andere Teile dazu. Die einzelnen Bauteile gibt es bei Versendern. Preis für das Board ca. 20 Taler mit allen dazu. Alle Unterlagen kannst du von mir bekommen bzw. stehen auch im Netz. Insgesamt gibt es zur Zeit ca. 50 verschiedene Platinen oder Erweiterungen. Teilweise mit recht anspruchsvollen Themen. Die Platinen Zeichnungen gibt es eigentlich in Sprint Leyout, aber man kann es zu anderen Sachen kopieren. Kann aber nicht sagen, ob alles dabei ist. Leider eskaliert der Streit um den besseren, einfacheren oder so Prozessor weiter. Es gibt viele verschiedene Systeme oder Hersteller. Für mich ist der richtige Prozessor, den ich verstehe, der einfach zu Programmieren ist und es muss genügend Hilfe dazu geben. Für einen Profi ist es egal. Ein Anfänger ist für jede Hilfe dankbar. Meine Sachen sind für Anfänger gedacht. Das wichtigste daran ist die Freunde wenn es funktioniert. achim
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.