Arm Cortex im DIP Gehäuse

Warum nicht so etwas:
https://www.aliexpress.com/wholesale?catId=0&initiative_id=&SearchText=stm32f103c8t6+board

Cortex-M3, und viel mehr als der Controller und zwei Quarze sind da 
nicht drauf. Alles mit bastelfreundlichen 2.54mm-Raster. Die meisten 
Pins sind frei verfügbar (bis auf ...).

Generell gibt's bei der STM32-Familie viel mehr Auswahl bei solchen 
"minimum boards" als bei den LPC oder Kinetis. Warum auch immer ...

Den LPC812 gibt es noch in SO20, 20 Pins mit 1,27 mm Pitch. Ein 
einfacher Controller mit 16 kB Flash / 4 kB RAM, Bootloader im ROM und 
einfach per USB-TTL Wandler programmierbar, Debuggen per SWD möglich, 
Switch Matrix über die Funktionspins flexibel auf die GPIOs verteilt 
werden können, RC Oszi + PLL 30 MHz Takt, mehrere Modi zum Stromsparen 
uvm.
Alleine mit den 'kleinen' LPC8xx kann man schon jede Menge erschlagen. 
Jetzt wurde die Familie noch um den LPC845 erweitert, ein Sahneteil, 
allerdings wieder in LQFP48/64.

https://www.mikroe.com/mini/

dann verwende einen Teensy.
https://www.pjrc.com/teensy/

Uwe schrieb:
> Ich möchte mich an meinem Lebensabend mit den Arm-Cortex Controllern
> beschäftigen, entweder M0(+) oder M3,

Warum diese Einschränkung? Ein M4F ist auch was Nettes.

Ich hätte dir da eine ganz andere Herangehensweise vorgeschlagen, 
nämlich nach Gehäusegröße. Wenn du eher nur kleinere Dinge damit machen 
willst, dann guck nach Chips im 48 bis 64 pinnigen Gehäuse, gestalte dir 
eine Minimalst-Leiterplatte dazu, laß diese im Dutzend in China 
anfertigen und gib dir einmal die Mühe, deine Chips nebst Quarz, 
Spannungsregler und Programmieranschluß auf diese LP zu kriegen, dazu 
eine Basisversion einer Firmware, die dem Teil erstmal Leben einhaucht. 
Dann hast du eine nette Basis für all deine Betätigungen.

Vorschläge meinerseits:

STM32xxx = häufig hier beredet, Bootlader, gute Dokumentation, aber 
Peripherie zum großen Teil nur 16 bittig.

LPCxxxx  = hier seltener besprochen, gleiche Liga wie STM32, Bootlader, 
gute Dokumentation und die Peripherie ist fast durchgängig 32 bittig.

Nuvoton  = hier ziemlich ignoriert, dennoch beachtenswert. kein 
Bootlader, also JTAG/SWD, aber es gibt dort M4F auch in kleineren 
Gehäusen (M452LC3AE, 48 Pin, etwa 70 MHz) und zu friedlichen Preisen. 
Haben nen Internetshop.

Also: guck dir etwas mit Weitblick aus, habe keine Scheu vor dem Löten, 
mach dir zu allererst Moduln wie oben beschrieben, mit denen kannst du 
später bequem leben, wenn der Tatterich zunimmt.

W.S.

Danke Dir Stefan!

Du hast sehr schöne Alternativen aufgezeigt. Blue Pills Boards scheiden 
aus, denn das wäre dann nicht zu 100% mein Werk, das sieht mir zu sehr 
nach Experimentierbaukasten, Jugend forscht aus, da bin ich sehr eitel.

Aber deine weitere Poweridee mit der preiswerten Heißluftlötstation 
werde ich weiter verfolgen! Das bedeutet doch, da ist Lötpaste auf den 
Pads, die dann schmilzt, und Kurzschlüsse dürften dann selten auftreten 
mit dem Verfahren, denn man braucht auch keine ruhige Hand?

Beste Grüße,

Uwe

Danke Detlev,
die SAM D10 haben Charme! 14- und 20 polige SOICs mit 1.27 mm Pinabstand 
klingt ja recht entspannt. 16 Kb Flash max. ist zwar nicht der Brüller, 
aber meine 6 Kb AVR Code bekomme ich da locker rein!

Beste Grüße,

Uwe

Danke Johannes für deine Tipps!

Das Ding schaue ich mir an, klingt gut, denn 1.27 mm Pinabstand sind 
recht entspannt, und die Technik hört sich gut an. ich lade mir sofort 
das Datasheet runter!

Beste Grüße,
Uwe

Hey Namensvetter, Du solltest vor dem Löten keine Angst haben, das geht 
unglaublich gut, wenn man den Dreh erst mal raus hat. Für Heißluft 
brauchst Du übrigens auch eine ruhige Hand beim Platzieren des 
vielpinnigen Teils.

Schnapp Dir ein paar alte Motherboards, Festplattencontroller ö.ä. und 
löte an denen herum. Mit Heißluft (einstellbare Baumarktheißluftpistole 
reicht) ablöten und dann mit Lötkolben wieder auflöten.  Entscheidend 
ist das Flußmittel, ein guter Lötkolben und ev. bei alternden Augen eine 
Kosmetikerlupenleuchte, dann lötest Du TQFP oder TSSOP ohne größere 
Anstrengungen. Lag Dir das von einem deutlich Ü50 glaubhaft versichern. 
;-)

Hallo W.S.!

Warum nicht gleich mit der Arm-Cortex A- oder R- Serie einsteigen? :-)
Spaß beiseite, denn selbst die M0 uCs sind schon recht komplex. Die 
Zeiten wie beim AVR, wo man sich mit einem guten Rotwein dabei 
einarbeitet, sind vorbei. Aber als übernächster Schritt wäre das 
durchaus eine gute Idee. ich möchte nämlich einen Technikschock 
vermeiden.

Deine Vorgehensweise ist gut. STM scheidet bei mir aus, weil wohl Code 
im Flash mit vielen Waitstates ausgeführt wird, diese Probleme kenne ich 
nicht bei XP, (LPCs) daher für mich eine höhere Liga.Nuvoton habe ich 
nie gehört, schaue ich mir an!

ja, ich sehe schon, ran an den Lötkolben ist hier die Devise, ich werde 
Euch folgen, Ihr habt mich ermutigt! Wobei Heißluftlötkolben fasziniert 
mich....
Beste Grüße,

Uwe

Uwe schrieb:
> Das Ding schaue ich mir an, klingt gut, denn 1.27 mm Pinabstand sind
> recht entspannt

Freut mich wenn es passt, ich helfe auch gerne weiter (nein, habe nix 
mit NXP zu tun).
Ein Wermutstropfen: wenn man SO20 als Filterkriterium nimmt bleibt nix 
anderes übrig als der LPC812. Wenn man mehr möchte muss man also doch 
wieder kleiner nehmen. Paradox, liegt aber möglicherweise an einem 
Microchip Patent, so habe ich es hier jedenfalls mal als Gerücht? 
gelesen.

> ja, ich sehe schon, ran an den Lötkolben ist hier die Devise
jepp, das ist die richtige Einstellung. Habe als Bj.62 auch nicht mehr 
die ruhigste Hand, aber mit ein bisschen Übung geht das. Naja, und 
selbst 20 Jahre jüngere Kollegen trauen sich das nicht zu, also am Alter 
liegts nicht. TSSOP20 mit 0,5 mm Pitch und 0402 bekomme ich auch noch 
gut auf die Platinen.

Heissluft ist schon gut, benutze selbst oft eine billige Atten 850D. 
Nicht nur zum Löten, auch zum Teile ausschlachten oder für 
Schrumpfschlauch schrumpfen oder 3D Druckteile aus PLA gefügig zu 
machen. Aber es ist nicht der heilige Gral, auch das will geübt sein, 
das richtige Timing ist hier wichtig. Da kann man sich in YouTube Videos 
einiges abschuen, aber auch nicht alles, hatte hier auch mal ein negativ 
Beisiel gepostet. Wie es zügig und gut geht sieht man zB hier: 
https://www.youtube.com/watch?v=9Sfggumc-Tc
Bei weniger hohen Anforderungen als in der industriellen Fertigung mit 
möglichst 100%er Qualität kann man auch mal überlagerte Paste mit 
Flussmittel wieder gängig machen, das Lagerungsproblem sehe ich da nicht 
so. Und selbst bei den China Bestellungen bekommt man Paste innerhalb 1 
Woche aus EU oder GB Lager, den Fehler einen 500g Topf zu bestellen 
mache ich auch nicht nochmal.

So einen Druckluft Dispenser wie von Chris genannt (AD-982) benutze ich 
auch, man braucht allerdings einen Kompressor der so 6 Bar liefern 
sollte. Alternativ gibt es auch DIY Lösungen mit Schrittmotor und 
Spindel als Dispenser.

> Die Zeiten wie beim AVR, wo man sich mit einem guten Rotwein dabei
> einarbeitet,

Als finalen Tipp:
Life is too short for bad wine,
aber auch das Löten möglichst vor dem Rotwein trinken erledigen :-)


