mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Arm Cortex im DIP Gehäuse


Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend Elektronikfreunde!

Ich möchte mich an meinem Lebensabend mit den Arm-Cortex Controllern 
beschäftigen, entweder M0(+) oder M3, nachdem mich in meinem vorherigen 
Berufsleben Freescale Controller beschäftigt hatten. Allerdings graut es 
mir vor dem Löten von 0.65 mm oder gar 0.5 mm Pinabständen. Dem 
Verfahren mit dicken Lötkolben und dann Entlöten mit Entlötlitze traue 
ich nicht! 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. Gibt es denn keine DIP 
Versionen, die heute noch produziert werden, zumal ich gelesen hatte, 
die Chinesen verlöten diese noch in Massen? Wenn ja, könnt Ihr mir 
solche Typen nennen?

Herzliche Grüße und vielen Dank im voraus,

Uwe

Autor: Stefan Schmidt (chiefeinherjar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist nichts aktuelles bekannt.
Man kann natürlich zu Beginn erstmal auf die Blue-Pill-Boards 
zurückgreifen. Wenn ich mich recht entsinne, passen die auf ein DIP 40 
Sockel. Alternativ legt man sich eben einen eigenen Footprint an und 
verwendet diesen dann im Layout oder bei einer Lochrasterplatine.

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

Probier es doch einfach mal aus. Es klappt besser als man denkt.

Alternativ gibt es für um die 30 Euro eine preiswerte 
Heißluftlötstation. Mit der kann man sehr viel SMD-packages löten.
Eine einfache Stirnlupe bzw Stehlupe ist auch sehr hilfreich.

Ich habe mich auch lange davor gescheut und genau so gedacht wie du. 
Mittlerweile bin ich völlig vom Gegenteil überzeugt.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Atmel - pardon - Microchip SAMD10 (M0+) gibt es zumindest in SOIC.

: Bearbeitet durch User
Autor: A. B. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Warum nicht so etwas:
https://www.aliexpress.com/wholesale?catId=0&initi...

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 ...

Autor: Stefan Schmidt (chiefeinherjar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. B. schrieb:
> Warum nicht so etwas:
> 
https://www.aliexpress.com/wholesale?catId=0&initi...

Danke! Genau die meinte ich mit:

Stefan S. schrieb:
> Man kann natürlich zu Beginn erstmal auf die Blue-Pill-Boards
> zurückgreifen. Wenn ich mich recht entsinne, passen die auf ein DIP 40
> Sockel.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan S. schrieb:> Man kann natürlich zu Beginn 
erstmal auf die Blue-Pill-Boards
> zurückgreifen. Wenn ich mich recht entsinne, passen die auf ein DIP 40
> Sockel.

Und selbst wenn solche Boards 1-2 Einheiten breiter sein sollten, oder 
48 statt 40 Pins haben: Es gibt einreihige Buchsenleisten.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: DIP CHIP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Checker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann verwende einen Teensy.
https://www.pjrc.com/teensy/

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian E. (sbe_15)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den LPC1114 (M0) gibts im DIP28 (LPC1114FN28).

Autor: scd (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. 
;-)

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe schrieb:

> deine ... idee 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?

Mach dir da nicht zu viel Hoffnung. Paste mußt du auf die Pads erst 
aufbringen. Und für Hobbybastler lohnt das eher nicht, denn die Paste 
hat (spätestens nach dem Öffnen des Gebindes) nur noch eine kurze 
Lebensdauer. Das lohnt einfach nicht.

Die Pads dick vorverzinnen und dann Reflowlöten mit Heißluft geht im 
Prinzip. Aber ehrlich gesagt mag ich die Zinntropfenmethode lieber. Man 
darf nur nicht mit Flux sparen und eine industriell hergestellte Platine 
mit maßhaltigen Pads und Lötstop ist auch von Vorteil. Andererseits habe 
ich schon 0.65mm Pitch auf einfache selbst gefertigte Platinen gelötet. 
Rund um die Pads einen "Rahmen" aus Kapton-Band geklebt, IC mit der 
Kreuzpinzette fixiert und einen Zinntropfen üder die Pins gezogen. Geht 
1A.

Uwe schrieb:
> STM scheidet bei mir aus, weil wohl Code
> im Flash mit vielen Waitstates ausgeführt wird

Da solltest du dich mal richtig informieren. Bei Taktfrequenzen >32MHz 
kommt kaum noch Flash mit. Sprich: bei hoher Taktfrequenz brauchen alle 
Cortexe Waitstates, wenn sie Code aus dem Flash ausführen. Das Problem 
erledigt sich natürlich, wenn der µC von vornherein nicht so schnell 
getaktet werden kann. Einen Vorteil würde ich das aber nicht nennen.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Axel S. schrieb:
> Mach dir da nicht zu viel Hoffnung. Paste mußt du auf die Pads erst
> aufbringen. Und für Hobbybastler lohnt das eher nicht, denn die Paste
> hat (spätestens nach dem Öffnen des Gebindes) nur noch eine kurze
> Lebensdauer. Das lohnt einfach nicht.

Kann ich so nicht bestätigen.

Die Stannol-Paste, die wir hier einsetzen, ist auch nach fast vier 
Jahren noch einwandfrei.

Vorraussetzung dafür: Lagerung im Biofreshfach bei knapp über 0°C, am 
besten in kleinen Portionen.

Eine eingefrorene Probe bei -20°C aus 2014 werde ich demnächst testen.

Für den Einsatz von Paste per Hand würde ich Uwe noch einen 
Druckluft-Dispenser (ca. 60€ aus China) empfehlen. Damit macht das 
Auftragen der Paste deutlich mehr Spaß :-)

So ausgerüstet sind SMD-Gehäuse wirklich zuverlässig und sauber lötbar.

: Bearbeitet durch Moderator
Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Schmidt (chiefeinherjar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
> Axel S. schrieb:
>> Mach dir da nicht zu viel Hoffnung. Paste mußt du auf die Pads erst
>> aufbringen. Und für Hobbybastler lohnt das eher nicht, denn die Paste
>> hat (spätestens nach dem Öffnen des Gebindes) nur noch eine kurze
>> Lebensdauer. Das lohnt einfach nicht.
>
> Kann ich so nicht bestätigen.
>
> Die Stannol-Paste, die wir hier einsetzen, ist auch nach fast vier
> Jahren noch einwandfrei.
>
> Vorraussetzung dafür: Lagerung im Biofreshfach bei knapp über 0°C, am
> besten in kleinen Portionen

Da schließe ich mich Jörg an. Kühl gelagert hält sie ausreichend lang.
Eine "Spritze" mit Lötpaste kostet um die 5 - 7 Euro.  Das ist bei 
regelmäßigem Einsatz eigentlich kein so großer Kostenfaktor.

Wenn man die kühl lagert hat man auch ein paar Monate etwas davon.

Und ja, das Bestücken erfordert zwar auch etwas Geschick, aber einen 
sehr großer Teil wird auch durch die Oberflächenspannung des Zinns 
erreicht.
Probier es am besten selber aus oder schau dir Videos bei Youtube an - 
da sieht man, wie so ein TQFP quasi "von alleine" in die richtige 
Position rutscht.

Autor: guest...Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe schrieb:
> Guten Abend Elektronikfreunde!
>
> Ich möchte mich an meinem Lebensabend mit den Arm-Cortex Controllern
> beschäftigen, entweder M0(+) oder M3, nachdem mich in meinem vorherigen
> Berufsleben Freescale Controller beschäftigt hatten. Allerdings graut es
> mir vor dem Löten von 0.65 mm oder gar 0.5 mm Pinabständen. Dem
> Verfahren mit dicken Lötkolben und dann Entlöten mit Entlötlitze traue
> ich nicht! 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. Gibt es denn keine DIP
> Versionen, die heute noch produziert werden, zumal ich gelesen hatte,
> die Chinesen verlöten diese noch in Massen? Wenn ja, könnt Ihr mir
> solche Typen nennen?

Nimm doch PIC32. Ist zwar MIPS statt ARM, aber es gibt etliche Typen im 
SDIP28, und sie sind alle problemlos erhältlich. Und von der Leistung 
her tut sich das nichts.

fchk

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Johannes!

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

Uwe

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;
      }
    }

