Hallo,
immer wieder bekomme ich zu hören, "geh auf stm32" oder "nimm was
vernünftiges wie einen stm32" usw.
Alles was ich bisher verstanden habe ist, das die 32Bit statt 8Bit
sind/haben.
Ich habe ein lerndefizit. Ich verstehe was man mir "erklärt" aber
beschreibungen z.b. verstehe ich nicht wirklich.
Was ich jedoch auch bisher gesehen habe ist das der Code mal total
anders und "komplizierter?" ist!?
Um mir das mal "vorzustellen" kann mir da mal jemand eine beispiel
machen?
Sagen wir PA1 soll High, dann würde man bei AVR machen:
1
#include<avr/io.h>
2
3
DDRA|=(1<<PA1);// pin als Ausgang
4
PORTA|=(1<<PA1);// PIN auf HIGH
Wie würde das nun bei ST sein? Sagen wir direkt für einen 32Bitter,
sagen wir STM32F0. Halten wir auch "erstmal" an dem fest.
Sinn dieses Thread ist es das ich das ganze ein wenig verstehe und mich
doch dazu "bewegen" kann auf STMs zu "wechseln".
Was ist "besser"? Also ich habe schon gesehen die können direkt USB und
DSP, SD-Karte, uvm.
Also können die alles was ein AVR auch kann? Bzw sogar noch viel mehr?
Bisher bin ich immer mit einem ATMega128A ausgekommen. Das ist so mein
"standart" uC für alles, ob 1 LED oder nen Display mit Touch.
Welcher "könnte" mein "Standart" STM werden?
Wie Flasht man die? C ist ja eigentlich C. Also sollte die "umstellung"
ja nicht so schwer werden. Klar haben die ne andere lib als avr aber
auch so "einfach" oder sagen wir "anwenderfreundlich"?
Was würde ich benötigen? Wie werden die Standart beschaltet? Wie AVRs?
5V, Abblockkondis und fertig?
Ich würde mich freuen wenn ihr mir da ein wenig behilflich sein könntet.
Werden die STMs und deren C-Code hier genau so supportet wie auch die
AVRs?
Danke euch
Antoli B. schrieb:> Sinn dieses Thread ist es das ich das ganze ein wenig verstehe und mich> doch dazu "bewegen" kann auf STMs zu "wechseln".
Aha. Und dafür sollen wir unsere Zeit opfern??? Dann bleib doch bei den
AVRs und gut ist... Keiner zwingt dich auf ARM zu wechseln.
Antoli B. schrieb:> Was ist "besser"?
So ziemlich alles :-) Das versteht man aber nur, wenn man sich einige
Zeit (bei mir sind es mittlerweile fast 8 Jahre) damit beschäftigt.
Antoli B. schrieb:> Also können die alles was ein AVR auch kann? Bzw sogar noch viel mehr?
Ja.
Antoli B. schrieb:> Bisher bin ich immer mit einem ATMega128A ausgekommen. Das ist so mein> "standart" uC für alles, ob 1 LED oder nen Display mit Touch.
Wenn dass dein "standart" ist, dann bleib dabei. Kennst die toolchain,
die Doku, die Macken...
Mein "STANDARD" ist der STM32F030. Billiger als ein AVR und kann davon
ein Vielfaches.
Antoli B. schrieb:> Welcher "könnte" mein "Standart" STM werden?
Auch Ingenieure können Rechtschreibung :-)
Antoli B. schrieb:> Wie Flasht man die?
Liest du bitte selber nach... Falls keine Lust dazu: Lehrgang belegen.
Kostet zwar, aber wenn man selber nicht die (übrigens hervorragende)
Doku lesen will...
Antoli B. schrieb:> Also sollte die "umstellung"> ja nicht so schwer werden. Klar haben die ne andere lib als avr aber> auch so "einfach" oder sagen wir "anwenderfreundlich"?
Definitiv. Vieles ist sinnvoller anzusteuern und man merkt dass das
Design insgesamt den AVRs einiges voraus ist (kein Wunder, ist ja auch
Jahrzehnte jünger). Unabhängig davon sind auch die AVRs gute uC.
Antoli B. schrieb:> Was würde ich benötigen?
Irgend ein Demo-Board, da ist schon alles drauf. z.B. diesen hier:
http://www.st.com/en/evaluation-tools/stm32f0discovery.html
Ansonsten Datenblatt und Reference Manual.
Antoli B. schrieb:> Wie werden die Standart beschaltet?
Nach Herstellerangaben :-)
http://www.st.com/content/ccc/resource/technical/document/application_note/91/66/2d/8c/f9/b5/47/55/DM00089834.pdf/files/DM00089834.pdf/jcr:content/translations/en.DM00089834.pdfAntoli B. schrieb:> Werden die STMs und deren C-Code hier genau so supportet wie auch die> AVRs?
Na ja, was heisst supportet? Musst schon selber das RefMan lesen,
verstehen und implementieren können. Wenn die Frage erkennen lässt, dass
du dich mit der Fragestellung beschäftigt hast, so solltest du auch eine
hilfreiche Antwort bekommen.
> #include <avr/io.h>>> DDRA |= (1<<PA1); // pin als Ausgang> PORTA |= (1<<PA1); // PIN auf HIGH
IAR & STM8:
#include "iostm8.h"
PA_DDR_DDR1 = 1;
PA_CR1_C11 = 1; // Port A, pin 1 is Push-Pull
PA_ODR_ODR1 = 1;
Grob gesagt, die 32Bitter sind nen Zacken schneller und komplexer, als
die 8Bitter, das ist alles.
Die ARM-Cortex sind auch nicht aus einer Hand, sondern es gibt mehrere
bekannte Herstellerfamilien, z.B. ADUCM3, ATSAM3, EFM32, LPC, STM32. Der
CPU-Core ist gleich, aber in der Peripherie gibt es erhebliche
Unterschiede.
Daher kann es sein, daß manchmal eine freie Toolchain etwas schwer für
das gewünschte Target zu konfigurieren ist.
Wenn Du keine Laufzeitprobleme hast oder besondere Peripherie brauchst,
bringt der Umstieg auf 32Bit nichts.
Der Core im AVR <> Cortex ist im prinzip doch dem Entwickler völlig
egal.
Einziger Unterschied: Wenn man mit einer 8-Bit CPU mit 32 Bit Zahlen
rechnet, dann muss man sicherstellen wass kein Interrupt die einzelnen
8-Bit Zahlen durcheinander würfelt, das kann einer 32 Bit CPU nicht
passieren.
Ansonsten sind gegenüber dem AVR im STM32 nicht nur viel mehr
Peripheriemodule, sonderen diese bieten auch weit mehr Funktionalität.
Und genau das ist der Haupt-Vorteil gegenüber einem AVR.
Alle Hersteller die µC mit Cortex Kern herstellen bieten zudem eine
komplexere Clock-Struktur. Intern/Extern/Hispeed/Low/RCC usw. Da muss
man einfach durch.
Die Datenblätter und Reference-Manuals sind schon sehr dick. Jedoch
Teile, die man nicht braucht (z.B. USB oder Kamera-Interface), solche
Kapitel braucht man auch nicht lesen.
Wenn man den Clock einer Peripherie nicht einschaltet, dann ist es so
als wenn die Peripherie nicht existiert - ist auch ein Fehler den man
gerne macht (z.B. man möchte PortA nutzen und schaltet den Clock dazu
nicht ein)
Peter D. schrieb:> Wenn Du keine Laufzeitprobleme hast oder besondere Peripherie brauchst,> bringt der Umstieg auf 32Bit nichts.
Und das ist mit effizienter Programmierung in >90% der Fälle so.
Holger schrieb:> Mein "STANDARD" ist der STM32F030. Billiger als ein AVR und kann davon> ein Vielfaches.
Der eine Typ ist hier, der andere da billiger.
Von ein "Vielfaches können" kann höchstens in Bezug auf die Leistung die
Rede sein. Wenn man die denn braucht- s.o.
> Lehrgang belegen.> Kostet zwar, aber wenn man selber nicht die (übrigens hervorragende)> Doku lesen will...
Genau. Da trifft "Vielfaches" auf jeden Fall zu. Vielfaches lernen
nämlich. Und wer mal ein AVR-Datenblatt mit einem ARM verglichen hat
weiss, was da hinsichtlich Übersichtlichkeit und Kürze hervorragt.
> Definitiv. Vieles ist sinnvoller anzusteuern
Vieles ist definitiv komplizierter anzusteuern :)
Ich nutze die STM32 hauptsächlich weil diese die Peripherie bieten, die
ich brauchen. Ich lasse den meist mit 8MHz laufen. Und sollte es doch
eng werden kann ich problemlos auch die PLL dazu nehmen.
Und für kleinere Projekte kommt von da her auch nur ein STM32F0xx in
Frage, da ich STM32 kenne und keine Lust habe mir einen AVR dafür an zu
tun.
Es ist im Prinzip genau das Gleiche.
Beim Arm muss nur zusätzlich der Port an den Bus zugeschaltet werden:
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE);
DDRA |= (1<<PA1); // pin als Ausgang
beim AVR gibt es nur Eingang und Ausgang, also 1Bit gestzt oder nicht
gesetzt, Beim Arm sind hier 4Bits die gesetzt werden können, um den Pin
zu konfigurieren.
GPIOA->CRL |= (0b????<<(PAx*4));
PORTA |= (1<<PA1); // PIN auf HIGH
ist nahezu identisch - 1bit in ein Register schreiben:
GPIOA->ODR |= (1<<PA1); // PIN auf HIGH
Antoli B. schrieb:> #include <avr/io.h>>> DDRA |= (1<<PA1); // pin als Ausgang> PORTA |= (1<<PA1); // PIN auf HIGH>> Wie würde das nun bei ST sein?
z.B. so:
1
#include<stm32f4xx.h>
2
GPIOA->MODER|=GPIO_MODER_MODER1_0;// Pin als Ausgang
3
GPIOA->BSRRL=GPIO_BSRR_BS_1;// PIN auf HIGH
Die Register sind halt anders strukturiert, und es gibt auch mehr
Optionen (man könnte noch die Geschwindigkeit vom Pin einstellen, oder
den auf Open-Drain setzen und ggf. Pullups zuschalten). Und vorher muss
man den Takt vom GPIOA einschalten, sonst tut sich nix:
1
RCC->AHB1ENR|=RCC_AHB1ENR_GPIOAEN;
Antoli B. schrieb:> C ist ja eigentlich C.
Nicht so ganz... Auf AVR ist C doch recht eingeschränkt. z.B. kann es
aufgrund der Harvard-Architektur keine Funktion geben, die einen char*
entgegennimmt, welcher du sowohl Pointer auf Flash-Daten, RAM-Daten oder
EEPROM-Daten übergeben kannst. Die Funktion muss "wissen", in welchen
Bereich der Zeiger zeigt, und entsprechend zugreifen. Das ist bei den
ARM's anders, denn aus den 32bits des Pointers weiß die Hardware
automatisch, auf welchen Bereich sich der bezieht. Das kann die
Programmierung durchaus vereinfachen.
Hinzu kommt dass viele C-typischen Konstrukte auf dem ARM einfach
effizienter sind und man sie dort sorgloser nutzen kann
(Offset/Array-Indizierung und allg. Pointer-Operationen, Shifts um
variable Bit-Zahlen, Stack-Zugriffe, je nach Modell auch Arithmetik
(Division, Floating-Point)).
Ok, aber so wie ich das hier lese ist STM für mivh totaler Overkill.
Ein bisschen i2c, ein bisschen display (ea dip, also fertige) ein wenig
i/o, pwm und 1-wire. Ab und an mal 1 - 2 adc aber das war es dann auch
schon.
Da sollten die AVRs dann doch reichen. Also dafür lohnt der umstieg
glaube nicht, oder?
Antoli B. schrieb:> Ok, aber so wie ich das hier lese ist STM für mivh totaler Overkill.
Puh. Jetzt hast Du es herausgefunden. Glückwunsch!
Und glaub mir, Du bist nicht der Einzige dem ein AVR locker langt :)
Antoli B. schrieb:> Da sollten die AVRs dann doch reichen. Also dafür lohnt der umstieg> glaube nicht, oder?
sich lohnen..?
beim Basteln geht das etwas anders. Wenn die AVR's dir für deine
Projekte ausreichen und wenn du noch genug davon in der Bastelkiste
hast, dann bleibe bei denen.
Wenn du dich aber nach Nachschub umsehen mußt, dann rate ich dir eben
doch zu irgendwelchen kleineren Cortexen, davon gibt es so einiges von
eigentlich allen Herstellern im Pinzahl-Bereich 48..64, was sicherlich
ein passabler Ersatz für AVR ist.
Und was hättest du davon?
- Pointer, die tatsächlich auf alles zeigen können
- echtes double (bei AVR würde ich mich da verscheißert fühlen)
- bei Cortex M4F (das F ist wichtig) single in Hardware
- ziemlich freie Wahl bei der Arbeitsgeschwindigkeit von fast 0 bis
typisch 72 MHz oder je nach Typ über 100 MHz
- bei vielen Typen ein fest eingebauter Bootlader
- und das Übliche eben (höher, schneller, weiter... eben weitaus höhere
Rechenleistung als AVR)
Ob du das nun tatsächlich brauchst, ist ne andere Frage. Aber wenn die
AVR noch weiter im Preis steigen, wäre das ein echter Grund (wenn ich du
wäre).
W.S.
Igor schrieb:> Peter D. schrieb:>> Wenn Du keine Laufzeitprobleme hast oder besondere Peripherie brauchst,>> bringt der Umstieg auf 32Bit nichts.>> Und das ist mit effizienter Programmierung in >90% der Fälle so.
Es gibt auch im Hobbybereich Leute die mehr als ein paar einfache
Blinkerschaltungen bauen. Für ein aktuelles Projekt brauche ich z.B.
schnellen Zugriff auf eine SD Karte. Angestrebte Übertragungsrate sind
mehrere MB pro Sekunde. Bei den STM32F4 gibts da eine SDIO Peripherie
und DMA. Viel Spaß mit dem AVR da mitzuhalten.
Naja, also ich verstehe das alles was du da geschrieben hast nicht so
ganz aber mit einem AVR habe ich schon ohne Probleme eine SD Karte
ausgelesen, die Daten dann an einen VS1053b geschickt, nebenbei noch ein
eDIPTFT70-ATP bedient, eine Lichtorgel an 3 ADCs ausgelesen und die
passenden "Farben" dann auf einen 400LED langen ws2812b LED Stripe
gesendet.
Ob du es glaubst der nicht, mit 8Mhz ging es nicht aber ab 12Mhz ging es
dann und mit 16Mhz einwandfrei.
Das sollte so in etwa in deine Richtung gehen.
Das ganze soll hier aber kein AVR vs. STM shitstorm werden. Die Frage
war eben ob es sich lohnt. Die Struktur, Code etc ist alles anders, auch
wenn minimal oder auch mehr. Lohnt es sich also? Meiner Ansicht nach
Nein, denn, wenn ich für 100 Projekte 99mal einen AVR erfolgreich und zu
vll. 60/70% auslastung einsetzen kann und nur einmal einen STM benötige,
je 100 Projekte, dann lohnt sich der umstieg schlicht und ergreifend
nicht. Alles neu erlesen, lernen etc. pp. für alle 8/9/10 Monate MAL ist
einfach overkill.
Also AVR4Ever :-P
Ich sehe genau drei Gründe, die einen Wechsel rechtfertigen würden.
1.) Man braucht die Leistung: Dazu wurde bereits genug gesagt. Für
einige anspruchsvolle Projekte durchaus genial. Zugegeben freue ich mich
aber auch, wenn beispielsweise Icons für ein Grafikdisplay einfach in
den Flash passen und ich nichts extern ranfrickeln muss.
2.) Microchip könnte die AVR langsam auslaufen lassen, wodurch diese
immer teurer werden: Auch dazu gabs neulich einen ewig langen Thread.
Sollte dem so sein, kommt irgendwann der (Preis-)Punkt, an dem man sich
das überlegen kann. Bis dahin spricht ja aber nichts gegen einen AVR.
3.) Man lernt das Ganze (auch) für den Beruf: Neueinsteigern mit diesem
Hintergedanken würde ich eher nicht zu einem AVR raten: Wenig
Verbreitung, deutlich älter und mit (vielleicht) ungewisser Zukunft.
Hier sind Projekte im Entstehen, die die Leistung auch wirklich brauchen
und dafür ist ARM die Zukunft.
Wie gesagt, kleine logische schaltungen o.ä. nicht großes ausser mein
Verstärker Projekt aber swlbat da langweilt sich der ATMega128 mit 12Mhz
noch zu tode.
Steuert ein Display (eDIPTFT43, das hat ja seinen eigenen code und uC)
über i2c dann noch ein HC06 Modul über RS232 und ein PT2322 Klangregler
über i2c. Das ist mein bisher größtes Projekt. Dazu kommen noch 6/7 i/os
das wars.
Antoli B. schrieb:> ganz aber mit einem AVR habe ich schon ohne Probleme eine SD Karte> ausgelesen, die Daten dann an einen VS1053b geschickt, nebenbei noch ein> eDIPTFT70-ATP bedient
Du hast also die schwere Arbeit externe Prozessoren machen lassen (die
am Ende auch ARM's sind)... Bei Nutzung eines Cortex-M hättest du dir
das Display mit Intelligenz und den Audio-Decoder vermutlich sparen
können. Eventuell hättest du so Kosten sparen können (für Hobby-Projekte
natürlich egal). Weniger (Entwicklungs-)Aufwand wär's so aber nicht
geworden...
Ich persönlich finde es einfach sehr angenehm mit den STM32 zu arbeiten,
u.a. weil diese jede Menge leistungsfähige Timer haben und man da nicht
sparen/rumtricksen muss. Auch bei der Rechenleistung kann man aus dem
Vollen schöpfen und muss nicht jeden Pups optimieren. Wenn ich mir die
kleineren AVR mit ihren 2 Timern anschaue gruselt es mich regelmäßig ;-)
Nunja. Die Displays sind unumgänglich für mich.
1. Sie haben nen schönes Design als irgendnen selbstbau
2. Der Touch ist einfach zu bedienen da "rückgabewerte"
3. Kann ich die ausrangierten von der Arbeit für etwas Kaffeegeld
mitnehmen. Ich habe das eDIPTFT70ATP (7Zoll Touch MIT Einbaurahmen) für
2 Pfund Kaffee mitnehmen können.
WARUM dann die Arbeit machen?
Ich habe auch nirgends gesagt das ich alles auf dem uC machen möchte. ;)
Für mich, und für meinen Fall reichen die ATMegas also dicke aus. Wenn
einer meiner Megas mal an seine grenzen kam hab ich einfach 2 ATMega128
genommen und die beiden die arbeit einfach "teilen" lassen. Nicht
elegant aber funktionabel.
Für mich also kommen diese eher nicht in frage. Wenns eine Chain gibt
die mir den AVR Code auf STM übersetzt dann gerne. Aber alles neu
lernen, wie gesagt, für 1-2 stk / Jahr lohnt es einfach nicht.
Martin schrieb im Beitrag #4913637:
> 3. Aufgabe der bastler- und wechselfreundlichen DIP Gehäuse
Naja also dem muss ich wiedersprechen. Ich mag die "lang"beinigen Käfer
ja mal garnicht. TQFP32/64 :)
Antoli B. schrieb:> Die Frage war eben ob es sich lohnt.
Zusammenfassend:
(a) Du kennst AVR bereits.
(b) Du bist mit AVR zufrieden.
(c) Du willst nichts ändern.
Daher lohnt sich ein Wechsel für dich nicht. Wäre eine der Bedingungen
nicht erfüllt, wäre ein Wechsel hingegen anzuraten.
Antoli B. schrieb:> Die Frage war eben ob es sich lohnt
Ein Umstieg AVR auf STM8 würde sich nur bei Automotive Produkten lohnen.
Hier gibt es nur die uralten AT90CAN und STM8 sind DIE robusten 8-bit uC
für diesen Bereich. Und natürlich für ältere Leute die ihre C64
Assembler Kenntnisse auffrischen wollen die STM8 sind 6502 :-)
Ein Umstieg AVR auf EFM8 würde sich dagegen für jeden lohnen, auch wenn
das hier keiner lesen will :-)
Eval-Board mit J-Link Debugger und LCD für nur 30 EUR anstatt dem
überteuertem Atmel-ICE
Viel billiger bei deutlich mehr Leistung z.B. 64k Flash USB 14-bit ADC
12-bit DAC für 1 EUR
W.S. schrieb:> Und was hättest du davon?> - Pointer, die tatsächlich auf alles zeigen können> - echtes double (bei AVR würde ich mich da verscheißert fühlen)
Double auf AVR ist mit einem passenden Compiler kein Problem.
> - bei Cortex M4F (das F ist wichtig) single in Hardware> - ziemlich freie Wahl bei der Arbeitsgeschwindigkeit von fast 0 bis> typisch 72 MHz oder je nach Typ über 100 MHz> - bei vielen Typen ein fest eingebauter Bootlader> - und das Übliche eben (höher, schneller, weiter... eben weitaus höhere> Rechenleistung als AVR)
Der große Vorteil der STM (o.ä.) ist die SWD-Schnittstelle, über die
(u.a.) Debugging zur Laufzeit überhaupt erst möglich wird.
Das fehlt beim AVR völlig.
Investier' einfach mal die 10EUR für ein NUCLEO-F091RC-Board,
hol' Dir den Keil-Compiler für STM32F0 und STM32L0 (ohne Code
Einschränkung) von http://www2.keil.com/stmicroelectronics-stm32/mdk und
teste das Gespann mal ein/zwei Wochen - würde mich wundern, wenn Du
danach nochmal einen AVR nutzen möchtest ;-).
m.n. schrieb:> Double auf AVR ist mit einem passenden Compiler kein Problem.
Welcher Compiler macht das denn?
Die meisten 8 Bit-Compiler rechnen nur mit float, auch wenn man double
hinschreibt.
W.S. schrieb:> - echtes double (bei AVR würde ich mich da verscheißert fühlen)
Dazu braucht man aber erstmal ne Aufgabe, die double benötigt.
Mir fallen da jetzt nur astronomische Berechnungen ein.
Für meine PID-Regler reicht float völlig aus, die ADC/DAC sind ja eh nur
16Bit.
Und 12-stellige Frequenzmesser sind auch keine Projekte, die oft
benötigt werden.
S. R. schrieb:> m.n. schrieb:>> Double auf AVR ist mit einem passenden Compiler kein Problem.>> Welcher Compiler macht das denn?
Der Compiler von IAR kann alternativ 'float' oder 'double' rechnen. Die
Kickstarter Version ist kostenlos und zwar auf 4 K Code beschränkt,
womit man aber schon Einiges erreichen kann:
http://mino-elektronik.de/fmeter/fm_software.htm#bsp2
Verwendet man anstelle des Quarzes einen TCXO kann man auch 8-stellige
Ergebnisse mit hinreichender Genauigkeit erhalten, womit sich dann auch
dieser Einwand als erledigt betrachten läßt:
Peter D. schrieb:> Dazu braucht man aber erstmal ne Aufgabe, die double benötigt.
Und bevor sich die Stimmen lautstark melden, daß sei ja alles viel zu
langsam: eine Division von double/double braucht < 100 µs auf einem 20
MHz AVR. Um jeden Irrtum auszuschließen: am besten selber testen!
m.n. schrieb:> Verwendet man anstelle des Quarzes einen TCXO kann man auch 8-stellige> Ergebnisse mit hinreichender Genauigkeit erhalten, womit sich dann auch> dieser Einwand als erledigt betrachten läßt:
Nö.
Ich glaub nicht, daß überhaupt ein nennenswerter Anteil der MC-Bastler
einen Frequenzmesser basteln will, egal wieviel Stellen.
Früher hatten ja Funkamateure noch Bedarf an solchen Geräten, aber die
sind inzwischen am Aussterben.
Ich hab nichtmal auf Arbeit nen Frequenzmesser, die 4 Digits am Oszi
reichen mir voll aus.
Ich suche daher immer noch die Brot- und Butteranwendungen für double,
die man in der MC-Praxis öfter brauchen kann.
Peter D. schrieb:> Brot- und Butteranwendungen für double,
Minimierung von Schleppfehlern. Habe ich in drei privaten Projekten
drin, mit float sind die Fehler am Ende des Messbereiches zu groß.
Peter L. schrieb im Beitrag #4915065:
> 3. Verzicht auf bastler/wechselfreudige DIP Gehäuse
ein stm32f103-minimal-"board" mit 40pin Stiftleiste ist genauso
bastlerfreundlich wie ein AVR mit dip-gehäuse.
M. schrieb im Beitrag #4915485:
> 2. Verzicht auf bis 5V Flexibilität
Die allermeisten Pins sind 5V-tolerant. Macht nur noch einen 3V3 Regler,
der bei vielen Miniboards drauf ist.
> grundschüler schrieb:>> ein stm32f103-minimal-"board" mit 40pin Stiftleiste ist genauso> bastlerfreundlich wie ein AVR mit dip-gehäuse.>> Ok. Aber es ist (viel) größer und unhandlicher.
Ist es nicht. Du kannst das ja nicht mit einem Tiny45 vergleichen,
sondern eher mit einem ATmega32. Immerhin hat das Teil enorm viele Pins.
Außerdem ist schon das drauf, was man sonst extern bräuchte:
Reset-Taster, Boot-Jumper, Pullups, (Spannungsregler wegen 3V3, siehe
oben), Abblock-Cs...
Zudem kostet es auch noch weniger als der genannte Mega.
> Vom zusätzlichen Aufwand> mit "Board" und Stiftleiste ganz abgesehen.
Wer hält dich davon ab, das Teil nicht steckbar direkt zu verlöten, wie
jedes DIP-Case auch? Ansonsten ist das ein unfairer Vergleich, dann
musst du beim DIP ja auch einen Sockel verbauen und extra Aufwand
betreiben...
Lothar schrieb:> M. schrieb im Beitrag #4915485:>> Der AVR bietet alle genannten Vorteile>> Vielleicht nicht mehr lange wenn man sich die hier für PIC gemachte> Werbung so ansieht:
[Werbung gesnipt]
Deine Aussage ergibt keinen Sinn. Wieso sollten sich die Eigenschaften
des AVR auch nur in der geringsten Weise verändern, nur weil Microchip
noch einen PIC16 Typen auf den Markt wirft?
Axel S. schrieb:> nur weil Microchip noch einen PIC16 Typen auf den Markt wirft
Das ist doch gar keine "Werbung" sondern ein "offizieller" Artikel der
extra hier im "ehemaligen" AVR Forum gebracht wurde :-)
Seit wann ist übrigens das AVR Logo oben links auf mikrocontroller.net
verschwunden??
> Wieso sollten sich die Eigenschaften des AVR auch nur in der> geringsten Weise verändern
Ist doch offensichtlich: Wenn AVR verschwindet dann verschwinden auch
die Eigenschaften.
grundschüler schrieb:> ein stm32f103-minimal-"board" mit 40pin Stiftleiste ist genauso> bastlerfreundlich wie ein AVR mit dip-gehäuse.
ich muss mich korrigieren. Als - typischer(?) - Bastler setze ich beides
ein. Nackte dip-avr aber schon lange nicht mehr. Das Gedöns mit
Kondensatoren und Quarzen tut man sich nicht mehr an. Verwendet werden
m328-Avr-mini-boards für um die 2€ oder stm32f103-mini-boards für um die
2€.
Beide werden mit Stiftsleisten gesockelt. Beide können mit 3.3 und 5.0
Peripherie arbeiten. Einsatzmöglichkeiten und Kosten sind also direkt
vergleichbar.
Bleibt noch das Problem mit der umständlicheren Programmierung. Wesen
eines "Programms" ist ja die Vereinheitlichung von Arbeitsschritten.
Zumindest für die Grundfunktionen - Setzen von Ausgängen/Einlesen von
Eingängen - ist die Verwendung von Structuren oder Macros. Dabei bietet
es sich geradezu an, die Macros so zu wählen, dass sie für beide Typen
gleichermaßen eingesetzt werden können, z.B. pinDIRout(xPort,yPin).
Damit ist dann auch bei der Programmierung Gleichartigkeit gegeben.
Peter D. schrieb:> Ich suche daher immer noch die Brot- und Butteranwendungen für double,> die man in der MC-Praxis öfter brauchen kann.
Das ist ganz gewiß ahängig vom eigenen Berufs- oder Bastel-Feld.
Bei mir kommt sowas, wo sich Restfehler von nur 24 Bit Mantisse eben oft
genug aufhäufen und dann von den 24 Bit nur noch 20..22 übrig lassen,
alle nase lang vor. Klar, man kann skalieren und dann mit int64 rechnen
(viel Spaß bei Divisionen..), aber weitaus angenehmer als derartige
Workarounds ist es eben, gleich in double zu rechnen.
Aber da wir hier in einem Bastelforum sind: Denk mal an DDS-Berechnung
für die diversen DDS von AD. Nur so als Beispiel.
Also, es gibt schon die B+B-Anwendungen für double, auch wenn die eher
nicht in dein Interessengebiet fallen.
W.S.
W.S. schrieb:> Also, es gibt schon die B+B-Anwendungen für double, auch wenn die eher> nicht in dein Interessengebiet fallen.
Sicher, aber die würde ich nicht (mehr) in der 8 Bit-Welt suchen. Auf
einem kleinen ARM oder MSP430 ist das was anderes.
Thread beobachten
Seitenaufteilung abschalten