Gute Nacht,
Jojo

Uwe schrieb:
> Vor Jahren gab es noch in wenigen Fällen die
> bastlerromantischen DIP Gehäuse (ich meine nicht die DIP8
> Spielzeugversion), etwa beim LPC1114FN28/102, allerdings discontinued,
> auch wenn man bei Ebay noch Restbestände findet

Hi Uwe, dein Ansinnen in allen Ehren, aber so aus der Luft wird das 
sicher nichts. Wenn du selbst Hardware ätzt, dann bleibt doch nur das 
Lötproblem. Und selbst die Kleinsten Pad's kannst du noch mit 
Flussmittel und Entlötlitze sauber bearbeiten.

Uwe schrieb:
> zumal ich gelesen hatte,
> die Chinesen verlöten diese noch in Massen? Wenn ja, könnt Ihr mir
> solche Typen nennen?

...sorry, aber du suchst am falschen Ende!
Best of British Luck to you.
Gruß Rainer

> Dem Verfahren mit dicken Lötkolben und dann Entlöten mit Entlötlitze
> traue ich nicht!

Das kann ich verstehen. Das ist zwar grundsaetzlich kein Problem, aber 
soetwas setzt eine gewisse Routine vorraus. Aehnlich wie Fahrradfahren 
oder schwimmen. Man kann nicht davon ausgehen das es beim erstenmal 
klappt und als privater Kleinbastler macht man das ja nicht jeden Tag.

> Versionen, die heute noch produziert werden, zumal ich gelesen hatte,
> die Chinesen verlöten diese noch in Massen?

Ich finde es immer wieder erstaunlich was hier fuer Vorurteile 
gegenueber China bestehen. Alles was da in Stueckzahlen laeuft ist dort 
genauso professionell wie bei uns, vielleicht sogar noch professioneller 
weil die Stueckzahlen groesser sind. Oder glaubt hier einer ernsthaft 
euer neues Iphone wird von Tante Hu ueber dem Kohlenfeuer geloetet?
Und bei kleinen Buden sitzen dann viele Maedchen und loeten mit dem 
dicken Loetkolben. Aber die machen auch drei SMD-ICs pro Minute weil sie 
das jeden Tag 10h machen.

Wenn du es wirklich nicht selber loeten willst dann wuerde ich mir 
Adapterplatinen mit bereits aufgeloeteten ICs kaufen. Oder steck dir 
einfach ein ganzes Demokit von ST auf deine eigene Platine.

Allerdings wuerde ich dir empfehlen dir ein Mikroskop zu kaufen und 
etwas zu ueben. Und zwar weniger wegen dem Microcontroller. Es gibt 
heutzutage auch jede Menge interessanter neue ICs die man als Bastler 
auch verwenden will und die sind auch alle SMD. Oder willst du neben 
deinen schicken neuen ARM einen LM324 packen? Wo bleibt denn da der Sinn 
fuer Aesthetik? :-)

Olaf

Hallo Detlev!

Also mit dem SAMD10 hast du mir ja einen Wahnsinnstipp verpasst, danke 
nochmals! Kostet als Einzelstück in der 16 Kb Version knapp ein Euro, 
dafür bekomme ich keinen ATMEGA, hat sogar 12 Bit ADC on board. Auf den 
habe ich mich eingeschossen! Wenn du mir abschließend einen guten 
Programmer/Debugger dafür empfehlen kannst (taugt der Atmel ICE etwas)??

Dankbare Grüße,

Uwe

Hallo Johannes!

Der LPC81X hat leider keinen ADC..... :-(
BG

Uwe

Hallo Jojo!

Also mit dem Druckluft Dispenser erledigt sich langsam, wenn neben mir 
auch noch ein Kompressor am röhren ist! :-) Einigen wir uns auf die 
quick und dirty Methode, alle Pins miteinander zu verlöten, und dann die 
Kurzschlüsse rückgängig machen mit Entlötlitze. Dein empfohlenes Video 
lade ich mir runter! Hast du dabei eine vergrößernde Brille auf mit etwa 
5 fach?? Als Jahrgang 60er habe ich auch nicht mehr die Adleraugen wie 
früher meine Laborassistenten, die 0.5 mm Pitches sogar teilweise ohne 
Lupe eingelötet haben.

Wie schon gesagt, mit dem LPC812 hat sich erledigt, no ADC.......

Allerdings wage ich es mal, dir kräftig zu widersprechen: Mit Alkohol im 
Blut wird die Hand viel ruhiger! :-)

Beste Grüße,

Uwe

Hallo Jojo!!

Habe mir dein empfohlenes Video runtergeladen und angeschaut, sehr gut! 
Wieso der nur einen einzigen Kurzschluss gebaut hat, ist mir ein Rätsel, 
eine Hammerleistung! Ob es daran liegt, daß durch das Flussmittel das 
Lot dünnflüssiger wird und daher schneller zerläuft? Egal, ich probiere 
es aus, langsam macht mir das Thema Spaß, wenn ich hier so Eure 
Einstellungen sehe!
BG

Uwe

Hallo Olaf!

Es geht mir weniger um Ästhetik, sondern um Bastlerromantik! Ich möchte 
die SMD Technik nicht schlecht reden, schließlich ist ihr EMV Verhalten 
um Welten besser als bei bedrahteten Bauteilen. Ich habe viele Jahre EMV 
Messungen und Optimierungen gemacht, daher schätze ich schon die SMD 
Technik sehr, von den niedrigen Bestückungskosten ganz abgesehen.

Aber: An 0.5 mm Pitches zu messen, macht keinen Spaß mehr, schnell kann 
man mit der Messpitze einen Kurzschluss bauen oder man verzählt sich bei 
den vielen Pins. Auch mit einer großen Lupe zu arbeiten finde ich nicht 
so toll. Das nenne ich nicht entspannte Bastlerromatik!Ich werde daher 
den Mix aus SMD Controller und bedrahteten Bauteilen machen. Sieht 
vielleicht nicht so toll aus, will aber damit auch nicht ins 
Kunstmuseum! :-)
In diesem Sinne herzliche Grüße,

Uwe

Uwe schrieb:
> mit dem LPC812 hat sich erledigt, no ADC

Hat aber 2x 5-Bit Komparatoren. Für ein Poti reicht 5-Bit ADC und falls 
nicht kann man damit auch einen 10-Bit SAR ADC in Software bauen.

    for (n=VOLTMAX; n>0; n--)
    {
      COMPLAD_bit.LADSEL = n;
      if (COMPCTRL_bit.COMPSTAT)
      {
        d = n;
        break;
      }
    }

Hallo Uwe
verwende nach dem Umstieg vom AVR zum ARM den SAM D21. Ist etwas grösser 
als der SAM D10. Benutze ein kleines Bord mit dem IC drauf. Habe mir 
eine kleine Platine dazu gebaut. Ein kleines Problem war die 
Stromversorgung. alle Teile von mir laufen mit 5V. Diese Modul mit 3,3V, 
Dadurch kommt man ungewollt auch zu den 3,3V. Die Programmierung mache 
über ISP mit dem ICE. Bin sehr zufrieden mit dem Teil. Die 
Programmierung ist zu Anfang für mich sehr anstrengend gewesen. Jetzt 
geht es langsam. Es soll auch einen SAM C20 mit 5V geben, habe ihn auf 
keiner Platine gesehen.
LG Berti

> Versionen, die heute noch produziert werden, zumal ich gelesen hatte,
> die Chinesen verlöten diese noch in Massen?

Ich mache SMD natuerlich beruflich, aber privat genauso. Und zwar weil 
es besser ist. Ueberleg mal wie einfach und schnell du fette Schaltungen 
auf Lochraster werfen kannst. (Loecher in der Mitte teilen) Oder das man 
Platinen nicht mehr bohren muss. Keine Draehte abschneiden.

Und richtig, die Teile kosten nichts. Und nehmen auch kein Platz weg. Du 
kannst in 0603er praktisch alles zuhause rumliegen haben.

Klar, man muss einmal 20-30Euro fuer ein Mikroskop ausgeben. (Bresser 
Junior) Aber das lohnt sich.

Und zum messen lötest du einfach einen Draht an. Das ist auch kein 
Problem.

Und für viele moderne Bauteile einfach unverzichtbar. (z.B Schaltregler)

Olaf

Uwe schrieb:
> Wie schon gesagt, mit dem LPC812 hat sich erledigt, no ADC.......

ADC haben die LPC82x oder der 845, aber da sind wir wieder bei 0,5 mm 
Pitch oder LQFP.
Wobei ich eher an der Technik feilen würde sowas doch löten zu können, 
SMD machen wirklich Freude und die Auswahl an Kandidaten wird um einiges 
grösser wenn man 0,5 oder 0,65 mm noch einbezieht.
Ich habe noch eine Lupenleuchte von Pollin, nicht das Optimum und ein 
Stereomikroskop steht schon auf der Wunschliste, aber im Moment sind die 
Prioritäten anders gesetzt.
Flussmittel wie FL-22 (Gel) oder FL-88 (flüssig) erleichtert das Ganze 
jedenfalls deutlich.
Für SMD habe ich mir dieses Set gegönnt, da sind feine Spitzen drin und 
die sind sehr hilfreich : 
https://www.reichelt.de/Pruefmittel-Sets/PMS-0-64/3/index.html?ACTION=3&LA=2&ARTICLE=63480&GROUPID=5619&artnr=PMS+0%2C64&SEARCH=%252A
Alternativ könnte man sich die aus Pogo Pins bauen, gibts beim Chinesen 
sehr günstig.