Autor: Daniel B. (dbuergin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir nehmen schon lange für kleinere Inhouse Serien solche Boards:
https://www.waveshare.com/product/mcu-tools/stm32/...

Autor: Berti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe schrieb:
> taugt der Atmel ICE etwas

Das Teil ist OK, nur die Programmierkabel mit den kleinen Steckerchen
gehen schnell kaputt.  Den Stecker hat allerdings ARM selbst so
standardisiert, da hat Atmel sich nur an den Standard gehalten.

Im Hobbybereich habe ich die Kabel auch noch nicht geschafft, aber
im beruflichen Umfeld haben wir da leider immer wieder Kackelwontakte.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...
Alternativ könnte man sich die aus Pogo Pins bauen, gibts beim Chinesen 
sehr günstig.

: Bearbeitet durch User
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lothar schrieb:
> Das ist zwar ein 8051 aber langsamer als der M0+ ist der nicht.

Könntest du mal bitte dein ewiges Evangelisieren belassen?  Die Frage
war nicht „was ist der beste Controller für mich?“, sondern „welchen
ARM-Controller kann ich verbauen?“ (das war schon eine Erweiterung
der ursprünglichen Frage nach dem DIP-Gehäuse).  Schließlich wollte
der TE ausdrücklich von einem 8-Bitter (den er schon kennt und hat)
umsteigen.

Autor: Stefan Schmidt (chiefeinherjar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe schrieb:
> Egal, ich probiere es aus, langsam macht mir das Thema Spaß, wenn ich
> hier so Eure Einstellungen sehe!

Mein Reden von Anfang an ;)

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

Oder man sieht einfach beim Layout dedizierte Testpads vor. Oder man 
nutzt Vias zum Messen. Und an SOICs mit 1,27 mm Pitch kann man auch noch 
vernünftig messen.
Also diese Ausreden zählen nicht ;)

Olaf schrieb:
> Du kannst in 0603er praktisch alles zuhause rumliegen haben.

Du kriegst die ganze E24 Reihe von 10 Ohm bis 1MegOhm in zwei dieser 
Kästen unter:
https://www.welectron.com/Licefa-V11-3-SMD-Lagerka...

Uwe schrieb:
> Ob es daran liegt, daß durch das Flussmittel das Lot dünnflüssiger wird
> und daher schneller zerläuft?

