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.
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:> Welcher µC ist einfach zu programmieren
Meinst du jetzt das Programm schreiben, zu compilieren, debuggen,
oder den Controller mit dem Code zu flashen?
@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. (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 ;-)
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.
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.
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 :-((
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.
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.
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 ;-)
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.
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...
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