Johannes S. schrieb:
> ADC haben die LPC82x oder der 845

Hier ist es aber wieder so, wenn es hauptsächlich um ADC/DAC geht: Der 
LPC845 hat 12-bit ADC und 2x 10-bit DAC bei 30 MHz und kostet 2 EUR im 
LQFP-48. Ein EFM8LB mit 14-bit ADC und 4x 12-bit DAC und 72 MHz kostet 
1.50 EUR im QFP-32 was wesentlich einfacher zu löten ist. Das ist zwar 
ein 8051 aber langsamer als der M0+ ist der nicht. Hat zudem DMA

Jörg W. schrieb:
> Könntest du mal bitte dein ewiges Evangelisieren belassen?

Ich habe doch selber LPC im Einsatz und dem Frager geschrieben dass er 
zwar recht hat:

Uwe schrieb:
> Der LPC81X hat leider keinen ADC

Es aber trotzdem geht und er sich den also mal ansehen kann:

Lothar schrieb:
> Hat aber 2x 5-Bit Komparatoren

Hallo Uwe, da immer mal wieder ein Mikroskop als Arbeitshilfe genannt 
wird, will ich mal ergänzen. Es gab - gibt? - bei Pollin sehr preiswerte 
USB-Mikroskope. Da hast du ein gestochenes Bild von deinen Bauteilen auf 
Bildschirmgröße vor dir. Mit einem Stativ kannst du dann sogar dabei 
löten. Ist natürlich etwas gewöhnungsbedürftig, aber seit ich das Ding 
habe, brauche ich keine Lupe oder Lupenleuchte mehr. Gruß Rainer

Danke für diesen hervorragenden Tipp Rainer!!! Löten unter einem 28" 
"Mikroskop" ist fast schon dekadent, aber Klasse!!! :-) Da fällt mior 
doch glatt ein, ich habe so ein Bresser Mikroskop mit elektronischem 
Okular (Webcam) im Keller liegen......
BG

Uwe

guest...Rainer schrieb:
> Hallo Uwe, da immer mal wieder ein Mikroskop als Arbeitshilfe
> genannt
> wird, will ich mal ergänzen. Es gab - gibt? - bei Pollin sehr preiswerte
> USB-Mikroskope. Da hast du ein gestochenes Bild von deinen Bauteilen auf
> Bildschirmgröße vor dir. Mit einem Stativ kannst du dann sogar dabei
> löten. Ist natürlich etwas gewöhnungsbedürftig, aber seit ich das Ding
> habe, brauche ich keine Lupe oder Lupenleuchte mehr. Gruß Rainer

Hi Rainer,


Damit kannst du arbeiten? Ich habe die gleiche Idee gehabt und muss 
sagen, dass das für mich überhaupt nicht funktioniert hat. Die 
USB-Geräte haben nämlich eine Latenzzeit. Man bewegt die Hand und es 
dauert eine Weile bis sich das auf das Bild überträgt. Für 
feinmotorische Arbeiten sehr störend.

Ich kann also aus persönlicher Erfahrung nur von USB-Mikroskopen zum 
Löten abraten.

Ich habe mir dann ein günstiges Stereomikroskop gekauft. Das 
funktioniert super.

Uwe schrieb:
> Warum nicht gleich mit der Arm-Cortex A- oder R- Serie einsteigen? :-)

Übertreib nicht.

So, zu der Komplexität: Die ist aus unserer Sicht eigentlich nicht in 
der CPU  angesiedelt, sondern in der Peripherie. Da nehmen sich M0, M3 
und M4 und M4F fast garnix.

Was die STM32 betrifft, so soll man die nicht in Bausch und Bogen 
verdammen, denn gerade bei den "besseren" Typen erfolgt der Flashzugriff 
nicht 16 bittig, sondern m.W. bis zu 64 bittig. Da relativieren sich die 
Waitstates, weil sie sich auf mehrere Befehle verteilen.

Die zumeist nur 16 bittige Peripherie ist hingegen oftmals ein viel 
größeres Ärgernis. Nach 32 Bit breiten Timern muß man wirklich suchen 
und wenn du dir mal die Kapitel über SAI, I2S und SPI anschaust, dann 
kommt dir das Grausen über das Gehampel, das man machen muß, um 32 Bit 
Daten über die 61 Bit Peripherie zu schleusen. Das Gleiche gilt für den 
USB, aber da bin ich durch, meinen USB VCP kannst du hier im Forum 
finden.

Gut ist, daß man gerade den STM32F103C8T6, der auf den Bluepill-LP 
drauf ist, beim freundlichen Chinesen spottbillig findet. Ich hab davon 
schon mehrere Dutzend für je etwa 1.10€ gekauft. Ein Problem ist der 
Versand, denn diese chinesischen Nachbauten haben recht dünne Beinchen 
und sie werden zumeist quasi lose versendet. Da ist vorsichtiges 
Geraderichten angesagt.

Aber we gesagt, für's Pensionärsdasein rate ich dir eher zu einem M4F, 
eigener LP und dazu einem mittelkleinen Monochrom-Grafikdisplay, so etwa 
128x64, dazu wenige Tasten und ein Drehgeber sowie nen seriellen und nen 
USB Anschluß - weil man ja in aller Regel auch ein bissel Hände und Füße 
an seinem Spielzeug braucht.


Was das Löten betrifft, so kann ich dir von all dem Heißluft-Gerede 
erstmal nur abraten. Mach es mit nem Lötkolben und nicht zu feiner 
Spitze. Sie sollte meißelförmig sein und nicht spitz wie ein Florett. 
Dazu ausreichend viel Kolophonium. Ich hatte neulich schon mal jemandem 
ne Art Checkliste geschrieben, wie es mit dem Löten geht. War damals 
wegen FPC-Steckverbinder im RM0.5.

W.S.

Bülent C. schrieb:
> Google mal nach s64dil reusch

Erledigt, danke für den Tipp!
http://reusch-elektronik.reworld.eu/de/produkte/s64dil-476/right.htm

Das ist ja ein überaus nettes Teil, nur leider ziemlich chaotisch 
beschrieben (der verlinkte Schaltplan ist für ein anderes Modul (F476 
vs. L476). Man kann den DFU-Bootloader angeblich löschen? Ist VDD = VCC 
= 3.3V?).

Hallo Berti!

Dein SAMD21 bietet zwar keine komfortablen 1.27 mm Pinabstände, die man 
noch mit einer Flasche Bier in der Hand löten kann, sondern bestenfalls 
als 32 Pinner 0.8 mm Anstand, was aber immerhin deutlich besser ist als 
0.5 mm. Ich habe mir ein Datasheet von dem interessanten Ding mal 
gespeichert, denn sollten 16 Kb Flash nicht ausreichen, wäre dein Typ 
eine logische Fortsetzung, daher danke für die Empfehlung!

W.S. schrieb:
> Ich hatte neulich schon mal jemandem
> ne Art Checkliste geschrieben, wie es mit dem Löten geht. War damals
> wegen FPC-Steckverbinder im RM0.5.

das war für mich in dem Thread den ich hier eröffnet hatte:
Beitrag "FPC Verbinder mit 0,5 mm Pitch löten"

Aber der FPC Connector ist wegen der Pinform sehr schwer zu löten, kein 
Vergleich mit den 0,5 mm IC Beinchen, also davon nicht beunruhigen 
lassen.

Pegge schrieb:
> Hi Rainer,
>
> Damit kannst du arbeiten?

Hallo, ja und doppelt ja. Bei meinem Teil, dass wir seinerzeit auch in 
der Firma im Prüffeld eingeführt haben, ist keine Verzögerung 
festzustellen! Und du kannst das Bild jederzeit speichern und hast damit 
auch schlechte Lötstellen u.ä. bequem dokumentiert. Ich sage ja, dass 
mit einem "gebastelten" Halter und ein wenig Übung das Löten auch bei 
0.5Pitch ein Spaziergang ist.
Gruß Rainer

Uwe schrieb:
> Ich möchte mich an meinem Lebensabend mit den Arm-Cortex Controllern
> beschäftigen, entweder M0(+) oder M3

Schön. Aber ohne konkrete Anwendung, die diese Controller wirklich 
erfordert? Ich wüsste ohnehin gerne mal, wieviele solcher Fragensteller 
es tatsächlich bis zur Beherrschung und dem produktiven Einsatz solcher 
Powercontroller bringen. Ich vermute, es ist ein verschwindender 
Bruchteil.