Richtig. Und es heißt nicht umsonst LötSTOPPmaske. Das Lot perlt einfach 
ab und wird dank des Kapillareffekts zu und unter die Beinchen gezogen.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bülent C. (mirki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Google mal nach s64dil reusch

Autor: guest...Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pegge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: eagle user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bülent C. schrieb:
> Google mal nach s64dil reusch

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

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?).

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Bülent C. (mirki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast sowohl 5V, wenn du vom USB einspeist, als auch 3v3 auf den 
rausgeführten pins.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: guest...Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pegge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/discussio...

Autor: Lutz H. (luhe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe schrieb:
> Allerdings graut es
> mir vor dem Löten von 0.65 mm oder gar 0.5 mm Pinabständen

Mit viel heißer Luft das Löten schon mal versucht?

: Bearbeitet durch User
Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: eagle user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eagle user schrieb:
> Wer designed so kranke Chips?

CM0/CM0+ sind auf minimale Chipfläche designt.

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die klassische 32-Bit ARM Architektur kennt bis heute keine 
Hardware-Division, d.h. ARM7, ARM9, ARM11 und 32-Bit Cortex-A können 
nicht in Hardware dividieren. Wenn dein Android-Handy zwar 64-Bit 
Cortex-A5x/7x enthält, aber im 32-Bit Modus arbeitet (bis vor 1-2 Jahren 
verbreitet), dann wird es ganzzahlig nicht in Hardware dividieren.

Als mit den ARM7-TDMI Mikrocontrollern der Thumb-Befehlssatz hinzu 
gefügt wurde, wurde infolgedessen auch keine Division hinzugefügt, denn 
diese neuen Befehle waren sämtlich direkt auf native ARM-Befehle 
abbildbar.

Erst mit dem stark erweiterten und selbständigen Thumb2-Befehlssatz der 
Cortex-M3 aufwärts kam eine Division ins Spiel, ebenso bei den Cortex-R. 
Da die Cortex-M0 aber auf dem nur minimal erweiterten alten 
Thumb-Befehlssatz basieren, blieb ihnen die Division erspart.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Division ist die kostspieligste der Grundrechenarten, daher hat man
> diese dort weggelassen.

Division ist laufzeitintensiv, aber nicht wirklich aufwändig zu 
implementieren. Während man eine Multiplikation kombinatorisch 
implementieren kann, also ohne auf ein interne Schleife zurückzugreifen, 
ist das bei der Division nicht möglich.

Eine implementierte Division ist also stets eine interne Schleife, in 
einfacheren Fällen mit einem Bit pro Iteration. Arg viel 
Hardware-Ressourcen sind dafür nicht nötig, im Grund nur ein Sequencer 
(btw. Microcode, wenn sowieso schon microcoded).

Andererseits ist der Chipaufwand für eine kombinatorische Multiplikation 
recht hoch. Bei den Cortex-M0 ist der optional, d.h. ein M0 Core kann 
mit kombinatorischem Multiplier konfiguriert sein (1 Takt), oder mit 
iterativem Multiplier (32 Takte). Das war auch schon bei den ARM7 so: 
Das "M" im -TDMI Suffix von ARM7-TMDI Cores signalisiert einen 
kombinatorischen Multiplier.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> 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.

Der ARM7 arbeitete ausschliesslich im nativem ARM Befehlssatz. Der 
ARM7ZDMI hatte optional den Thumb-Befehlssatz drin, aber Exceptions 
waren nativ und ohne Klimmzug nicht reentrant.

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

> Hinterher hat man dann gemerkt, dass dadurch Latenzen auftreten, keine
> Rekursion mehr möglich ist, und bei Stacküberlauf Hardfault.

Rekursion ist der falsche Begriff, Reentrancy passt schon besser. Das 
Interrupt-System der klassischen ARM Architektur erlaubt von Haus aus 
keine Verschachtelung von Interrupts jenseits der 2 Hardware-Interrupts, 
Normal und Fast. Wenn man im Handler vom Interrupt-Kontext in den 
System-Kontext wechselt, dann wird verschachtelung möglich, man arbeitet 
dann aber eben auf dem Stack des System-Kontextes und nicht mehr auf dem 
Interrupt-Stack.

Entweder erlaubt man im klassischen ARM verschachtelte Interrupts mit 
mehr als den alten 2 ARM-Prioritäten, dann hat man einen Stack der 
deshalb überlaufen kann. Oder man bleibt bei den 2 Prioritäten und diese 
2 Interrupts besitzen vom Normalbetrieb abgetrennte Stacks.

Die Latenzen der Cortex-M sind recht gering, da Befehle mit grosser 
Laufzeit abbrechbar sind, wie beispielsweise LDM/STM und Division. Der 
für Verschachtelung nötige Klimmzug der alten ARMs hingegen muss bis zum 
Kontextwechsel mit abgeschalteten Interrups arbeiten, was die Latenz 
deutlich grösser gestaltet.

Wie Cortex-R damit umgeht weiss ich nicht.

: Bearbeitet durch User
Autor: N. G. (newgeneration) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Wie geschrieben will aber Stand heute niemand mehr bezahlen für den
> Fast. Alle NXP CM0 haben daher Fast.
(Hervorhebung durch mich)

Hallo,

stimmt so nicht ganz. Es gibt einige Spezialfälle, als Beispiel sei der 
LPC54102 von NXP genannt. Dieser besitzt zusätzlich zu einem Cortex-M4 
noch einen zweiten Prozessor: einen Cortex-M0+. Und dieser hat eben 
(wahrscheinlich wegen knapper Chip-Fläche) nur den iterativen 
Multiplizierer. Auszug aus dem Datenblatt:
In LPC5410x, the Cortex-M0 coprocessor hardware multiply is implemented as a 32-cycle iterative multiplier.

Dafür beherrscht der ARM GCC aber auch eine extra Option, damit 
einfachere Shifts generiert werden, anstatt den Multiplier zu nutzen. 
Siehe dazu die Anmerkung im verlinkten Artikel.

Aber natürlich stellen die Cortex-M0(+) mit iterativem Multiplier eine 
absolute Minderheit dar.

Mit freundlichen Grüßen,
N.G.

Autor: Bülent C. (mirki)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> eagle user schrieb:
> Wer designed so kranke Chips?
>
> CM0/CM0+ sind auf minimale Chipfläche designt.
>
> Division ist die kostspieligste der Grundrechenarten, daher hat man
> diese dort weggelassen.

Solange der divident zweier Potenz ist brauch ich auch keinen hardware 
teiler :-)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bülent C. schrieb:
> Solange der divident zweier Potenz ist brauch ich auch keinen hardware
> teiler

Aber einen "barrel shifter", gibt's den nicht (wie beim 8-Bit-AVR), ist 
auch das Schieben eine "kostbare" Operation.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Cortex-R und auch die Cortex-A verwenden das alte Exception-System. 
Die maximale Interrupt-Latenz der Cortex-R kann also effektiv nur dann 
gegenüber den Cortex-M besser sein, wenn man sich auf eine Unterbrechung 
normaler Interrupts durch Fast-Interrupts bezieht. Verschachtelbar sind 
diese Fast-Interrupts dann aber nicht. Und mit Verschachtelung normaler 
Interrupts ist deren maximale Latenz schlechter als die der Cortex-M.

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. Die maximale 
Verschachtelung von Interrupts lässt sich auch bei den CMx begrenzen, 
indem man das Prioritäts-System entsprechend einstellt.

Autor: dumdideldei (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Aber einen "barrel shifter", gibt's den nicht (wie beim 8-Bit-AVR), ist
> auch das Schieben eine "kostbare" Operation.

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

Autor: Bülent C. (mirki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Bülent C. schrieb:
> Solange der divident zweier Potenz ist brauch ich auch keinen hardware
> teiler
>
> Aber einen "barrel shifter", gibt's den nicht (wie beim 8-Bit-AVR), ist
> auch das Schieben eine "kostbare" Operation.

Stimmt, aber ich bezog mich auf den cm0, der hat den

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dumdideldei schrieb:
> - Knackige Logikrätsel beim Debuggen von DMA dank Adressvirtualisierung

Haben die kleinen Cortexe nicht.  Eine Sorge weniger. :)

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Wer sich darueber beschwert das fette Microcontroller komplizierte DMA
> haben

Es ging doch nicht um DMA, sondern um virtualiserte Adressen.  Da die
DMA natürlich in physischen Adressen arbeitet, hast du dort halt noch
eine Ebene mehr, die man berücksichtigen muss.

Beitrag #5212082 wurde von einem Moderator gelöscht.
Beitrag #5212086 wurde von einem Moderator gelöscht.
Beitrag #5212092 wurde von einem Moderator gelöscht.
Beitrag #5212095 wurde von einem Moderator gelöscht.
Beitrag #5212097 wurde von einem Moderator gelöscht.
Beitrag #5212106 wurde von einem Moderator gelöscht.
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=S...

Autor: Stefan Us (stefanus)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Bülent C. (mirki)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Offtopic:
Das ist das schöne an diesem Forum :-) Der TO fragt nach einem Cortex in 
DIP Bauform und die Diskussion geht über Hardware divider, Barrel 
shifter und DMA Adressen bis zu parallel Verarbeitung mit dual core 
uC's. Abgerundet wird das ganze mit vergleichen zu AVR's, 8051'ern und 
weiteren.
Dieses Forum ist sehr informell, alleine schon nur im diesem Thread 
stecken verdammt viele nützliche Infos.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Alles würde ohne Probleme funktionieren, hätte man für jeden Mode
> einfach eine komplette Registerbank gemacht, wie beim 8051.

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.

> Es ist dadurch nicht echtzeitfähig:

Inwiefern wird er durch die im Text geschilderte Eigenschaft nicht 
echtzeitfähig?

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Dafür muss der System-Stackpointer initialisiert werden. Dennoch kann es
> dann durch das Autostacking by Exceptions zum Stacküberlauf kommen.

Kannst du das näher erläutern? Insbesondere inwieweit das unvermeidlich 
zum Problem wird.

: Bearbeitet durch User
Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: chris (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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-...

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
Youtube-Video "The first ARM processor in the world with Sophie Wilson (Part 2)"
womit sie wahrscheinlich zu den einflussreichsten Frauen der Computerära 
gehören dürfte.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Es hat mich erstaunt, dass der Barrelshifter so wichtig ist, dass man so
> viel Fläche dafür spendiert.

Bei der ARM Architektur war wohl zuforderst eine Idee der Hardware da, 
erst dann der Befehlssatz jenseits von RISC und Predication. Nämlich die 
Idee, den rechten Port der ALU stets über einen separaten Barrelshifter 
zu bedienen. Womit man Adressrechnung mit skaliertem Offset oder Index, 
Shifts und den Byteselect von Load-Byte alles in einem Aufwasch 
erledigt. Erst daraus ergab sich dann der konkrete Befehlssatz, d.h. was 
man damit alles anfangen kann.

Wobei da freilich schon gleich der erste kleine Konzeptfehler eingebaut 
wurde. Um den Barrel Shifter mit einem Register für die Anzahl bedienen 
zu können bräuchte man 3 lesende Register-Ports. Diese Ports sind aber 
schweineteuer, weshalb man nur 2 implementierte und solche Befehle auf 2 
Takte ausdehnte.

Das widerspricht dem einfachen Ablaufprinzip der RISC-Befehle und es 
bremst. Klüger wäre es m.E. gewesen, dafür schlicht das Register vom 
linken ALU-Port mitzuverwenden. Meist sind dynamische Shift/Rotates 
sowieso Move-Befehle, da ist dieser Port ungenutzt. Aber es wäre in 1 
Takt erledigt. In den wenigen Fällen, wo man Arithmetik/Logik mit 
dynamischen Shifts verbindet, wären es eben 2 Befehle geworden, die mit 
zusammen 2 Takten auch nicht langsamer sind als 1 Befehl in 2 Takten.

: Bearbeitet durch User
Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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}

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> 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}

