Hallo Forum, ich habe mir letztens ein paar Informationen geben lassen bezüglich der µC. Für meine Zwecke wurde der Attiny2313 empfohlen. Jetzt lautet meine Frage was für ein Nachteil würde es haben, wenn ich lieber einen stärkeren µC (z.B. Atmega8) nehme, ausser der Preisunterschied Gruß Koray
Das kannst du selbst ganz genau beantworten, wenn du die beiden Datenblätter miteinander vergleichst. Pinzahl? Pinfunktionen? Taktrate? Energiebedarf?, Abmessungen... Aufwändig wird es wenn eine vorhandene Schaltung für den Attiny2313 ausgelegt ist und du die für einen Atmega8 umbauen willst. Wenn du vollkommen frei in der Wahl des µC bist, sehe ich beim Atmega8 sogar Vorteile: Der Atmega8 hat nämlich einen ADC (mit mehreren Eingangskanälen) und der Atmega8 ist das "Arbeitspferd" im AVR-Tutorial.
Statt des Mega8 würde ich lieber den Mega88(A) oder Mega168(A) nehmen, die sind moderner und konnen mehr, bei weniger Stromverbrauch.
@Travel Rec. (travelrec) Benutzerseite >Statt des Mega8 würde ich lieber den Mega88(A) oder Mega168(A) nehmen, >die sind moderner und konnen mehr, bei weniger Stromverbrauch. Ich behaupte mal, dass 90% der Projekte das nicht benötigen und ebenso 90% der Hobbybastler die Grenze nicht ausreizen können. MfG Falk
aber genau diese 90% müssen sowas unbedingt haben, überlegmal wieviel Geld du sparen kannst, wenn eine Schaltung 2W im Jahr weniger braucht ;-) ausserdem lieber oversized wenn es nicht zu teuer wird, als beim nächsten Software Update undersized
Falk Brunner schrieb: > Ich behaupte mal, dass 90% der Projekte das nicht benötigen und ebenso > 90% der Hobbybastler die Grenze nicht ausreizen können. Daran liegts nicht. Atmel hat seine MCs in mehreren Stufen gepimt, z.B. die 28-Pinner: 1. AT90S4433 2. ATmega8 3. ATmega48..168 4. ATmega48p...328p Für neue Projekte liegt es also nahe, einfach die aktuellste Version zu nehmen. Peter
Nur leider sind die Tutorien fast alle auf den ATmega8 getrimmt- und für den Anfang ist es doch ganz praktisch, die Sachen "genau so" machen zu können und nicht erst nach mühsehligem Datenblattsuchen die Sache "doch nocht irgendwie" hinzbekommen, indem alle Registereinstellungen durchprobiert werden. Aber das gilt nur für Anfänger. Für den Rest stimme ich uneingeschränkt zu (es sei denn, man hat noch viele alte Schippse in der Schublade liegen). Viele Grüße Nicolas
@Peter Dannegger (peda) >Für neue Projekte liegt es also nahe, einfach die aktuellste Version zu >nehmen. Für Leute, die sich mit der Materie auskennen ja. Für Anfänger und Nachbauer definitiv nein. MFG Falk
Hi
>Für Anfänger und Nachbauer definitiv nein.
Warum willst du Anfängern Debug-Wire verweigern? Das hat der ATMega8
z.B. definitiv nicht.
MfG Spess
@ spess53 (Gast) >Warum willst du Anfängern Debug-Wire verweigern? Immer diese Unterstellungen? Bist du Anwalt? ;-) > Das hat der ATMega8 z.B. definitiv nicht. Ja, aber denkst du das hilft einem ANFÄNGER großartig, der schon mit ner blinkenden LED seine Probleme hat? Und wie gesagt, die Tutorials sind größtenteils auf den Atmega8 zugeschnitten. Welcher dafür vollkommen OK ist. Willst du sie umschreiben? Im Halbjahresrhytmus, weil es neue Controller gibt? Und viele Anfänger habe eh kein Kabel für Debugwire, weil sie erstmal mit minimalen Kosten einsteigen wollen. Der Simulator reicht zum Lernen erstmal. MFG Falk
spess53 schrieb: > Warum willst du Anfängern Debug-Wire verweigern? Das hat der ATMega8 > z.B. definitiv nicht. Dann sollte sich mal jemand opfern und das Tut auf Mega88(A)(P) plus Dragon umschreiben bzw. ergänzen.
Hier sind alle Erweiterungen aufgelistet. Möge der Anwender entscheiden. http://www.atmel.com/dyn/resources/prod_documents/doc2553.pdf
Wenn man nicht zu kompliziert arbeitet dann sind die Controller doch direkt kompatibel. Nur in wenigen Fällen hat sich viel intern geändert, und das kann man anhand der mirgration notes nachvollziehen. Nen "alten" Controller würde ich nur nehmen, wenn man ein altes Projekt 1:1 nachbauen will und sich nicht um Details kümmern möchte (so plane ich es zB gerade für den AVR-Transistortester).
@A. K. (prx) >Dann sollte sich mal jemand opfern und das Tut auf Mega88(A)(P) plus >Dragon umschreiben bzw. ergänzen. Dann geh mal mit gutem Beispiel vorran! Aber bitte auch solide TESTEN!!! MFG Falk
ATmega8, 16, 32, 128.. würde ich aus einem Grund nicht mehr verwenden. Bei dieser Generation herrscht noch ein ziemliches Chaos bei den Registern Das mag im Einzelfall keine Rolle spielen, aber wenn man sich eine Library schreiben will, die auch für anderen AVR Funktioniert, fängt man doch ziemlich das Fluchen an, weil man mit einer regelrechten #if defined() Orgie nicht nur die unterschiedlichen Registernamen zuordnen muss sondern teilweise auch verschiedene Codesegmente braucht. Wer schonmal versucht hat, eine universelle USART Routine zu schreiben, weiß, wovon ich rede. Da sind die Xmega ein echter Segen
Martin Gerken schrieb: > Wenn man nicht zu kompliziert arbeitet dann sind die Controller doch > direkt kompatibel. Ach ja? Fängt doch schon bei den anders benannten (und teilweise auch anders anzusprechenden, Stichwort URSEL) USART-Registern an. USART dürfte bei vielen mit eines der ersten Dinge sein, die sie zum Laufen bringen wollen. Andreas
@ Andreas Ferber (aferber) >Ach ja? Fängt doch schon bei den anders benannten (und teilweise auch >anders anzusprechenden, Stichwort URSEL) USART-Registern an. USART >dürfte bei vielen mit eines der ersten Dinge sein, die sie zum Laufen >bringen wollen. Stimmt, hier hat Atmel eher gebastelt. Eine orthogonale Strktur ist das nicht. Und warum? Um ein paar Hunder Gatter un ein paar um Chipfläche zu sparen?!? Dort ist der MSP430 deutlich besser. Dort ist z.B. Timer 0 in alles Derivaten identisch, oder? MFG Falk
Falk Brunner schrieb: > Stimmt, hier hat Atmel eher gebastelt. Eine orthogonale Strktur ist das > nicht. Und warum? Um ein paar Hunder Gatter un ein paar um Chipfläche zu > sparen?!? Gebastelt sicher nicht. Ist einfach historisch gewachsen. Atmel hat wohl versucht, zu den älteren Modellen möglichst kompatibel zu sein. Stichwort ATmega128 und PortF ist das glaube ich, bei dem ein Register aus der Reihe schlägt > Dort ist der MSP430 deutlich besser. Dort ist z.B. Timer 0 in > alles Derivaten identisch, oder? Ich weiß nicht, wie es bei den MSP430 ist, aber bei den Xmega hat Atmel eindeutig gelernt und gnadenlos aufgeräumt. Viel strukturierter geht es eigentlich kaum noch
Falk Brunner schrieb: >>Ach ja? Fängt doch schon bei den anders benannten (und teilweise auch >>anders anzusprechenden, Stichwort URSEL) USART-Registern an. USART >>dürfte bei vielen mit eines der ersten Dinge sein, die sie zum Laufen >>bringen wollen. > Stimmt, hier hat Atmel eher gebastelt. Eine orthogonale Strktur ist das > nicht. Und warum? Um ein paar Hunder Gatter un ein paar um Chipfläche zu > sparen?!? Die Register gehen beim ATmega8 genau bis 0x3f, sind also komplett mit IN/OUT verwendbar. Für nur ein Register mehr (das man hier durch die Doppelbelegung gespart hat) hätte man ein zusätzliches Adressbit gebraucht, und hätte genau ein Register gehabt, bei dem IN/OUT nicht mehr geht. OK, beim ATmega8 gibt es noch ein paar reservierte Register, die sind aber beim ATmega16 alle in Verwendung. Beim ATmega88 brauchte man dann sowieso mehr Register, daher wurde die Doppelbelegung aufgelöst (und das freiwerdende Bit in UCSRC/UCSR0C konnte man auch gut gebrauchen). Generell sieht das beim ATmega88 alles etwas "weitsichtiger" aus, exemplarisch z.B. die Benennung der USART-Register jeweils mit "0" drin, obwohl es nur einen USART gibt. Das macht dann die spätere Portierung auf Controller mit mehreren USARTs einfacher. Andreas
@ Andreas Ferber (aferber) >Die Register gehen beim ATmega8 genau bis 0x3f, sind also komplett mit >IN/OUT verwendbar. Für nur ein Register mehr (das man hier durch die >Doppelbelegung gespart hat) hätte man ein zusätzliches Adressbit >gebraucht, und hätte genau ein Register gehabt, bei dem IN/OUT nicht >mehr geht. OK, beim ATmega8 gibt es noch ein paar reservierte Register, >die sind aber beim ATmega16 alle in Verwendung. Einen Mirkocontroller entwirft man nciht als Einzelexemplar, sondern als Familie. Und da ist etwas Planung und Strategie nicht von Nachteil. >Beim ATmega88 brauchte man dann sowieso mehr Register, daher wurde die >Doppelbelegung aufgelöst (und das freiwerdende Bit in UCSRC/UCSR0C >konnte man auch gut gebrauchen). Das ist Bastlerdenken. Eben um diese paar Gatter einzusparen. MFG Falk
Falk Brunner schrieb: > Einen Mirkocontroller entwirft man nciht als Einzelexemplar, sondern als > Familie. Was zu Anfang leider versäumt wurde. Man sieht deutlich, wie verschiedene Köche in dem AVR-Brei rumgerührt haben. Und bei den Timern ist immer noch kein System zu erkennen. Die ATmega haben z.B. keinen Dead Time Generator und keine PLL und die ATtiny fast nur 8 oder 10Bit Timer. Peter
Peter Dannegger schrieb: > Die ATmega haben z.B. keinen Dead Time Generator Dafür gibt's ja die AT90PWM. Aber stimmt schon - ist ziemlich viel Kleinklein. Hier ein Spezialteil, dort ein Spezialteil.
Wiso nimmt man nicht einfach einen STM32. Da gibts diese Pheriperieunterschiede nicht. Über 110 Varianten und die Pheriperie ist in allen gleich. Das ist ein ausgereifter Controllertyp. Aus Erfahrung kann ich nur den empfehlen. Egal was man für ein Problem hat, der deckt alles ab.
Falk Brunner schrieb: > Einen Mirkocontroller entwirft man nciht als Einzelexemplar, sondern als > Familie. Und da ist etwas Planung und Strategie nicht von Nachteil. Halte mal die Registermap des AT90S8515 neben die vom ATmega16. Im Detail gibt es natürlich Änderungen, im großen und ganzen sind die Registeradressen aber lange stabil geblieben. An Register wie UBRRH hat damals noch keiner gedacht, vermutlich weil niemand damit gerechnet hat, dass 8 Bit-Mikrocontroller irgendwann mal mit deutlich über 8 MHz laufen würden. >>Beim ATmega88 brauchte man dann sowieso mehr Register, daher wurde die >>Doppelbelegung aufgelöst (und das freiwerdende Bit in UCSRC/UCSR0C >>konnte man auch gut gebrauchen). > Das ist Bastlerdenken. Eben um diese paar Gatter einzusparen. Auf mich macht das nicht den Eindruck, als wäre es um ein paar Gatter gegangen. Man hat solange wie möglich versucht, mit dem durch die Befehlsarchitektur vorgegebenen Limit von 64 Adressen hinzukommen (auch wenn es kein "hartes" Limit war, da die IO-Register schon immer auch Memory Mapped erreichbar waren, allerdings weniger performant). Erst als durch immer mehr Peripherie das absolut nicht mehr haltbar war, hat man eine generelle Erweiterung und Neuaufteilung des IO-Adressraumes vorgenommen, dabei sind dann nicht mehr viele Register an ihrem alten Platz geblieben, und es wurde (auch und gerade in den Bereichen <= 0x1f für SBI/CBI und <= 0x3f für IN/OUT) reichlich Freiraum geschaffen für spätere Erweiterungen. Seitdem ist der IO-Space dann wieder relativ stabil geblieben. Andreas
Markus Müller schrieb: > Wiso nimmt man nicht einfach einen STM32. Den kannte eben 1997 noch keiner. MCs werden ja nicht erst seit 2010 eingesetzt. > Egal was man für ein Problem > hat, der deckt alles ab. Leider nicht. Die 6 .. 28 Pinner und 1,8 .. 5,5V deckt er nicht ab. Peter
@ Andreas Ferber (aferber) >An Register wie UBRRH hat damals noch keiner gedacht, vermutlich weil >niemand damit gerechnet hat, dass 8 Bit-Mikrocontroller irgendwann mal >mit deutlich über 8 MHz laufen würden. Klar, weil ja selbst die UrAVRs schon 20 MHz konnten . . . >Auf mich macht das nicht den Eindruck, als wäre es um ein paar Gatter >gegangen. Auf mich schon. > Man hat solange wie möglich versucht, mit dem durch die >Befehlsarchitektur vorgegebenen Limit von 64 Adressen hinzukommen (auch >wenn es kein "hartes" Limit war, da die IO-Register schon immer auch >Memory Mapped erreichbar waren, allerdings weniger performant). Die Architektur war auch am Anfang größer, als es die verfügbaren Typen waren. Allein schon das Ganze Gemache mit 22 Bit PC etc. >spätere Erweiterungen. Seitdem ist der IO-Space dann wieder relativ >stabil geblieben. Ja, relativ. Aber was solls. Das Problem hat Atmel erkannt und wie man hört bei dem Xmegas ausgeräumt. Eine Baustelle für Programmierer weniger. MFG Falk
@ Markus Müller (mmvisual) >Wiso nimmt man nicht einfach einen STM32. Weil trotz der gewissen Macken der AVR immer noch ein sehr schöner Mikrocontroller ist. Und deine neue Religion Zeit braucht, viele Anhänger um sich zu scharren ;-) >Aus Erfahrung kann ich nur den empfehlen. Egal was man für ein Problem >hat, der deckt alles ab. Kaum. Die Wunderschraube, die auf M3 bis M100 passt gibt es nicht. Auch nicht als Mikrocontroller ;-) MFG Falk
Peter Dannegger schrieb: > Die 6 .. 28 Pinner und 1,8 .. 5,5V deckt er nicht ab. Cortex-M0 Controller mit 2,5-5,5V sind immerhin angekündigt (NuMicro). Und da sage noch einer, 5V wäre tot ;-).
Markus Müller schrieb: > Wiso nimmt man nicht einfach einen STM32. Weil das ein 32 Bit Controller ist, den nicht jeder braucht? Und bevor ich mich mit ARM rumschlage nehm ich erstmal die Xmega. Die sind auch aufgeräumt
eheheh, wusst ichs doch. Wird nur drauf eingehauen. Ihr banausen. Anstatt den Artikel STM32 mal zu lesen...
@ Markus Müller (mmvisual)
>Anstatt den Artikel STM32 mal zu lesen...
Klar, die Barbaren kann man nicht so leicht zum Evangelium bekehren,
Revernd Müller ;-)
Ich wollte schon immer mal bei dem Streit AVR - STM32 mitmachen. Also mal mein Beitrag hierzu: Markus Müller schrieb: > Wiso nimmt man nicht einfach einen STM32. > >... > > Aus Erfahrung kann ich nur den empfehlen. Egal was man für ein Problem > > hat, der deckt alles ab. Warum man nicht den STM32 nehmen sollte? Erstmal sollte man das nicht tun, weil du stääändig bei jedem Thread wo man auch nur im Entferntesten vom STM32 sprechen könnte, deinen Marketinggenerator rausholst und los sabbelst. Das geht einem sowas von auf die Eier. Dann möchte ich das mal aus einer etwas anderen Perspektive beleuchten. Ich bin Fotograf. Leidenschaftlich hoch 10 und so.. Jo. Warum ich nach wie vor eine DSLR von Anno keine Ahnung besitze? Weil ich damit das machen kann was ich will. Fotos. Sicher es gibt neue Kameras die haben weniger Rauschen und viel mehr Bilder/s und sogar Videofunktion! Toll! Wirklich! Brauch ich aber nich. Ich kenne meine Kamera. Meine Kamera kennt mich. Funktioniert. Schön. Der Nachteil gegenüber etwas "besserem" ist doch meist auch der Funktionsumfang und damit das Unbekannte oder Ungewohnte. Du kannst nem schlechten Fotomann ne Mamiya in die Hand drücken und er wird schlechtere Fotos machen als mit jedem Aldi Teil. Bei ucs ist das ganze nicht anders. Warum sollte er, wenn jemand ihm einen ATtiny(!) empfiehlt, einen 32-bit Prozessor verwenden mit Funktionen die beim Reifenwechsel anfangen und kurz vorm Beglücken der Ehefrau enden? Ich kann dieses undifferenzierte gelaber einfach nicht ab. Es kommt IMMER darauf an was man schon kann und was man machen möchte.
Ja, Falk, Du hast auch einiges zu dem STM Artikel beigetragen, vielen Dank! Sorry, ich bin nun mal leidenschaftlich vom STM32 überzeugt... Irgend jemand muss ja den Gegenpol zum AVR spielen.
Markus Müller schrieb: > Irgend jemand muss ja den Gegenpol zum AVR spielen. ...den gibt's doch schon in Form von 8051, PIC, MSP430, STR7, MB90Fxxx, R8/R16, AT91, AT32, TMS470 und viele andere mehr. Ein weiteres "Gegenpölchen" im Strudel der Controller wird's da so schnell nicht reissen...
"Nimm doch statt einem Tiny einen STM32" Klar, kein Problem, ist in einer halben Stunde auf den neuen µC migriert, Hardware und Software hat man vorgehalten, Einarbeitung in die Programmierumgebung würd ich mit 5-10 Minuten ansetzen. Wer von euch kann schon mit MS Word richtig umgehen? Ich würd mal sagen 95% aller User können den vollen Funktionsumfang von Word garnicht nutzen. Analog dazu Photoshop. Ein Füllhorn voller toller Werkzeuge, von denen keiner weiß wozu sie alle gut sind.
Ich kenne die PICs gut. Jeder PIC hat eine andere Pheriperie drin, irgend welche Bits sind anders, andere Position, mehr oder weniger Funktionen, selbst bei den neuen PIC24. Jedesmal muss man das Datenblatt wieder neu studieren was denn jetzt schon wieder anders ist. Wenn man viel entwickelt ist das doch nervig, lästig und Zeitintensiv. Hingegen beim STM32 ist die Pheriperie durchgängig gleich. Punkt. Einmal ins Datenblatt geschaut und gelernt, für alle Derivate anwendbar. Da oben diskutiert wurde was das für eine schlechte Atmel-Angelegenheit ist, konnte ich es nicht verkneifen den STM32 mit in diese Diskussion zu werfen. Nach wie vor bin ich der Meinung, dass es leichter ist einmal den STM32/Cortex/ST FW-Lib zu kapieren als jedes mal, wenn man einen anderen AVR braucht wieder neu das Datenblatt zu studieren. Ich hatte in den letzten 20 Jahren schon einige durchgemacht, Z80, 68HC11, AT90CAN128, AVR, PIC, dsPIC, M16C, LPC2294, LPC2368. Den C166 wollte ich mal, ist aber schwer beschaffbar. Aber alle haben irgend welche "Macken". Der einzige Nachteil des STM32F107xx ist, dass der kein SDIO mit drin hat.
nur nicht jeder braucht einen 32 Bit Controller mit 40 IO und mehr. Viele BRAUCHEN vielleicht mal einen kleinen Controller im 8 Pin SSOP Gehäuse, selbst wenn ein STM32 mit 128kB Flash genauso teuer ist wie der 8 Pin µC mit 1kB. Andere arbeiten seit Jahren mit AVR, brauchen etwas mehr Leistung, wollen aber nicht das gesamte Equipment (Programmer, IDE...) wegwerfen und neu kaufen. Dann schaut man sich halt erstmal die Xmega an. Vielleicht sind die Xmega doppelt so teuer wie die STM32, aber für das bei der Entwicklungsumgebung eingesparten Geld kann man nen ganzen Haufen Xmega kaufen (nicht alle arbeiten mit dem GCC) Also lass stecken. Wer mit dem STM32 arbeiten will wird schon von alleine drauf kommen
Es soll sogar Leute geben, die 6-Pin AVRs als adaptive Spannungsregler einsetzen. Und die kosten nicht mal mehr, als ein Spannungsregler...
Travel Rec. schrieb: > Es soll sogar Leute geben, die 6-Pin AVRs als adaptive Spannungsregler > einsetzen. Und die kosten nicht mal mehr, als ein Spannungsregler... Das würde mich interessieren. Gibts dazu was online?
MarkusB schrieb: > Andere arbeiten seit Jahren mit AVR, brauchen etwas mehr Leistung, > wollen aber nicht das gesamte Equipment (Programmer, IDE...) wegwerfen > und neu kaufen. Dann schaut man sich halt erstmal die Xmega an. > > Vielleicht sind die Xmega doppelt so teuer wie die STM32, aber für das > bei der Entwicklungsumgebung eingesparten Geld kann man nen ganzen > Haufen Xmega kaufen (nicht alle arbeiten mit dem GCC) Das ist ein Grund. Ein weiterer ist die Erfahrung, die man mit der bisher eingesetzten Familie hat. Jeder Controller hat seine "Macken" und man arbeitet sich nicht in eine neue Familie ein, nur weil dort der passende Typ 50 Cent günstiger wäre (es sei denn, man hat sehr hohe Stückzahlen). Wir arbeiten hier z.B. fast ausschließlich mit AVRs - die kennen wir aus dem FF und bisher sind sie für uns vollkommen ausreichend. Es kommen zu den (relativ kleinen) Beträgen der neuen Software/Hardware also noch die Einarbeitungszeit + Risiken + Bibliotheksanpassung bei der Umstellung. > Also lass stecken. Wer mit dem STM32 arbeiten will wird schon von > alleine drauf kommen Interessant ist er auf jeden Fall :-) Chris D.
Chris D. schrieb: > Interessant ist er auf jeden Fall :-) Zweifellos. Ich hab mir gerade mal einen raus gepickt und überflogen. Was mich schon auf den ersten Blick gestört hat war, dass da zwar stand "Bis zu 12 Timer", aber beim zweiten Blick entpuppt sich das dann in "ja, 2 Timer können das, 3 können das, einer ist der Watchdog, ein andere Systick usw" Bei dem Xmega: "acht 16 Bit Timer, alle können das selbe, Punkt Ende".
MarkusB schrieb: >> Es soll sogar Leute geben, die 6-Pin AVRs als adaptive Spannungsregler >> einsetzen. Und die kosten nicht mal mehr, als ein Spannungsregler... > > Das würde mich interessieren. Gibts dazu was online? Nö, aber bei mir auf dem Labortisch ;-).
MarkusB schrieb: > "Bis zu 12 Timer", aber beim zweiten Blick entpuppt sich das dann in > "ja, 2 Timer können das, 3 können das, einer ist der Watchdog, ein > andere Systick usw" Yep, Watchdogs und RTCs mit den übrigens Timern in einen Topf zu werfen ist keine gute Idee. Ist aber nur die Zählweise, das Marketinggewäsch auf Seite 1 vom Datasheet. Wenn man diesen Unfug abzieht bleiben bei den nicht funktionsspezifischen Timern 3 Varianten übrig: (1) Ein paar ganz einfache ohne externe Funktion. (2) Die universellen mit capture/PWM/... (3) Ein paar von (2) haben zusätzlich motor control PWM features, sind aber sonst identisch. Den Systick hat man mit dem Cortex-Core immer drin, da kann ST nix für. > Bei dem Xmega: "acht 16 Bit Timer, alle können das selbe, Punkt Ende". Hmm. Ich komme bei den "A" Typen auf 4 verschiedene: Die TCs, den Watchdog und zwei Sorten RTCs.
A. K. schrieb: > Hmm. Ich komme bei den "A" Typen auf 4 verschiedene: Die TCs, den > Watchdog und zwei Sorten RTCs. Ich hab ja nur die T/C gezählt. Mit RTC, Watchdog usw kommt ich auch auf 10 oder 11 Timer. Aber ich hab für Marketing Gewäsch nix übrig War halt typisch. Ich lese auf der Webseite in der Übersicht "blablabla 12 Timer blablabla". Woah, 12 Timer? Geil. Dann ein Blick ins Datenblatt... Ich weiß, die Aussage ist korrekt, aber halt doof.
Moment mal. Der STM32F103xF / STM32F103xG hat 14 Timer*. Davon: - 2 mit Motion Control (4 Ausgänge + 4 negierte Ausgänge) - 2 Interne vollwertige Timer (nur ohne Pins nach aussen) - 10 mit 1..4 nach aussen geführten Pins. Im Artikel STM32 steht was mit 16 Timern, woher die Zahl kommt weiß ich nicht, im Product Selector von ST kann auch nur 14 eingegeben werden. Ich habs mal im Artikel richtig gestellt. *(Systic, RTC und WDG nicht mitgerechnet)
Sehr geehrter Herr Müller, kannst Du jetzt vielleicht mal langsam mit Deinem STM-Gespamme aufhören? Jeder dritte Thread in dem es um direkte Fragen zu Controllern geht, wird von Dir gekapert, um Deinen ach so tollen Controller hervorzuheben. Wir wissen es inzwischen! Wenn Du wieder etwas Neues in den Datenblättern gefunden hast, behalt´s für Dich. Wir können selber lesen. Hochachtungsvoll!
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.