Rudolph schrieb:
> Uwe schrieb:
>> Ich möchte mich an meinem Lebensabend mit den Arm-Cortex Controllern
>> beschäftigen, entweder M0(+) oder M3
>
> Schön. Aber ohne konkrete Anwendung, die diese Controller wirklich
> erfordert? Ich wüsste ohnehin gerne mal, wieviele solcher Fragensteller
> es tatsächlich bis zur Beherrschung und dem produktiven Einsatz solcher
> Powercontroller bringen. Ich vermute, es ist ein verschwindender
> Bruchteil.

Wenn man die in c programmiert, geht das an einem Nachmittag.

Guten Abend Rudolph!

Es gibt schon eine sehr konkrete Anwendung, mit der ich mich seit 
Monaten beschäftige, das Gegenstromladen von Ernst Beer, erfunden 1954. 
Eine geniale Erfindung, leider weitgehend in Vergessenheit geraten. Ich 
wende sie seit etwa 15 Jahren an zum Laden von Akkus, die es mir mit 
einer langen Lebensdauer bisher gedankt haben trotz so mancher 
Überladung bei NiMh und Pb. Bis vor wenigen Monaten habe ich die Ströme 
durch Halogenlampen begrenzt, was eine einfache Methode ist. Da ich 
ziemlich viel Zeit habe, dachte ich mir, das automatisiere ich mal mit 
einem schnellen AVR ATMega, der mit 18.432 MHz gehetzt wird. Dennoch 
brauchte dieser beim Durchrechnen einer Entladeformel mit 4 
Multiplikationen und einer Division bei 32 Bit Operationen anfangs 200 
us. Wenn als Ergebnis nach 200 us herauskommt, nach 100 us hätte der 
Entladestrom schon abgeschaltet werden müssen, dann hat man schon 
verloren. Zwar konnte ich durch einige Optimierungen des Algorithmuses 
zu Lasten der Lesbarkeit des Codes die Rechenzeit auf 110 us verringern, 
dennoch stehe ich bei kleinen Ladeströmen, die ich momentan vermeide, am 
Anschlag. Natürlich wird eine CPU mit 32 Bit ALUs solche 32 Bit 
Operationen mindestens um den Faktor 10 schneller rechnen. Kurzum, bei 
32 Bit Operationen brechen die Achtbiter brutal ein, da lohnt sich 
durchaus so eine Kanone.

Es gibt aber auch noch einen zweiten Grund: Wenn mittlerweile so ein 32 
Bit Geschoss preiswerter ist als 8 und 16 Bit Technik, und bietet genug 
Reserven, dann sollte man die Flotte auf 32 Bit ARMs umstellen, eine 
Tendenz, die ich seit paar Jahren beobachte. Oder würdest du beim 
Autokauf eine 75 PS Maschine nehmen, wenn man dir 250 PS billiger 
anbietet?
Gruß

Uwe

Hallo Pegge!

Also wenn die Datasheets der einfachen ARM-Cortex uCs schon 900 Seiten 
umfassen, die AVRs etwa nur ein drittel, dann wird man so ein komplexes 
Ding nicht an einem Nachmittag in C hardwarenah programmieren! Dafür 
bietet es zu viele Möglichkeiten. Auch wird man Schwachpunkte entdecken 
in der Hardware, die aufhalten. So war es beim AVR, wenn man versucht, 
mit den angegebenen 1.1 V Referenzspannung genaue ADC Ergebnisse zu 
erhalten. Da vergehen schon einige Nachmittage inklusive 
Hardwareänderung.
Gruß

Uwe

Hallo Uwe, nachdem Du eine plausible, rechenintensive Anwendung genannt 
hast will ich Dich mal ausdrücklich aus meiner pessimistischen 
Einschätzung ausnehmen. Denn

Pegge schrieb:
> an einem Nachmittag

ist es mit der Einarbeitung in Entwicklungsumgebung, Architektur und 
Bibliotheken gewiss nicht getan, daß verlangt schon nach einer (solchen) 
guten Begründung.

Uwe schrieb:
> Also wenn die Datasheets der einfachen ARM-Cortex uCs schon 900 Seiten
> umfassen, die AVRs etwa nur ein drittel, dann wird man so ein komplexes
> Ding nicht an einem Nachmittag in C hardwarenah programmieren!

Du kannst aber doch nur die Peripherie ansehen, die Du wirklich 
programmieren willst. Also wenn Du z.B. beim LPC einen Timer brauchst, 
dann schaust Du Dir die Beschreibung vom MRT Timer an. Der ist einfacher 
als jeder AVR Timer. Und wenn Du State-Machine Sachen machen willst, 
siehst Du Dir den SCT Timer an. Der ist so kompliziert, dass es dazu 
sogar ein zusätzliches Manual gibt:

https://community.arm.com/iot/embedded/f/discussions/3723/what-s-the-big-deal-in-nxp-s-sctimer

> Also wenn die Datasheets der einfachen ARM-Cortex uCs schon 900 Seiten
> umfassen, die AVRs etwa nur ein drittel, dann wird man so ein komplexes
> Ding nicht an einem Nachmittag in C hardwarenah programmieren!

Ja und nein.

Alle Microcontroller werden ja heute in C programmiert. Es ist daher 
vollkommen egal ob man einen dummen kleinen AVR oder was richtiges wie 
einen SH2 oder grossen ARM programmiert. Man merkt es schlicht nicht.

Die Datenblaetter haben deshalb soviele Seiten weil in den grossen 
Microcontrollern auch sehr viel mehr Peripherie drin ist. Aber du musst 
ja nur das lesen was du gerade nutzt. Und wenn man beim kleinen AVR nur 
die RS232 genutzt haette dann nutzt du beim fetten Teil eben auch nur 
die RS232. Es kann Unterschiede geben, aber die liegen dann eher am 
Hersteller und wie er die Peripherie gestaltet. (z.B ist I2C beim 
STM32F103 eine Katastrophe)

In der Praxis kann es trotzdem komplizierter werden. Dafuer gibt es aber 
zwei andere Gruende.

1. Die Entwicklungsumgebung. Da ist ja heute in der Regel Eclipse oder 
eine Abart davon ueblich. Das ist ein hoellenkomplexes vollkommen 
unlogisch zusammengeschustertes Etwas. Damit kann man viel Spass im 
negativen Sinne haben.

2. Die Faulheit der Nutzer. Die meisten Anfaenger sind heute zu faul 
oder zu bloed etwas lernen zu wollen. Es ist ueblich geworden sich 
Source aus dem Internet zusammenzustehlen. Am Ende hat man dann ein 
untotes Gebastel wo keiner mehr genau weiss was darin passiert. Das gab 
es so bei kleinen Controllern mit 8kFlash und 128Byte Ram nicht. Einfach 
weil nicht genug Platz war um die ganzen Fehler einzubauen.  :-)

Dafuer haben fette Controller aber auch Vorteile. Du hast genug Platz um 
vernuenftig zu programmieren. Du hast immer noch eine serielle uebrig um 
dort Fehlerzustaende auszugeben. Es gibt sehr leistungsfaehiger 
Debugger. Man muss das nur nutzen. Dann machen solche Controller viel 
mehr Spass. Ich wuerde privat jedenfalls auch immer einen fetten 
Controller verwenden. Was interessiert mich ob der 2Euro mehr kostet? 
Ich wuerde sogar einen moeglichst fetten nehmen und denn dann fuer alle 
privaten Projekte verwenden damit man nicht immer unterschiedliche Typen 
fuer Projekte mit der Stueckzahl 1 hat. .-)

Und noch was. USB-Mikroskope sind im Prueffeld okay, aber zum loeten 
sind sie unbrauchbar. Weil sie nicht Stereo sind. Ohne 3D-Sehen kann man 
seine Haende nur so ungefaehr positionieren. Wie soll das klappen wenn 
man etwas tut was sowieso bereits an der Grenze der menschlichen 
Faehigkeiten liegt? Ich hab gerade einen defekten Cortex M4 im DFN64 
Gehaeuse mit 0,5er Pitch auf einer beidseitig voll bestueckten Platine 
gewechselt. Das will ich mal sehen wie ihr das mit USB-Mikroskop macht.

Olaf

Uwe schrieb:
> Es gibt schon eine sehr konkrete Anwendung, mit der ich mich seit
> Monaten beschäftige,

Dann nimm doch einfach ein Discovery-Board, mit dem Du ohne große 
Löterei gleich loslegen kannst. Danach kannst Du besser beurteilen, was 
Du tatsächlich brauchst.

> Oder würdest du beim
> Autokauf eine 75 PS Maschine nehmen, wenn man dir 250 PS billiger
> anbietet?

Das ist kein Argument! Ich gehe davon aus, daß der stärkere Motor einen 
höheren Verbrauch hat - insbesondere, wenn man im Stau steht. Für den 
Gang zum Bäcker reicht auch ein Fahrrad.

Uwe schrieb:
> Es gibt schon eine sehr konkrete Anwendung (...) mit einem schnellen
> AVR ATMega, der mit 18.432 MHz gehetzt wird. Dennoch brauchte dieser
> beim Durchrechnen einer Entladeformel mit 4 Multiplikationen und
> einer Division bei 32 Bit Operationen anfangs 200 us.