Man bräuchte keinen Stack, sondern ein separates Register für die 
Exception-Return-Adresse, grad so wie es das SPSR für das CPSR gibt. Und 
natürlich einen Befehl für Exception-Return. Damit wäre der Kessel 
geflickt und Interrupts im Interrupt-Kontext verschachtelbar.

Bei den ganz alten ARMs mit kombiniertem PC/PSR kann ich das noch 
verstehen. Minimalistik, man brauchte einen Proz für den Acorn-Rechner 
und sonst nichts. Aber in den Übergang zum getrenntem CPSR hätte das gut 
reingepasst.

: Bearbeitet durch User
Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Richtig edle Teile, kennt hier allerdings kein Schwein ;-)

Renesas oder deren Distributor hatte vor Jahren mal versucht, den 
Bastlern die nicht annähernd so edle R8C/M16C Linie schmackhaft zu 
machen. Ebenfalls ohne durchschlagenden Erfolg.

Chips alleine machen nicht glücklich, und seien sie noch so edel. Eine 
Infrastruktur aus Entwicklungssystemen und Supportforen spielt auch noch 
eine Rolle. Und dass man sie nicht nur bei Digikey kriegt.

: Bearbeitet durch User
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Und der ARM11 mit NEON FPU hat eine ganz andere Rechenleistung.

Lass mal die Kirche im Dorf.  Er will von einem AVR umsteigen.

Vier Multiplikationen und eine Division von 32-bit-Zahlen (auch, wenn
letztere in Software erfolgt) sind nun wirklich nicht das Thema.

Beitrag #5212555 wurde von einem Moderator gelöscht.
Beitrag #5212610 wurde von einem Moderator gelöscht.
Beitrag #5212619 wurde von einem Moderator gelöscht.
Beitrag #5212623 wurde von einem Moderator gelöscht.
Beitrag #5212644 wurde von einem Moderator gelöscht.
Beitrag #5212685 wurde von einem Moderator gelöscht.
Beitrag #5212700 wurde von einem Moderator gelöscht.
Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Beitrag #5212711 wurde von einem Moderator gelöscht.
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Allerdings, und das hat mich sehr überrascht da Atmel diese Serie auch
> als AVR bezeichnet hatte.

Techniker am Werk... Also nix gegen Techniker, aber jenseits vom 
Tellerrand gibts auch eine Welt. Die verachtete Welt des Marketings.

Ein anderer Name wäre ein solider Schuss ins Knie gewesen. AVR ist ein 
gut eingeführter Produktname und jeder hätte sich gefragt, ob man die 
Teile mit neuem Namen überhaupt in die bisherige Infrastruktur 
integrieren kann, oder ob man jetzt doch endlich den Schritt zu ARM 
macht. Zumal der Unterschied zu den alten AVRs so gross nun doch nicht 
ist.

: Bearbeitet durch User
Beitrag #5212714 wurde von einem Moderator gelöscht.
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Beitrag #5212722 wurde von einem Moderator gelöscht.
Beitrag #5212727 wurde von einem Moderator gelöscht.
Beitrag #5212731 wurde von einem Moderator gelöscht.
Beitrag #5212734 wurde von einem Moderator gelöscht.
Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Beitrag #5212739 wurde von einem Moderator gelöscht.
Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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-microc...

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