Das ist sogar ein Argument für einen M3 oder M4. Die M0 können nämlich 
nicht dividieren! Jedenfalls nicht in Hardware. Wer designed so kranke 
Chips?

Uwe schrieb:
> Alle Microcontroller werden ja heute in C programmiert. Es ist daher
> vollkommen egal ob man einen dummen kleinen AVR oder was richtiges wie
> einen SH2 oder grossen ARM programmiert. Man merkt es schlicht nicht.

Ist das jetzt gut oder schlecht? Ich bin froh, dass ich es an einer 
fehlenden library gemerkt habe. Die braucht der GCC für eine Division 
auf dem M0. Die gehört nicht zur Grundausstattung und für 25000 Zeilen C 
für den M3 hatte mir diese library nicht gefehlt.

Jörg W. schrieb:
> CM0/CM0+ sind auf minimale Chipfläche designt

Die Historie war doch in etwa so: man wollte einen ARM7 Nachfolger bei 
dem Exceptions komplett in C programmiert werden können. Dafür hat man 
Register-Banking durch Auto-Stacking ersetzt und raus kam der CM3. 
Hinterher hat man dann gemerkt, dass dadurch Latenzen auftreten, keine 
Rekursion mehr möglich ist, und bei Stacküberlauf Hardfault. Daher 
musste man für sicherheitskritische Anwendungen die Cortex-R Serie 
nachschieben.

Dann wollte man einen billigen CM3 machen. Anstatt aber einzelne 
Funktionen wegzulassen, wurde eine ältere Thumb-Version genommen. Folge: 
C-Code vom CM3 läuft oft auch neu kompiliert nicht auf dem M0 z.B. 
Alignment Hardfault. Und Assembler-Code vom CM0 läuft trotz 
"Aufwärtskompatibilität" nicht auf dem CM3 z.B. MOVS / MOV

> Division ist die kostspieligste der Grundrechenarten, daher hat man
> diese dort weggelassen

Beim Hardware-Multiplier hatte man sich zunächst auch einen 
Preisunterschied vorgestellt. Daraus wurde aber nichts.

Fast : This allows the MULS instruction to execute in a single cycle
Small : An iterative multiplier that takes 32 cycles to execute a MULS 
instruction.

A. K. schrieb:
> Andererseits ist der Chipaufwand für eine kombinatorische Multiplikation
> recht hoch

Jetzt haben sich unsere Posts überschnitten - komplett zeitgleich :-)

Wie geschrieben will aber Stand heute niemand mehr bezahlen für den 
Fast. Alle NXP CM0 haben daher Fast.

Also Mein Umstieg von kleinen 16-Bit Controllern auf dicke mit 32 Bit 
war mit erheblichen Kopfschmerzen verbunden. Bei mir waren es zwar 
PIC32, aber der Unterschied zu ARM ist jetzt nicht so gewaltig.

Freu dich auf all die wunderschönen Begleiterscheinungen großer 
Microcontroller, zum Beispiel:
- Kryptische Dinge wie Cache-Settings und Flash-waitstates *1)
- Eine wunderschöne Oszillatorkonfiguration, mit der man viele Stunden 
totschlagen kann (Für Bonuspunkte: I2S + USB mit einem Quarz umsetzen 
;-))
- Knackige Logikrätsel beim Debuggen von DMA dank Adressvirtualisierung
- Dicke Manuals
Viele schöne Dinge :-)

*1) Bonus1: Im Handbuch nur unzureichend beschrieben...
Bonus2: Falsche Einstellungen führen zum ausgiebigen Testen des 
Exception handlers.

Die Alternative zu den Kopfschmerzen ist, eine Art HAL (wie Cube-MX oder 
HARMONY) zu verwenden. Problem: Wenn DA mal ein Fehler drin ist, findet 
man gar nix mehr, schon weil man die Hintegründe nicht mehr versteht.
Und ja, da sind welche drin ;-)

Ich bin inzwischen auf den 32Bittern hängengeblieben. Weil jetzt kenn 
ich den Quark ja. Aber Umsteigen "weil es zeitgemäß ist" würde ich 
nicht!
Das tut man nur, wenn man dsa auch wirklcih Sinn macht.

> Haben die kleinen Cortexe nicht

Zaehlt sowieso nicht. Wer sich darueber beschwert das fette 
Microcontroller komplizierte DMA haben der kann ja einfach DMA nicht 
verwenden und die Seiten im Datenblatt nicht lesen.

Zu den Dingen die ich gelten lassen wuerde gehoert in der Tat die etwas 
aufwendigere Clockaufbereitung moderner Controller und vor allem das 
Peripherie erst laeuft wenn man ihr den Clock einschaltet. Oder die 
Ueberraschung wenn man sieht das selbst Port einen Clock haben der 
asyncron zum Mainclock laeuft und schweinelangsam ist im Vergleich zum 
Core.

Aber dafuer laeuft dann eben auch ein fetter Controller ein Jahr aus 
einer kleinen Knopfzelle wenn man alles richtig macht.

Olaf

A. K. schrieb:
> Hinsichtlich Stack-Überlauf besteht der Unterschied dann nur darin, dass
> die CMx Interrupts auf dem System-Stack arbeiten, die beiden CRx
> Interrupts hingegen eigenen Stacks besitzen

Dafür muss der System-Stackpointer initialisiert werden. Dennoch kann es 
dann durch das Autostacking by Exceptions zum Stacküberlauf kommen. Auch 
im NMI-Handler kann das nicht behoben werden, der braucht auch Stack. 
Der FIQ-Handler braucht erst mal keinen Stack, da eigene Registerbank ab 
R8

Alles würde ohne Probleme funktionieren, hätte man für jeden Mode 
einfach eine komplette Registerbank gemacht, wie beim 8051. Die 
Notlösung ist ja Dual-Core CM4/CM0 wie im LPC54 um "echt parallel" zu 
werden.

> Der CM3 hingegen arbeitet ausschliesslich im Thumb2-Befehlssatz und
> dessen Exception-System ist von Haus aus reentrant

Es ist dadurch nicht echtzeitfähig:

https://books.google.de/books?id=9YxqAAAAQBAJ&pg=SL5-PA198&lpg=SL5-PA198&dq=cortex-m+recursive+interrupt&source=bl&ots=Ub31N8dyfy&sig=owT9d-BewFO2JGzQxp0ae9CWFyw&hl=de&sa=X&ved=0ahUKEwjvi-L1tMPXAhVFXhoKHTehCycQ6AEIRjAD#v=onepage&q=cortex-m%20recursive%20interrupt&f=false

Die Argumentation, dass ARM Controller für Anfänger schwieriger 
anzuwenden sind, als 8bit Mikrocontroller ist korrekt. Aber nicht jeder 
empfindet das als Hindernis.

Immerhin benutzen viele von uns auch den ATmega328P lieber, als den 
ATmega8. Auch dort gibt es erhebliche Unterschiede im Umfang der 
Datenblätter.

Beim Hobby ist doch oft der Weg das Ziel. Ich erforsche einen Chip, und 
freue mich dann, dann ich ihn für etwas nützliches benutzen kann. Ob das 
nun die technische optimale oder preisliche günstigste Lösung ist, 
spielt im Hobby meistens nur eine untergeordnete Rolle.

> Alles würde ohne Probleme funktionieren, hätte man für jeden Mode
> einfach eine komplette Registerbank gemacht, wie beim 8051.

Oder Renesas SH2A. Da gibt es dann acht Registerbaenke und es flutscht 
nur so in den IRQ.

Olaf

Hallo Bülent!

Ich finde den thematischen Verlauf der Kommentare hervorragend. Und daß 
Einwände in Sachen Rechenzeit entstanden, habe ich verursacht, als ich 
von dem erheblichen Rechenaufwand des ATMegas 88 sprach. Daß die 
technisch sehr versierten Jungs mich warnten vor der M0 Division, war 
eine logische Konsequenz, schon eine Notwendigkeit, danke Jungs!!! Werde 
mich nun daher mal mit Rechenzeiten des M0 fit machen, und dann mal 
schauen, ob es bei dem M3s auch Gehäuseformen mit 1.27 mm oder 0.8 mm 
Pitches gibt.
Gruß

Uwe

A.K. schrieb
>Es gibt aber keinen ARM ohne Barrel Shifter. Der war von vorneherein aus
>der Implementierung der ARM Architekturen nicht wegzudenken.

Und der hat schon beim ARM1 ziemlich viel Chip-Fläche verbraucht.
von
http://www.righto.com/2015/12/reverse-engineering-arm1-ancestor-of.html

Es hat mich erstaunt, dass der Barrelshifter so wichtig ist, dass man so 
viel Fläche dafür spendiert.

Der Befehlssatz wurde von Sophie Wilson entwickelt
https://www.youtube.com/watch?v=re5xAqgKqc0
womit sie wahrscheinlich zu den einflussreichsten Frauen der Computerära 
gehören dürfte.

Uwe schrieb:
> Werde
> mich nun daher mal mit Rechenzeiten des M0 fit machen, und dann mal
> schauen, ob es bei dem M3s auch Gehäuseformen mit 1.27 mm oder 0.8 mm
> Pitches gibt.