Autor: Olaf (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> AVR ist ein gut eingeführter Produktname und jeder hätte sich gefragt,
> ob man die Teile mit neuem Namen überhaupt in die bisherige
> Infrastruktur integrieren kann, oder ob man jetzt doch endlich den
> Schritt zu ARM macht.

Naja, das dürfte vor allem an der extrem späten Markteinführung
gelegen haben.  Als die Xmega konzipiert worden sind, war ARM noch
nicht so deutlich am Horizont, insbesondere noch kein Cortex-M.
Allerdings hat es von den ersten Prototypen bis zur Serienreife
mehrere Jahre gedauert, weil es wohl Probleme mit dem Flash gab.
Beim ATxmegaA1 hat selbst Rev. H ja noch eine nicht ganz kleine
Errata-Liste.

Im Prinzip hätte man wohl während der Odyssee des ersten Xmega
irgendwann die Reißleine ziehen sollen, und das interessante Eventsystem
in einen Cortex-M integrieren.  Da die Probleme jedoch nicht bei der
CPU, sondern beim Flash lagen, ist fraglich, ob das alles damit viel
erfolgreicher geworden wäre.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Als die Xmega konzipiert worden sind, war ARM noch
> nicht so deutlich am Horizont, insbesondere noch kein Cortex-M.

Der Cortex-M3 wurde bereits 2004 vorgestellt, die ersten µCs damit 
könnten von Luminary Micro gewesen sein, mit (C) von 2006. Die 
adressierten auch ganz offensichtlich den von 8/16-Bittern dominierten 
Markt, auch den von kleineren Typen mit 20 Pins.

> Im Prinzip hätte man wohl während der Odyssee des ersten Xmega
> irgendwann die Reißleine ziehen sollen, und das interessante Eventsystem
> in einen Cortex-M integrieren.

Yep. Die Renovierungen um den Core herum sind der interessante Teil. Den 
Core hingegen betrachte ich als bereits bei Markteinführung veraltet. 
Umständlicher als CM0, kaum klare Vorteile.

: Bearbeitet durch User
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Jörg W. schrieb:
>> Als die Xmega konzipiert worden sind, war ARM noch
>> nicht so deutlich am Horizont, insbesondere noch kein Cortex-M.
>
> Der Cortex-M3 wurde bereits 2004 vorgestellt, die ersten µCs damit
> könnten von Luminary Micro gewesen sein, mit (C) von 2006.

Der Xmega dürfte ähnlich alt sein.  Ich glaube mich zu erinnern, den
ersten (noch handverlesenen) in Trondheim 2007 in die Hand gedrückt
bekommen zu haben.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Als die Xmega konzipiert worden sind, war ARM noch
> nicht so deutlich am Horizont, insbesondere noch kein Cortex-M.

Als mir gesagt wurde, daß die Xmega definitiv kein CAN haben werden, 
habe ich sie gleich wieder vergessen.

A. K. schrieb:
> er Cortex-M3 wurde bereits 2004 vorgestellt, die ersten µCs damit
> könnten von Luminary Micro gewesen sein

Um die ist es wirklich schade, die hatten Ethernet noch komplett intern. 
Nur noch den Magjack dranpappen, fertisch.

Beitrag #5213257 wurde von einem Moderator gelöscht.
Beitrag #5213309 wurde von einem Moderator gelöscht.
Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe schrieb:
> Motorola hat nach dem großen Erfolgen der 68000
> Dimension nichts mehr gebracht,

68000 wurde so lange weiter entwickelt, bis man merkte, dass man 
zurückrudern muss, weil die Architektur in all ihrer Komplexität mehr 
mit sich selbst als mit dem Programm beschäftigt war. Daraus entstand 
Coldfire.

Bei Performance kam danach Motorolas eigener RISC Ansatz, 88000. 
Interessant, potentiell schnell - und schwierig. Blieb ein Randphänomen.

Dann ging es zusammen mit IBM ins PowerPC Konsortium. Woraus auch 
Controller resultierten. Gegen Intel anzustinken erwies sich aber auf 
Dauer als nicht lukrativ, hoher Aufwand, zu kleiner Markt bei zu 
geringen Preisen dafür. Nur IBM ist noch dabei, auf einem zwar sehr 
kleinen Markt, kann aber enorme Preise verlangen.

Nebenbei gab es noch eine weitere RISC-Hochzeit, auf der Motorola 
tanzte, nämlich MCore. Der Sinn entging mir allerdings.

Autor: Stefan Us (stefanus)
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe schrieb:
> Erinnerte mich an die Zilog Zeit, als man vom Z80 auf die Z800 Serie
> ging.

Mit Z8000 zwischendrin. Gab aber ein paar Probleme damit. Zilog setzte 
damals als einziger der drei Firmen auf Random Logic, Intel und Motorola 
hingegen auf Microcode. Das Debugging dauerte viel zu lang und am Ende 
waren sie dann recht spät dran. Dessen Nachfolger Z80000 landete nach 
einiger Quälerei wohl nur deshalb nicht alsbald in den Papierkorb, weils 
irgendwo im Pentagon drin steckten soll.

Bei Controller gab es auch recht bald die Z8. Sehr interessantes Design, 
angenehm zu programmieren. Hatte aber einen Haken: Die Architektur war 
effektiv auf gut 200 Bytes RAM festgenagelt, mehr ging nicht. Oder nur 
mit hässlichen Winkelzügen wie bei 8051, womit die ganze Eleganz beim 
Teufel gewesen wäre. Eine Revision der Architektur gibts als Z8 Encore.

Dafür gibts aber eine 32-Bit Z80, Z380. Darauf hatte die Welt gewartet.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Ist die Komplexität des Befehlssatzes ziemlich egal, solange es einen
> passenden Compiler für irgendeine Hochsprache gibt?

Dem Anwender schon. Aber nicht dem Chipentwickler.

Nicht wenn du einen hochkomplexen Befehlssatz so implementieren willst, 
dass das Ergebnis so schnell wie bei der Konkurrenz kommt und trotzdem 
nicht von der Mondphase abhängt. Sowohl was den Aufwand auf dem Chip 
angeht (das war besonders in den 90ern relevant), als auch beim 
gegenüber strukturell einfacheren Konstruktionen viel grösseren 
Entwicklungsaufwand.

Wenn du Befehle baust, die alle Operanden einer N-Adress-Operation im 
Speicher zulassen, und virtuellen Speicher implementierst, dann wirds 
sehr schnell ungemütlich. Motorola bekam das gebacken, indem sie nicht 
wie alle anderen die Befehle abbrechbar gestalteten, sondern mitten im 
Microcode unterbrachen um später an dieser Stelle wieder aufzusetzen.

National Semiconductor bekam das bei den 32000-er CPUs möglicherweise 
nie wirklich in den Griff und überliess dem Programmierer das Lesen von 
Errata-Listen. DEC ging bei dem Versuch, die VAX konkurrenzfähig zu 
halten, fast koppheister. Und beliess es dann dabei - der nächste 
Schritt bestand darin, die Architektur einzustampfen und durch Alpha zu 
ersetzen.

Bei der Dekodierung hochkomplex codierter Befehle und superskalarer 
Ausführung sah das nicht besser aus als bei N-Adress-Operationen. 
Versuch mal, 2 Befehle pro Takt zu decodieren, wenn du bei keinem davon 
die Länge kennst, und deren Länge nicht nur vom Opcode abhängt (x86), 
sondern auch noch von der Codierung des ersten und zweiten Operanden 
(VAX, 68020, 32000).

Der entscheidende Schritt bei x86 kam mit dem Pentium Pro. Damit gelang 
es Intel, den gordischen Knoten zu durchschlagen. Das war aber nur 
finanzierbar, weil Intel sich mit den vorherigen x86ern dumm und 
dusselig verdiente. Immerhin wird die Entwicklung komplexer Chips über 
Jahre hinaus vorfinanziert. Wenn das dann nichts wird ist der Laden 
schnell pleite.

: Bearbeitet durch User
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Beitrag #5213719 wurde von einem Moderator gelöscht.
Beitrag #5213756 wurde von einem Moderator gelöscht.
Beitrag #5213764 wurde von einem Moderator gelöscht.
Beitrag #5213796 wurde von einem Moderator gelöscht.
Beitrag #5213841 wurde von einem Moderator gelöscht.
Autor: Markus F. (mfro)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
A. K. schrieb:
> 68000 wurde so lange weiter entwickelt, bis man merkte, dass man
> zurückrudern muss, weil die Architektur in all ihrer Komplexität mehr
> mit sich selbst als mit dem Programm beschäftigt war. Daraus entstand
> Coldfire.

Irgendwie hatte man bei Motorola/Freescale am Schluss immer das Gefühl, 
dass die ihr Zeugs eigentlich gar nicht verkaufen, sondern lieber 
behalten wollten.

MC68060RC50 (mit 50 MHz spezifiziert) laufen bis heute mit >100 MHz 
stabil.

M54[78]x (ColdFire) läuft mit 266 MHz und hat ein Speicherinterface, das 
kaum 50 MB/s schafft. Das USB-Interface hatte gefühlt 150 Erratas bis 
das letzte davon dann (verklausuliert) sagte: "vergiss' es. Funktioniert 
nicht".

Trotzdem hänge ich persönlich immer noch an dieser (m.E. sehr eleganten) 
Architektur.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-microc...

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> 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-microc...

Ich denke, er meint keineswegs Desktop PowerPCs (die sind so gut wie 
ausgestorben), sondern Serversyteme vom Schlage einer Power 8 E880.

Letztendlich ist das die einzige Prozessorarchitektur für grosse 
Serversysteme, die es geschafft hat, der Intel/AMD Übermacht zu trotzen 
(wobei für mich persönlich fraglich ist, wie lange sie das noch tut).

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pegge (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 :-)

Autor: W.S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/mas...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Der Pi Zero kostet 5 EUR.

Nur kann man ihn nicht in Stückzahlen kaufen, sondern darf ihn *immer 
nur einzeln* bestellen, so daß immer schön Verpackung und Versand 
dazukommen. Beim Zero W ist es, entgegen andersartiger Ankündigungen, 
auch nicht anders.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:

> A. K. schrieb:
>> er Cortex-M3 wurde bereits 2004 vorgestellt, die ersten µCs damit
>> könnten von Luminary Micro gewesen sein
>
> Um die ist es wirklich schade, die hatten Ethernet noch komplett intern.
> Nur noch den Magjack dranpappen, fertisch.

Gibts jetzt wieder:

http://www.ti.com/product/msp432e401y

fchk

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nette Idee, ARM-µCs als renovierte MSP430 zu tarnen. ;-)

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lothar schrieb:
> Das ist falsch. Ohne Linux geht problemlos:
...
> https://github.com/PeterLemon/RaspberryPi/blob/mas...

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.

Autor: Pegge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pegge schrieb:
> Das stimmt allerdings. Als Jungspund vergisst man das oft.

Wenn wirklich Jungspund, dann biete dich als PC/Handy-Supporter für 
jemanden aus der Familie an, der altersmässig zu Ü70 passt. Dann 
vergisst du das nicht mehr, ganz besonders nicht bei Ü90. ;-)

: Bearbeitet durch User
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Dokumantation ihres Krempels im PDF Format zuwege zu bringen

Die BASIC Doku wurde erst am 04.11. komplett renoviert.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven D. (sven_la)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Die BASIC Doku wurde erst am 04.11. komplett renoviert.

Wo finde ich dieses BASIC? Bitte poste einen Link.

Autor: Lothar (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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"

Beitrag #5214712 wurde von einem Moderator gelöscht.
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte ich noch vergessen: Ein Online-Manual gibt es auch z.B.

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

Beitrag #5214730 wurde von einem Moderator gelöscht.
Beitrag #5214815 wurde von einem Moderator gelöscht.
Beitrag #5214881 wurde von einem Moderator gelöscht.
Beitrag #5214925 wurde von einem Moderator gelöscht.
Autor: Olaf (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Mit dem R8C. 16-Bit Architektur. Völlig andere Linie.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-R8C...
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 ;-)

Beitrag #5215054 wurde von einem Moderator gelöscht.
Beitrag #5215071 wurde von einem Moderator gelöscht.
Beitrag #5215078 wurde von einem Moderator gelöscht.
Beitrag #5215194 wurde von einem Moderator gelöscht.
Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> 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.

So weit ich das noch im Kopf habe, hat MS irgendwann mit Windows CE 6 
die Unterstützung von MIPS und SH eingestellt. Übrig blieben ARM und 
x86.

>> 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.

Da müssten mal die übriggebliebenen SH4s gegen aktuelle M7 wie den i.MX 
RT1050 (600 MHz Cortex M7) getestet werden. Beim Coremark liegen die RX 
auf M7-Niveau

> 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
bzw.
http://www.renesasshop.com/synergy
oder DigiKey und Mouser, die z.T. auch genügend Controller auf Lager 
haben. Die RX111 sind u.U. vielleicht für den TO interessant, da es die 
mit bis zu 64-Pins im lötfreundlicheren TQFP mit 0.8mm Pitch gibt ;)

> 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.

So neu sind nur die Synergys, die RZ gibt's länger und mit ARM 
kooperiert Renesas seit 2003... 
https://www.renesas.com/en-us/about/web-magazine/e...

> 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.

Volle Zustimmung. Gilt ebenso für die Synergys mit M4 und M0-Kern.
Bei anderen Controller-Hersteller könnte man auf die Idee kommen, dass 
sie an Leiterplatten-Herstellern und EMV-Laboren beteiligt sind...
Das einzige, was mich etwas stört (RX und Synergy): HiSpeed-USB gibt's 
nur ab 176-Pins aufwärts und nur bei den S5, S7 und RX71M. Zudem könnte 
Renesas mal ihre Webseite überarbeiten und bspw. überall gleich 
dazusagen, was die SCIs je nach Modell können u.a. Simple SPI und I²C, 
Smart Card und bei den RX71M auch LIN (die RX65x kämen dann auf 11x SPI 
oder I²C + 3x I²C + 3x rSPI + 1x QuadSPI)

Autor: m.n. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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-Microcontrolle...) 
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 ;-)