Beides ist nicht zielführend. Wenn du viel rechnen willst, dann greife 
zum M4F und rechne in Gleitkomma. Wenn du es dort dann passend 
formulierst, benutzt der Compiler dabei auch die DSP-Befehle. Das ist 
durchaus schnell.

Und das Zweite ist, daß es zwar bei Freescale (soweit ich weiß in der 
MKE-Serie) Chips im etwas gröberen Raster als 0.5 gibt (mag sein 0.65 
oder 0.8, hab's nicht auswendig gelernt), aber das sind dann eben wieder 
M0 oder M0+ und weder M3 noch M4 und schon gar nicht M4F. Obendrein kann 
ich die Freescale-Chips nicht wirklich empfehlen.

W.S.

A. K. schrieb:
> Demgegenüber empfinde ich es als Kardinalfehler des ursprünglichen ARM
> Designs, dass der PC des unterbrochenen Kontextes im LR des
> Interrupt-Kontextes gesichert wird

Aber nur so kann doch die ISR mit MOV PC, LR beendet werden ???

Sonst bräuchte man doch wieder einen Stack für LDMIA SP!, {PC}

Hallo W.S.!
.
Stimmt der M4 hat ja schon DSP Funktionalitäten, da könnte man sich ja 
auch gleich in Fourier Analyse austoben. :-) Deine gesunden Ansichten 
und Technikbegeisterung in allen Ehren, aber mir kommt die Situation 
vor, als wenn man einem Fahrschüler, der gerade auf einem Golf die 
Führerscheinprüfung bestanden hat, einen 40 Tonner hinstellt nach dem 
Motto, damit kannste nicht nur zum Discounter fahren, sondern auch 
gleich deine Umzüge mit machen..... Ich möchte keinen brutalen Umstieg 
machen, sondern schrittweise die ARM-Cortexe kennenlernen in entspannter 
Atmosphäre! Der M4 wird bestimmt mal bei mir an der Reihe sein, aber 
nicht sofort, will ja meinen Lebensabend nicht verfluchen!
Beste Grüße,

U.H.

A. K. schrieb:
> Olaf schrieb:
>> Oder Renesas SH2A. Da gibt es dann acht Registerbaenke und es flutscht
>> nur so in den IRQ.
>
> Gibts die auch in DIP? Zumindest so wie in obigen Modulen.

Wohl kaum, denn die SH2A sind Edelprozessoren und in Bastelkreisen eher 
nicht anzutreffen.
Es sind übrigens 16 Registerbänke - für jede Priorität eine eigene Bank. 
Und falls diese schon belegt ist, werden die Register automatisch auf 
den Stack gelegt.
Ich hatte es beim SH7211 mal gemessen: rund 60 ns Reaktionszeit inkl. 
retten aller Register (16 x 32 Bit allgemeine + weitere 
Control-Register) nach Auslösen des IRQ. Der SH7211 war mit der erste µC 
der SH2A Reihe mit max. zwei Instruktionen/Takt bei 160 MHz. Ein 
Nachfolger war der SH7216, der mit 200 MHz neben 32 Bit (float) auch 64 
Bit (double) direkt unterstützt.

Richtig edle Teile, kennt hier allerdings kein Schwein ;-)

W.S. schrieb:
> Beides ist nicht zielführend. Wenn du viel rechnen willst, dann greife
> zum M4F und rechne in Gleitkomma. Wenn du es dort dann passend
> formulierst, benutzt der Compiler dabei auch die DSP-Befehle. Das ist
> durchaus schnell.

Wobei ein M4F jetzt auch nicht die FPU Performance hat und der Preis in 
der Nähe eines Pi Zero liegt das wieder auf Steckbrett kann. Und der 
ARM11 mit NEON FPU hat eine ganz andere Rechenleistung. Und ARM11 Bare 
Metal ist auch nicht komplizierter als M4F wenn eine HAL genutzt wird.

Beitrag "Re: Raspberry Pi als "dicker" Mikrocontroller"

> Auch bei einem XMEGA musst du erheblich umdenken,
> wenn du zuvor den ATMega hattest, die Peripherie ist total anders.

Allerdings, und das hat mich sehr überrascht da Atmel diese Serie auch 
als AVR bezeichnet hatte.

Uwe schrieb im Beitrag #5212700:
> Mir hat es Ende der 80er richtig Spaß gemacht, den
> 68000 in Assembler zu programmieren

Da gab es aber schon den 16/32-bit ARM2 und der war als Derivat des 
8-bit 6502 wesentlich einfacher in Assembler zu programmieren. Leider 
ist der ARM-Erfinder Acorn vor Commodore Pleite gegangen. Trotzdem: wo 
ist heute das 68000 Zeug wie 68HC, Coldfire und PowerPC? Und wo ist ARM?

https://en.wikipedia.org/wiki/Acorn_Archimedes

> Da mach Dir mal keine Sorgen. Kommen doch laufend neue "X"Tinys heraus
> :)
+1
Die technische Seite der AVR ist sicherlich ok, aber das Microchip 
Marketing scheint das Aschenputtel nicht zu mögen, so sieht es 
jedenfalls für mich aus wenn ich die viele Werbung sehe für 
ausschließlich Pics.

>Da gab es aber schon den 16/32-bit ARM2 und der war als Derivat des
>8-bit 6502 wesentlich einfacher in Assembler zu programmieren. Leider
>ist der ARM-Erfinder Acorn vor Commodore Pleite gegangen. Trotzdem: wo
>ist heute das 68000 Zeug wie 68HC, Coldfire und PowerPC? Und wo ist ARM?

PowerPc wird noch millionenfach in der Automobilindustrie verbaut:
https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/mpc5xxx-55xx-32-bit-mcus:POWER_ARCH_5XXX

Coldfire ist die Weiterentwicklung des 68000 :
https://en.wikipedia.org/wiki/NXP_ColdFire
Wo der noch verwendet wird, weiß ich nicht.

> Wohl kaum, denn die SH2A sind Edelprozessoren und in Bastelkreisen eher
> nicht anzutreffen.

Bei mir laeuft er seit Jahren als MP3-Player. :)

> Es sind übrigens 16 Registerbänke - für jede Priorität eine eigene Bank.

Stimmt, hab mich da vertan.

> Richtig edle Teile, kennt hier allerdings kein Schwein ;-)

Schnuckelig ist auch das echte Dualportram. Und überhaubt die interne 
RAM-Groesse.

Die Bastlerschweine mögen die aber natuerlich nicht weil es die sicher 
nicht in DIL gibt. Ausserdem hat das Datenblatt auch 2000Seiten. Aber 
immerhin sind die nicht in BGA. Und sie werden problemlos vom Gcc 
unterstuetzt.

Problem bei den Teilen ist eher das einem da Projektideen fehlen wo man 
so eine Leistung wirklich braucht. Als Weihnachtsbaum-LED-Ansteuerung 
ist er auch mir etwas zu schade.

Im Prinzip ist das ein neues Luxusproblem. Waehrend man beim MCS48 noch 
ueber jedes SpeicherBIT nachgedacht hat, so bekommt man heute 
Microcontroller kaum noch ausgelastet.

Olaf

Danke Lothar für den tollen Link, da wird einem ganz nostalgisch zu 
Mute!
Hätte mal Acorn (ARM) vor 1981 diese tollen Computer rausgebracht, dann 
wäre uns die kranke 8088 Architektur erspart gewesen! Parallel zu den 
Acorn Computern gab es die Atari ST Serie mit der technisch sauber 
durchdachten 68000 Familie.

Deine Frage, wo sind diese Prozessoren alle geblieben, ist absolut 
gerechtfertigt! Motorola hat nach dem großen Erfolgen der 68000 
Dimension nichts mehr gebracht, weswegen Apple damals bei ihren Power 
PCs zu Intel gewechselt ist. Motorola hatte dann den Prozessorbereich 
ausgelagert, Freescale entstand, aber deren 16 Bit Prozessoren wie Star 
12, konnten mich nicht begeistern, waren aufgebohrte Achtbiter. 
Erinnerte mich an die Zilog Zeit, als man vom Z80 auf die Z800 Serie 
ging. Freescale wurde mittlerweile von NXP aufgekauft, womit das Kapitel 
Motorola ganz beendet ist, denn Freescales Werbespruch lautete damals 
"Freescale-launched by Motorola". Bin mal gespannt, ob die 
Automobilindustrie immer noch sehr stark auf Freescale/NXP setzt. Leider 
hatte ich vor 6 Jahren diese verlassen.

Ist die Komplexität des Befehlssatzes ziemlich egal, solange es einen 
passenden Compiler für irgendeine Hochsprache gibt?

Uwe schrieb:
> Hätte mal Acorn (ARM) vor 1981 diese tollen Computer rausgebracht

Immerhin läuft die ganze Acorn Software heute problemlos auf dem 
Raspberry Pi:

https://www.raspberrypi.org/blog/risc-os-for-raspberry-pi/

A. K. (prx)
>Nur IBM ist noch dabei, auf einem zwar sehr
>kleinen Markt, kann aber enorme Preise verlangen.

Wenn Du damit die Desktop PowerPCs meinst, dann vielleicht.
Es gibt aber eben auch die MPC Serie für Embedded-Anwendungen, die 
"noch" massiv in der Automotive-Industrie eingesetzt wird.

z.B.:
https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/mpc5xxx-55xx-32-bit-mcus/ultra-reliable-mpc57xx-32-bit-automotive-industrial-microcontrollers-mcus:MPC57XX

m.n. schrieb:
> Richtig edle Teile, kennt hier allerdings kein Schwein

Oink, oink... allerdings ist die Unterstützung durch WinCE seit langem 
eingestellt - nur so am Rande.

Also mal im Klartext: Das ist/war ne andere Liga als das, was hier auf 
dem Programm steht.



Uwe schrieb:
> als wenn man einem Fahrschüler, der gerade auf einem Golf die
> Führerscheinprüfung bestanden hat,...

leg einfach die Angst ab.
Es sind auch bloß Chips im TQFP mit 48..64..80..100..120 Pins, je nach 
Typ. Und die zugehörige Dokumentation ist auch nicht viel anders als bei 
den M0 Typen.

W.S.

Uwe schrieb:
> Hallo W.S.!
> .
> Stimmt der M4 hat ja schon DSP Funktionalitäten, da könnte man sich ja
> auch gleich in Fourier Analyse austoben. :-) Deine gesunden Ansichten
> und Technikbegeisterung in allen Ehren, aber mir kommt die Situation
> vor, als wenn man einem Fahrschüler, der gerade auf einem Golf die
> Führerscheinprüfung bestanden hat, einen 40 Tonner hinstellt nach dem
> Motto, damit kannste nicht nur zum Discounter fahren, sondern auch
> gleich deine Umzüge mit machen..... Ich möchte keinen brutalen Umstieg
> machen, sondern schrittweise die ARM-Cortexe kennenlernen in entspannter
> Atmosphäre! Der M4 wird bestimmt mal bei mir an der Reihe sein, aber
> nicht sofort, will ja meinen Lebensabend nicht verfluchen!
> Beste Grüße,
>
> U.H.

Hi Uwe,

Ich denke du machst dir unnötig einen Kopf. Du musst die volle 
Funktionalität ja nicht nutzen. Ich habe zum Beispiel CortexM3 Platinen 
im 10er Pack zu Hause liegen und nutze die für alles. Egal ob es nur ein 
Lauflicht ist, eine Schaltung für einen LED-Dimmer, oder die Steuerung 
eines Quadrokopters. Absolut irrelevant, denn der Preis ist so niedrig, 
dass es keine Rolle spielt. Wenn man C nutzt ist die Komplexität egal.

Selbst 14-Jährige können ARM-Prozessoren spielend einfach programmieren. 
Ich selbst habe einem Mechaniker die Thematik an Hand eines ARMs 
nähergebracht. Er programmiert natürlich in c und nutzt vorhandene 
Librarys von ST. Es ist kinderleicht und wirklich nicht schwer.

Hier im Forum gibt es jemanden der sogar Kindern die Elektronik an Hand 
von CortexM3 näherbringt. Er hat ein nettes Buch geschrieben.

Beitrag "Buch Vorstellung in eigener Sache - für Weihnachten?"

Also: Nur Mut. Schritt für Schritt. Und erstmal mit einem Blinki 
anfangen :-)

Lothar schrieb:
> Wobei ein M4F jetzt auch nicht die FPU Performance hat und der Preis in
> der Nähe eines Pi Zero liegt

Schreib keinen Unsinn.

Bei Farnell liegen die einschlägigen STM32F4xxx um und bei 5 Euro netto 
und bei Nuvoto-direct fangen die M4F bei etwa 2.50 Euro an, ab 10 Stück 
wird's billiger. Bastel-Boards dazu gibt's auch, die liegen bei etwa 
19..20 Euro, siehe Bild.

Der Pi-Zero liegt m.W. nackt ohne alles bei etwa 11..12 Euro und mit 
Adaptern bei etwa 17..20 Euro. Dazu dann noch die SD-Karte.. und das 
Ganze ist ne völlig andere Liga als ein Cortex M0..4, deswegen auch 
völlig andere Softwareumgebung, andere Paradigmen usw.

W.S.

W.S. schrieb:
> Der Pi-Zero liegt m.W. nackt ohne alles bei etwa 11..12 Euro

Der Pi Zero kostet 5 EUR. Du verwechselst das mit dem Pi Zero W:

https://shop.pimoroni.de/products/raspberry-pi-zero

> das Ganze ist ne völlig andere Liga als ein Cortex M0..4

Das ist falsch. Ohne Linux geht problemlos:

BASCOM-ähnliches BASIC mit Inline-Assembler z.B. Blinky

LED1 = 21
toggle = 0
SYS "GPIO_WriteMode", LED1, 1
REPEAT
  SYS "GPIO_WriteData", LED1, toggle
  toggle = 1 - toggle
  timeact = TIME + 25
  REPEAT
  UNTIL TIME > timeact
UNTIL FALSE

Auf PC BIN-File erzeugen und vom Bootloader statt einem Kernel laden 
lassen z.B.

https://github.com/PeterLemon/RaspberryPi/blob/master/HelloWorld/CPU/kernel.asm

Lothar schrieb:
> Das ist falsch. Ohne Linux geht problemlos:
...
> https://github.com/PeterLemon/RaspberryPi/blob/master/HelloWorld/CPU/kernel.asm

Willst du mich auf'n Arm nehmen?

Mal ganz davon abgesehen, daß all diese Githubianer es partout nicht 
fertig bringen, zu ihrem Krempel ein Konzept und eine Dokumantation 
ihres Krempels im PDF Format zuwege zu bringen. Wurschtel-Kruscht.

W.S.

A. K. schrieb:
> Pegge schrieb:
>> Selbst 14-Jährige können ARM-Prozessoren spielend einfach programmieren.
>
> Bizarrer Vergleich. Mit 70 dauert manches Neue etwas länger als mit 14.

Das stimmt allerdings. Als Jungspund vergisst man das oft.

W.S. schrieb:
> Dokumantation ihres Krempels im PDF Format zuwege zu bringen

Die BASIC Doku wurde erst am 04.11. komplett renoviert.

W.S. schrieb:
> m.n. schrieb:
>> Richtig edle Teile, kennt hier allerdings kein Schwein
>
> Oink, oink... allerdings ist die Unterstützung durch WinCE seit langem
> eingestellt - nur so am Rande.

Ich weiß nicht, wie Du in diesem Zusammenhang (SH2A) auf WinCE kommst.

> Also mal im Klartext: Das ist/war ne andere Liga als das, was hier auf
> dem Programm steht.

Von der reinen Rechenleistung her, spielen die von mir erwähnten 7211 
bzw. 7216 in der gleichen Liga wie Cortex-M4/-M7.
Die fehlende Verbreitung führe ich darauf zurück, daß es nie 
bastlergünstige Demo-Boards gab. Renesas war/ist sich vermutlich zu fein 
dafür oder hat es durch seine Großkunden nicht nötig gehabt, so etwas 
anzubieten. Neuerdings hat man aber auch noch ARM als Kernprozessor 
entdeckt. Vermutlich, weil man auf Kundendruck mit auf diesen Zug 
aufspringen mußte.

Wie auch immer: sieh Dir das Pinout von SH, H8SX oder auch 
RX-Controllern an und was die Peripherie bietet, dann verstehst Du, was 
ich als edel bezeichne.

Lothar schrieb:
> Die BASIC Doku wurde erst am 04.11. komplett renoviert.

Wo finde ich dieses BASIC? Bitte poste einen Link.

Sven D. schrieb:
> Wo finde ich dieses BASIC? Bitte poste einen Link.

Gab hier im Forum schon eine Diskussion zu: Es handelt sich um "RISC OS 
Pico"

Das ist kein Image wie z.B. Raspbian sondern der Inhalt des ZIP wird auf 
eine FAT-formattierte SD-Karte gezogen. Dann startet das Pi im BASIC

https://www.riscosopen.org/content/downloads/raspberry-pi

Da es natürlich dann keinen Desktop gibt, ist die Programmierung, auch 
mit Editor, umständlich. Daher nimmt man üblicherweise einen PC oder ein 
zweites Pi mit Desktop zum Programmieren, und schiebt das Ergebnis 
rüber. Es gibt auch Auto-Boot, dann wird das BASIC Programm auf der 
SD-Karte beim Einschalten gestartet. Das funktioniert ohne Monitor und 
Tastatur, also gut für Embedded.

Es gibt mehrere Foren z.B.

https://www.raspberrypi.org/forums/viewtopic.php?t=185715

Und hier hatte ich mal eine Grafik-Demo gepostet:

Beitrag "Re: Raspberry Pi als "dicker" Mikrocontroller"

Hatte ich noch vergessen: Ein Online-Manual gibt es auch z.B.

https://www.riscosopen.org/wiki/documentation/show/IIC_Control