Beitrag #5215362 wurde von einem Moderator gelöscht.
Autor: Christopher Johnson (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe schrieb:
> 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.

Es gibt auch direkt von ST Nucleo-Boards im Bluepill-Format, z.B. 
Nucleo-L432KC. Da ist auch gleich ein Debugger mit drauf, d.h. USB-Kabel 
anschließen und los gehts. Kostet in der Bucht 19€ inkl. Versand und bei 
Mouser oder RS gibt es die für 9-10€ zzgl. MwSt.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Olaf schrieb:
> 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.

FYI: Die einen hassen ihn, die anderen lieben ihn: den GCC. Mit den 
R8C/M16C tut der sich etwas schwer. Der hat wohl was dazu drin, aber die 
Architektur gibt das nicht wirklich her, zu wenig Register. Das war für 
mich ein Argument, diese mit R8C,M16C,M32C etwas verwirrend benannte 
Familie zu ignorieren.

Beitrag #5215572 wurde von einem Moderator gelöscht.
Beitrag #5215998 wurde von einem Moderator gelöscht.
Beitrag #5216777 wurde von einem Moderator gelöscht.
Beitrag #5216816 wurde von einem Moderator gelöscht.
Beitrag #5216871 wurde von einem Moderator gelöscht.
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Letztendlich ist das die einzige Prozessorarchitektur für grosse
> Serversysteme, die es geschafft hat, der Intel/AMD Übermacht zu trotzen

Fast. Die IBM 360 Mainframes aus den 60ern werden immer noch 
weiterentwickelt, heute z Systems genannt. Eigene Marktnische, 
spezialisiert auf sehr geringe Downtime. Zwischen den z Systems und den 
grossen p Systems (Power) gibts es Synergieeffekte im Systemaufbau.

: Bearbeitet durch User
Beitrag #5216953 wurde von einem Moderator gelöscht.
Beitrag #5216967 wurde von einem Moderator gelöscht.
Beitrag #5216984 wurde von einem Moderator gelöscht.
Beitrag #5217005 wurde von einem Moderator gelöscht.
Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Markus F. schrieb:
>> Letztendlich ist das die einzige Prozessorarchitektur für grosse
>> Serversysteme, die es geschafft hat, der Intel/AMD Übermacht zu trotzen
>
> Fast. Die IBM 360 Mainframes aus den 60ern werden immer noch
> weiterentwickelt, heute z Systems genannt. Eigene Marktnische,
> spezialisiert auf sehr geringe Downtime. Zwischen den z Systems und den
> grossen p Systems (Power) gibts es Synergieeffekte im Systemaufbau.

Wobei wir fast wieder beim Thea "ARM" wären, denn wer mal auf 
Assembler-Ebene mit einer /360(,/370,/390,z) zu tun hatten, der hat 
manches ARM-typische ("Branch AND Link", keine absoluten Adressen, 
sondern alles relative zu einem (oder zwei) Register(n)) schon mal 
gesehen.
Die Gehäusegröße ist nur nicht mehr ganz DIP ;-)

: Bearbeitet durch User
Beitrag #5217073 wurde von einem Moderator gelöscht.
Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Jaein. Du kannst dir den gcc einfach wie fuer jedes andere Zielsystem
> uebersetzen und nutzen.

GCC setzt bestimmte Eigenschaften eines Targets voraus. Eine 
ausreichende Anzahl Register beispielsweise. Hat man die nicht, muss man 
auf Pseudo-Register im RAM ausweichen, also dem Compiler mehr Register 
vorspiegeln, als das Target hat. Eine Methode, die ich als Notlösung 
betrachte.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Olaf schrieb:
> Das ist aber natuerlich ein bizarrer Vorwurf weil die AVRs 2005 soviel
> Flash (oder gar Ram) garnicht hatten.

Hust, hust … den ATmega103 gab es zumindest schon 2001, der ATmega128
folgte kurz darauf.

Allerdings konnte man deren 128 KiB Flash natürlich im GCC damals nur
benutzen, weil sie als 64 KWorte adressiert werden.  Trampolines für
volle Unterstützung des ATmega2560 gab's erst 2005.  Allerdings sehe
ich sowas auch heute noch eher kritisch: man hätte bei 128 KiB Flash
und 64 KiB RAM aufhören sollen, denn programmiermäßig ist alles darüber
ziemlicher Mist.  Danach wäre 32 Bit mehr als sinnvoll gewesen.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Beitrag #5217175 wurde von einem Moderator gelöscht.
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Allerdings konnte man deren 128 KiB Flash natürlich im GCC damals nur
> benutzen, weil sie als 64 KWorte adressiert werden.

Die Codierung der M16C ist ein Bytestream, d.h. die direkte 
Adressierbarkeit von Code ist auf 64KB begrenzt. Während AVRs durch die 
Wortadressierung auf 128KB kommen.

Ist aber ein weiterer Punkt, der mit bei den M16C missfiel: Die 
Adressraumtrennung. Die haben einen 1MB Adressraum, mit 64KB RAM/IO 
unten eingebettet. Nur bei kleinen R8C liegt das Flash auch in diesen 
64KB, erlaubt also prinzipiell eine Datenadressierung vom Flash mit 
normalen Pointern. Bei den anderen gibts genau den gleichen Zirkus wie 
bei AVR. Da ich bereits LPC2000 verwendete, waren die Renesas auch 
deshalb keine Option.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Olaf schrieb:
> Weisst du, das weiss ich garnicht. :-)
> Ich nutze halt den Compiler und er macht was er soll.

Ich bin da historisch etwas vorbelastet, weshalb ich gerne mal 
reinschaue, wie der Compiler die Dinge sieht. Und ich kann es mir 
mangels kommerziellen Interesses leisten, ästhetische Aspekte stärker 
mit einzubeziehen.

> Also wuerde ich mal sagen solange man kein Compilerentwickler ist,

War ich mal, weshalb ich die Umsetzbarkeit von C in Maschinencode 
automatisch im Auge habe, wenn ich eine Architektur sehe.

Es half auch nicht wirklich, dass die damalige Implementierung in GCC 
indirekte Sprünge über statischen Zwischenspeicher im RAM 
implementierte. Eine Tretmine, die bei indirekten Sprüngen in Interrupts 
scharf wird und jedes RTOS aus der Kurve schmeisst. Das ist allerdings 
nicht der Maschine anzulasten, sondern nur der Implementierung.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Die Codierung der M16C ist ein Bytestream, d.h. die direkte
> Adressierbarkeit von Code ist auf 64KB begrenzt.

s/direkte/indirekte/, also über normale Pointer, ohne auf Tricks 
zurückgreifen zu müssen. Bezogen auf einen GCC Stand, der noch nicht mit 
Adressräumen umgehen konnte.

: Bearbeitet durch User
Beitrag #5217860 wurde von einem Moderator gelöscht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.