> Von der reinen Rechenleistung her, spielen die von mir erwähnten 7211
> bzw. 7216 in der gleichen Liga wie Cortex-M4/-M7.
> Die fehlende Verbreitung führe ich darauf zurück, daß es nie
> bastlergünstige Demo-Boards gab.

In Deutschland. Ich bin ja auf den SH2A aufmerksam geworden weil so ein 
Board in Japan der Elektronikzeitschrift kostenlos beilag. Und es gab 
dort auch immer irgendwelche anderen billigen Boards von Renesas in den 
Elektronikgeschaeften.

Ich glaub sogar mal gesehen zu haben das Elektor hier auch mal ein Board 
mit so einem Controller hatte, bin mir aber nicht sicher.

Olaf

Olaf schrieb:
> Ich glaub sogar mal gesehen zu haben das Elektor hier auch mal ein Board
> mit so einem Controller hatte, bin mir aber nicht sicher.

Du meinst dieses Board: 
https://www.reichelt.de/MC-68HC-Controller/EVB-R8C13/3/index.html?ACTION=3&LA=2&ARTICLE=69672&GROUPID=2944&artnr=EVB+R8C13&SEARCH=%252A
Das sieht sich aber hier einer Konkurrenz von 'blauen Pillen' gegenüber, 
die jedem Schinagrabscher als portofreies 5er-Pack bekannt sein dürfte, 
und den R8C13 im Regen stehen lassen.

Für die SH2A µCs braucht man zum Einstieg allein schon einen E10A 
Emulator, der vor ein paar Jahren bei € 200/Stk. lag. Erst die neueren 
Renesas µCs (RX) werden mit 1- bzw. Mehrdraht Debug-Interface angeboten. 
SWD ist da im Vorteil und in der Praxis pflegeleichter zu benutzen.

> In Deutschland.

Wegen langer Lieferzeiten hatte ich mir Renesas-Teile wiederholt in USA 
besorgt. Jetzt bin ich beim STM32F4xx gelandet, den - wie oben 
geschrieben - selbst Farnell aktuell in guter Stückzahl zu gutem Preis 
anbietet.
Der F4 ist ein Spatz in der Hand - aber auch ein ganz flotter ;-)

Arc N. schrieb:
>> Die fehlende Verbreitung führe ich darauf zurück, daß es nie
>> bastlergünstige Demo-Boards gab.
>
> Mittlerweile gibt's die zumindest für RX und Synergy, afair alle mit
> J-Link eingebaut
> http://www.renesasshop.com/promotion-board

Bei den aufgeführten Boards würde ich wegen der Leistungsfähigkeit und 
des Alters nicht unter RX210 einsteigen wollen. RX210, ein schönes Teil, 
für das ich vor fünf Jahren ein bißchen (nutzlos) die Trommel gerührt 
habe: Beitrag "Verlosung RX210 Promo-Board"

Trotz J-Link Unterstützung sind die Endpreise > € 50, was hier im Forum 
schon als Wucher gilt. Nucleo-Boards mit ST-Link gibt es für weniger als 
ein Drittel 
(https://www.reichelt.de/Einplatinen-Microcontroller/NUCLEO-F411RE/3/index.html?ACTION=3&LA=446&ARTICLE=154272&GROUPID=6667&artnr=NUCLEO+F411RE&SEARCH=nucleo) 
und beim Kauf in Schina bekommt man (vermutlich) noch Geld dazu. Das 
ist, was hier zählt.
Daß diese RX einen fein konfigurierbaren Adress-/Datenbus bieten, rafft 
das Bastlerherz doch garnicht. Daß es neben einem DMA, der nicht nur 
vorwärts sondern auch rückwärts und teilweise mit beliebigen 
In-/Dekrement arbeiten kann, auch einen exDMA gibt, der ext. getriggert 
werden kann: merkt doch keiner, wozu braucht man DMA?
Und daß es für Peripherie viele, separate Interrupt-Vektoren für fast 
jedes einzelne Ereignis gibt: das habe ich noch nie gebraucht.
Was soll man da argumentieren?

Aber wie gesagt, auch Spatzen können fliegen, auch wenn es nicht immer 
so schön aussieht ;-)

> Du meinst dieses Board:
> https://www.reichelt.de/MC-68HC-Controller/EVB-R8C...

Noe, das meinte ich nicht. Das R8C Board hab ich ja sozusagen selber 
initiert. (Die Idee zu dem Elektorartikel und der Platine als Beigabe 
kam von mir) Das war ein paar Jahre frueher. Ich meine die hatten 
spaeter nochmal was gemacht.

> Für die SH2A µCs braucht man zum Einstieg allein schon einen E10A
> Emulator, der vor ein paar Jahren bei € 200/Stk. lag.

Das Teil was ich hier habe kann von SPI und SD-Karte booten und Renesas 
hat dafuer einen besonderen Bootloader geschrieben der spaeter die 
kontrolle an den HWS-Debugger uebergibt. Damit braucht man den E10 
nicht. Das haben sie wohl extra fuer das japanische Elektronikmagazin 
gemacht.

> Was soll man da argumentieren?

Das war schon damals bei den R8C so. Das tollen an den Teilen war 
naemlich damals der kostenlose KD30 ueber RS232. Gegen das konnten die 
AVR nicht anstinken. Aber der Bastler von Welt fand halt Ponyprog cooler 
und hat sich gefragt ob man Debugger essen kann. :-D

Olaf

> FYI: Die einen hassen ihn, die anderen lieben ihn: den GCC. Mit den
> R8C/M16C tut der sich etwas schwer.

Jaein. Du kannst dir den gcc einfach wie fuer jedes andere Zielsystem 
uebersetzen und nutzen. Das hab ich damals auch so gemacht. Er tat sich 
etwas schwer wenn man mehr wie 64k Flash hatte. Soll heissen man konnte 
ohne Tricks wohl nur 64k nutzen. Das ist aber natuerlich ein bizarrer 
Vorwurf weil die AVRs 2005 soviel Flash (oder gar Ram) garnicht hatten.
Versteht mich richtig, ich würde heute auch keinem mehr zu den alten 
M16C raten, aber damals waren sie genial. Bloss wuerden sie hier 
vermutlich auch wieder alle jammern das sie doch SOOOOOO kompliziert 
sind weil man da schon vor 15Jahren soviel Peripherie in einem 
Microcontroller bekommen konnte wie heute in einem ARM.

Olaf

> auf Pseudo-Register im RAM ausweichen, also dem Compiler mehr Register
> vorspiegeln, als das Target hat. Eine Methode, die ich als Notlösung
> betrachte.

Weisst du, das weiss ich garnicht. :-)
Ich nutze halt den Compiler und er macht was er soll.

Selbst als ich damals das hier geschrieben habe...

Beitrag "Neuer Multitasker Olix"

...ist es mir nicht aufgefallen. Dabei ist da sogar ein Stueck Assembler 
drin. Also wuerde ich mal sagen solange man kein Compilerentwickler ist, 
ist es piepegal.


> Allerdings sehe ich sowas auch heute noch eher kritisch: man hätte
> bei 128 KiB Flash und 64 KiB RAM aufhören sollen,

Es faellt einem auch schwer zu glauben das man 64kByte tatsaechlich mit 
Code vollprogrammiert. Ich denke wenn jemand soviel Flash braucht dann 
weil viel Tabellen oder Texte im Code stehen. Da ist es dann vermutlich 
auch egal wenn der Zugriff etwas komplizierter ist.

Olaf

Ich bin als Anfänger darüber gestolpert, dass der ADC des STM32F103 zum 
verrecken keine (Single-Shot) Messung machen wollte. Nach 4 Stunden 
try&error fand ich dann die Lösung.

Ich muss ihn für jede einzelne Messung immer wieder erst einschalten und 
dann starten:

1

    // Start a conversion

2

    SET_BIT(ADC1->CR2, ADC_CR2_ADON);

3

    SET_BIT(ADC1->CR2, ADC_CR2_SWSTART);

4

5

    // Wait until the conversion is finished

6

    while (!READ_BIT(ADC1->SR, ADC_SR_EOC));

7

8

    // Return the lower 12 bits of the result

9

    return ADC1->DR & 0b111111111111;

Die beiden Bits in einem Abwasch zu setzen, bringt nichts. Und dass man 
ADON immer wieder erneut einschalten muss, steht auch nicht im 
Datenblatt. Jedenfalls habe ich dazu nichts gefunden.

Da sind die Datenblätter der AVR's deutlich klarer geschrieben. Das 
gängige Totschlag-Argument von wegen "verfusen" zählt für mich nicht, 
denn diesen Fehler macht man höchstens 2 mal, wenn man bei Verstand 
ist.#

Tja, mein Beitrag ist noch da (juhu). Aber nun fragen sich alle, was 
will der stefanus uns damit sagen?

Kurze Erklärung für diejenigen, die die gelöschten Beiträge nicht 
gelesen haben:

Es ging darum, dass AVR Mikrocontroller deutlich einfacher zu verstehen 
und klarer dokumentiert sind, als so mancher ARM Controller. Da ich mich 
gerade mit der schlechten Doku eines ARM Modell abgekämpft habe, wollte 
ich ein konkretes Beispiel dazu zeigen.