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
:
Gesperrt durch Moderator
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.
Die Atmel - pardon - Microchip SAMD10 (M0+) gibt es zumindest in SOIC.
:
Bearbeitet durch User
Warum nicht so etwas: https://www.aliexpress.com/wholesale?catId=0&initiative_id=&SearchText=stm32f103c8t6+board Cortex-M3, und viel mehr als der Controller und zwei Quarze sind da nicht drauf. Alles mit bastelfreundlichen 2.54mm-Raster. Die meisten Pins sind frei verfügbar (bis auf ...). Generell gibt's bei der STM32-Familie viel mehr Auswahl bei solchen "minimum boards" als bei den LPC oder Kinetis. Warum auch immer ...
A. B. schrieb: > Warum nicht so etwas: > https://www.aliexpress.com/wholesale?catId=0&initiative_id=&SearchText=stm32f103c8t6+board 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.
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.
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.
Uwe schrieb: > Ich möchte mich an meinem Lebensabend mit den Arm-Cortex Controllern > beschäftigen, entweder M0(+) oder M3, Warum diese Einschränkung? Ein M4F ist auch was Nettes. Ich hätte dir da eine ganz andere Herangehensweise vorgeschlagen, nämlich nach Gehäusegröße. Wenn du eher nur kleinere Dinge damit machen willst, dann guck nach Chips im 48 bis 64 pinnigen Gehäuse, gestalte dir eine Minimalst-Leiterplatte dazu, laß diese im Dutzend in China anfertigen und gib dir einmal die Mühe, deine Chips nebst Quarz, Spannungsregler und Programmieranschluß auf diese LP zu kriegen, dazu eine Basisversion einer Firmware, die dem Teil erstmal Leben einhaucht. Dann hast du eine nette Basis für all deine Betätigungen. Vorschläge meinerseits: STM32xxx = häufig hier beredet, Bootlader, gute Dokumentation, aber Peripherie zum großen Teil nur 16 bittig. LPCxxxx = hier seltener besprochen, gleiche Liga wie STM32, Bootlader, gute Dokumentation und die Peripherie ist fast durchgängig 32 bittig. Nuvoton = hier ziemlich ignoriert, dennoch beachtenswert. kein Bootlader, also JTAG/SWD, aber es gibt dort M4F auch in kleineren Gehäusen (M452LC3AE, 48 Pin, etwa 70 MHz) und zu friedlichen Preisen. Haben nen Internetshop. Also: guck dir etwas mit Weitblick aus, habe keine Scheu vor dem Löten, mach dir zu allererst Moduln wie oben beschrieben, mit denen kannst du später bequem leben, wenn der Tatterich zunimmt. W.S.
Danke Dir Stefan! Du hast sehr schöne Alternativen aufgezeigt. Blue Pills Boards scheiden aus, denn das wäre dann nicht zu 100% mein Werk, das sieht mir zu sehr nach Experimentierbaukasten, Jugend forscht aus, da bin ich sehr eitel. Aber deine weitere Poweridee mit der preiswerten Heißluftlötstation werde ich weiter verfolgen! Das bedeutet doch, da ist Lötpaste auf den Pads, die dann schmilzt, und Kurzschlüsse dürften dann selten auftreten mit dem Verfahren, denn man braucht auch keine ruhige Hand? Beste Grüße, Uwe
Danke Detlev, die SAM D10 haben Charme! 14- und 20 polige SOICs mit 1.27 mm Pinabstand klingt ja recht entspannt. 16 Kb Flash max. ist zwar nicht der Brüller, aber meine 6 Kb AVR Code bekomme ich da locker rein! Beste Grüße, Uwe
Danke Johannes für deine Tipps! Das Ding schaue ich mir an, klingt gut, denn 1.27 mm Pinabstand sind recht entspannt, und die Technik hört sich gut an. ich lade mir sofort das Datasheet runter! Beste Grüße, Uwe
Hey Namensvetter, Du solltest vor dem Löten keine Angst haben, das geht unglaublich gut, wenn man den Dreh erst mal raus hat. Für Heißluft brauchst Du übrigens auch eine ruhige Hand beim Platzieren des vielpinnigen Teils. Schnapp Dir ein paar alte Motherboards, Festplattencontroller ö.ä. und löte an denen herum. Mit Heißluft (einstellbare Baumarktheißluftpistole reicht) ablöten und dann mit Lötkolben wieder auflöten. Entscheidend ist das Flußmittel, ein guter Lötkolben und ev. bei alternden Augen eine Kosmetikerlupenleuchte, dann lötest Du TQFP oder TSSOP ohne größere Anstrengungen. Lag Dir das von einem deutlich Ü50 glaubhaft versichern. ;-)
Hallo W.S.! Warum nicht gleich mit der Arm-Cortex A- oder R- Serie einsteigen? :-) Spaß beiseite, denn selbst die M0 uCs sind schon recht komplex. Die Zeiten wie beim AVR, wo man sich mit einem guten Rotwein dabei einarbeitet, sind vorbei. Aber als übernächster Schritt wäre das durchaus eine gute Idee. ich möchte nämlich einen Technikschock vermeiden. Deine Vorgehensweise ist gut. STM scheidet bei mir aus, weil wohl Code im Flash mit vielen Waitstates ausgeführt wird, diese Probleme kenne ich nicht bei XP, (LPCs) daher für mich eine höhere Liga.Nuvoton habe ich nie gehört, schaue ich mir an! ja, ich sehe schon, ran an den Lötkolben ist hier die Devise, ich werde Euch folgen, Ihr habt mich ermutigt! Wobei Heißluftlötkolben fasziniert mich.... Beste Grüße, Uwe
Uwe schrieb: > 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.
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
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
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.
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
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
> Dem Verfahren mit dicken Lötkolben und dann Entlöten mit Entlötlitze > traue ich nicht! Das kann ich verstehen. Das ist zwar grundsaetzlich kein Problem, aber soetwas setzt eine gewisse Routine vorraus. Aehnlich wie Fahrradfahren oder schwimmen. Man kann nicht davon ausgehen das es beim erstenmal klappt und als privater Kleinbastler macht man das ja nicht jeden Tag. > Versionen, die heute noch produziert werden, zumal ich gelesen hatte, > die Chinesen verlöten diese noch in Massen? Ich finde es immer wieder erstaunlich was hier fuer Vorurteile gegenueber China bestehen. Alles was da in Stueckzahlen laeuft ist dort genauso professionell wie bei uns, vielleicht sogar noch professioneller weil die Stueckzahlen groesser sind. Oder glaubt hier einer ernsthaft euer neues Iphone wird von Tante Hu ueber dem Kohlenfeuer geloetet? Und bei kleinen Buden sitzen dann viele Maedchen und loeten mit dem dicken Loetkolben. Aber die machen auch drei SMD-ICs pro Minute weil sie das jeden Tag 10h machen. Wenn du es wirklich nicht selber loeten willst dann wuerde ich mir Adapterplatinen mit bereits aufgeloeteten ICs kaufen. Oder steck dir einfach ein ganzes Demokit von ST auf deine eigene Platine. Allerdings wuerde ich dir empfehlen dir ein Mikroskop zu kaufen und etwas zu ueben. Und zwar weniger wegen dem Microcontroller. Es gibt heutzutage auch jede Menge interessanter neue ICs die man als Bastler auch verwenden will und die sind auch alle SMD. Oder willst du neben deinen schicken neuen ARM einen LM324 packen? Wo bleibt denn da der Sinn fuer Aesthetik? :-) Olaf
Hallo Detlev! Also mit dem SAMD10 hast du mir ja einen Wahnsinnstipp verpasst, danke nochmals! Kostet als Einzelstück in der 16 Kb Version knapp ein Euro, dafür bekomme ich keinen ATMEGA, hat sogar 12 Bit ADC on board. Auf den habe ich mich eingeschossen! Wenn du mir abschließend einen guten Programmer/Debugger dafür empfehlen kannst (taugt der Atmel ICE etwas)?? Dankbare Grüße, Uwe
Hallo Jojo! Also mit dem Druckluft Dispenser erledigt sich langsam, wenn neben mir auch noch ein Kompressor am röhren ist! :-) Einigen wir uns auf die quick und dirty Methode, alle Pins miteinander zu verlöten, und dann die Kurzschlüsse rückgängig machen mit Entlötlitze. Dein empfohlenes Video lade ich mir runter! Hast du dabei eine vergrößernde Brille auf mit etwa 5 fach?? Als Jahrgang 60er habe ich auch nicht mehr die Adleraugen wie früher meine Laborassistenten, die 0.5 mm Pitches sogar teilweise ohne Lupe eingelötet haben. Wie schon gesagt, mit dem LPC812 hat sich erledigt, no ADC....... Allerdings wage ich es mal, dir kräftig zu widersprechen: Mit Alkohol im Blut wird die Hand viel ruhiger! :-) Beste Grüße, Uwe
Hallo Jojo!! Habe mir dein empfohlenes Video runtergeladen und angeschaut, sehr gut! Wieso der nur einen einzigen Kurzschluss gebaut hat, ist mir ein Rätsel, eine Hammerleistung! Ob es daran liegt, daß durch das Flussmittel das Lot dünnflüssiger wird und daher schneller zerläuft? Egal, ich probiere es aus, langsam macht mir das Thema Spaß, wenn ich hier so Eure Einstellungen sehe! BG Uwe
Hallo Olaf! Es geht mir weniger um Ästhetik, sondern um Bastlerromantik! Ich möchte die SMD Technik nicht schlecht reden, schließlich ist ihr EMV Verhalten um Welten besser als bei bedrahteten Bauteilen. Ich habe viele Jahre EMV Messungen und Optimierungen gemacht, daher schätze ich schon die SMD Technik sehr, von den niedrigen Bestückungskosten ganz abgesehen. Aber: An 0.5 mm Pitches zu messen, macht keinen Spaß mehr, schnell kann man mit der Messpitze einen Kurzschluss bauen oder man verzählt sich bei den vielen Pins. Auch mit einer großen Lupe zu arbeiten finde ich nicht so toll. Das nenne ich nicht entspannte Bastlerromatik!Ich werde daher den Mix aus SMD Controller und bedrahteten Bauteilen machen. Sieht vielleicht nicht so toll aus, will aber damit auch nicht ins Kunstmuseum! :-) In diesem Sinne herzliche Grüße, Uwe
Uwe schrieb: > mit dem LPC812 hat sich erledigt, no ADC Hat aber 2x 5-Bit Komparatoren. Für ein Poti reicht 5-Bit ADC und falls nicht kann man damit auch einen 10-Bit SAR ADC in Software bauen. for (n=VOLTMAX; n>0; n--) { COMPLAD_bit.LADSEL = n; if (COMPCTRL_bit.COMPSTAT) { d = n; break; } }
Wir nehmen schon lange für kleinere Inhouse Serien solche Boards: https://www.waveshare.com/product/mcu-tools/stm32/core407i.htm
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
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.
> Versionen, die heute noch produziert werden, zumal ich gelesen hatte, > die Chinesen verlöten diese noch in Massen? Ich mache SMD natuerlich beruflich, aber privat genauso. Und zwar weil es besser ist. Ueberleg mal wie einfach und schnell du fette Schaltungen auf Lochraster werfen kannst. (Loecher in der Mitte teilen) Oder das man Platinen nicht mehr bohren muss. Keine Draehte abschneiden. Und richtig, die Teile kosten nichts. Und nehmen auch kein Platz weg. Du kannst in 0603er praktisch alles zuhause rumliegen haben. Klar, man muss einmal 20-30Euro fuer ein Mikroskop ausgeben. (Bresser Junior) Aber das lohnt sich. Und zum messen lötest du einfach einen Draht an. Das ist auch kein Problem. Und für viele moderne Bauteile einfach unverzichtbar. (z.B Schaltregler) Olaf
Uwe schrieb: > Wie schon gesagt, mit dem LPC812 hat sich erledigt, no ADC....... ADC haben die LPC82x oder der 845, aber da sind wir wieder bei 0,5 mm Pitch oder LQFP. Wobei ich eher an der Technik feilen würde sowas doch löten zu können, SMD machen wirklich Freude und die Auswahl an Kandidaten wird um einiges grösser wenn man 0,5 oder 0,65 mm noch einbezieht. Ich habe noch eine Lupenleuchte von Pollin, nicht das Optimum und ein Stereomikroskop steht schon auf der Wunschliste, aber im Moment sind die Prioritäten anders gesetzt. Flussmittel wie FL-22 (Gel) oder FL-88 (flüssig) erleichtert das Ganze jedenfalls deutlich. Für SMD habe ich mir dieses Set gegönnt, da sind feine Spitzen drin und die sind sehr hilfreich : https://www.reichelt.de/Pruefmittel-Sets/PMS-0-64/3/index.html?ACTION=3&LA=2&ARTICLE=63480&GROUPID=5619&artnr=PMS+0%2C64&SEARCH=%252A Alternativ könnte man sich die aus Pogo Pins bauen, gibts beim Chinesen sehr günstig.
Johannes S. schrieb: > ADC haben die LPC82x oder der 845 Hier ist es aber wieder so, wenn es hauptsächlich um ADC/DAC geht: Der LPC845 hat 12-bit ADC und 2x 10-bit DAC bei 30 MHz und kostet 2 EUR im LQFP-48. Ein EFM8LB mit 14-bit ADC und 4x 12-bit DAC und 72 MHz kostet 1.50 EUR im QFP-32 was wesentlich einfacher zu löten ist. Das ist zwar ein 8051 aber langsamer als der M0+ ist der nicht. Hat zudem DMA
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.
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-Lagerkasten-mit-60-Behaeltern?utm_campaign=gs 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.
Jörg W. schrieb: > Könntest du mal bitte dein ewiges Evangelisieren belassen? Ich habe doch selber LPC im Einsatz und dem Frager geschrieben dass er zwar recht hat: Uwe schrieb: > Der LPC81X hat leider keinen ADC Es aber trotzdem geht und er sich den also mal ansehen kann: Lothar schrieb: > Hat aber 2x 5-Bit Komparatoren
Hallo Uwe, da immer mal wieder ein Mikroskop als Arbeitshilfe genannt wird, will ich mal ergänzen. Es gab - gibt? - bei Pollin sehr preiswerte USB-Mikroskope. Da hast du ein gestochenes Bild von deinen Bauteilen auf Bildschirmgröße vor dir. Mit einem Stativ kannst du dann sogar dabei löten. Ist natürlich etwas gewöhnungsbedürftig, aber seit ich das Ding habe, brauche ich keine Lupe oder Lupenleuchte mehr. Gruß Rainer
Danke für diesen hervorragenden Tipp Rainer!!! Löten unter einem 28" "Mikroskop" ist fast schon dekadent, aber Klasse!!! :-) Da fällt mior doch glatt ein, ich habe so ein Bresser Mikroskop mit elektronischem Okular (Webcam) im Keller liegen...... BG Uwe
guest...Rainer schrieb: > Hallo Uwe, da immer mal wieder ein Mikroskop als Arbeitshilfe > genannt > wird, will ich mal ergänzen. Es gab - gibt? - bei Pollin sehr preiswerte > USB-Mikroskope. Da hast du ein gestochenes Bild von deinen Bauteilen auf > Bildschirmgröße vor dir. Mit einem Stativ kannst du dann sogar dabei > löten. Ist natürlich etwas gewöhnungsbedürftig, aber seit ich das Ding > habe, brauche ich keine Lupe oder Lupenleuchte mehr. Gruß Rainer Hi Rainer, Damit kannst du arbeiten? Ich habe die gleiche Idee gehabt und muss sagen, dass das für mich überhaupt nicht funktioniert hat. Die USB-Geräte haben nämlich eine Latenzzeit. Man bewegt die Hand und es dauert eine Weile bis sich das auf das Bild überträgt. Für feinmotorische Arbeiten sehr störend. Ich kann also aus persönlicher Erfahrung nur von USB-Mikroskopen zum Löten abraten. Ich habe mir dann ein günstiges Stereomikroskop gekauft. Das funktioniert super.
Uwe schrieb: > Warum nicht gleich mit der Arm-Cortex A- oder R- Serie einsteigen? :-) Übertreib nicht. So, zu der Komplexität: Die ist aus unserer Sicht eigentlich nicht in der CPU angesiedelt, sondern in der Peripherie. Da nehmen sich M0, M3 und M4 und M4F fast garnix. Was die STM32 betrifft, so soll man die nicht in Bausch und Bogen verdammen, denn gerade bei den "besseren" Typen erfolgt der Flashzugriff nicht 16 bittig, sondern m.W. bis zu 64 bittig. Da relativieren sich die Waitstates, weil sie sich auf mehrere Befehle verteilen. Die zumeist nur 16 bittige Peripherie ist hingegen oftmals ein viel größeres Ärgernis. Nach 32 Bit breiten Timern muß man wirklich suchen und wenn du dir mal die Kapitel über SAI, I2S und SPI anschaust, dann kommt dir das Grausen über das Gehampel, das man machen muß, um 32 Bit Daten über die 61 Bit Peripherie zu schleusen. Das Gleiche gilt für den USB, aber da bin ich durch, meinen USB VCP kannst du hier im Forum finden. Gut ist, daß man gerade den STM32F103C8T6, der auf den Bluepill-LP drauf ist, beim freundlichen Chinesen spottbillig findet. Ich hab davon schon mehrere Dutzend für je etwa 1.10€ gekauft. Ein Problem ist der Versand, denn diese chinesischen Nachbauten haben recht dünne Beinchen und sie werden zumeist quasi lose versendet. Da ist vorsichtiges Geraderichten angesagt. Aber we gesagt, für's Pensionärsdasein rate ich dir eher zu einem M4F, eigener LP und dazu einem mittelkleinen Monochrom-Grafikdisplay, so etwa 128x64, dazu wenige Tasten und ein Drehgeber sowie nen seriellen und nen USB Anschluß - weil man ja in aller Regel auch ein bissel Hände und Füße an seinem Spielzeug braucht. Was das Löten betrifft, so kann ich dir von all dem Heißluft-Gerede erstmal nur abraten. Mach es mit nem Lötkolben und nicht zu feiner Spitze. Sie sollte meißelförmig sein und nicht spitz wie ein Florett. Dazu ausreichend viel Kolophonium. Ich hatte neulich schon mal jemandem ne Art Checkliste geschrieben, wie es mit dem Löten geht. War damals wegen FPC-Steckverbinder im RM0.5. W.S.
Bülent C. schrieb: > Google mal nach s64dil reusch Erledigt, danke für den Tipp! http://reusch-elektronik.reworld.eu/de/produkte/s64dil-476/right.htm Das ist ja ein überaus nettes Teil, nur leider ziemlich chaotisch beschrieben (der verlinkte Schaltplan ist für ein anderes Modul (F476 vs. L476). Man kann den DFU-Bootloader angeblich löschen? Ist VDD = VCC = 3.3V?).
Hallo Berti! Dein SAMD21 bietet zwar keine komfortablen 1.27 mm Pinabstände, die man noch mit einer Flasche Bier in der Hand löten kann, sondern bestenfalls als 32 Pinner 0.8 mm Anstand, was aber immerhin deutlich besser ist als 0.5 mm. Ich habe mir ein Datasheet von dem interessanten Ding mal gespeichert, denn sollten 16 Kb Flash nicht ausreichen, wäre dein Typ eine logische Fortsetzung, daher danke für die Empfehlung!
Du hast sowohl 5V, wenn du vom USB einspeist, als auch 3v3 auf den rausgeführten pins.
W.S. schrieb: > Ich hatte neulich schon mal jemandem > ne Art Checkliste geschrieben, wie es mit dem Löten geht. War damals > wegen FPC-Steckverbinder im RM0.5. das war für mich in dem Thread den ich hier eröffnet hatte: Beitrag "FPC Verbinder mit 0,5 mm Pitch löten" Aber der FPC Connector ist wegen der Pinform sehr schwer zu löten, kein Vergleich mit den 0,5 mm IC Beinchen, also davon nicht beunruhigen lassen.
Pegge schrieb: > Hi Rainer, > > Damit kannst du arbeiten? Hallo, ja und doppelt ja. Bei meinem Teil, dass wir seinerzeit auch in der Firma im Prüffeld eingeführt haben, ist keine Verzögerung festzustellen! Und du kannst das Bild jederzeit speichern und hast damit auch schlechte Lötstellen u.ä. bequem dokumentiert. Ich sage ja, dass mit einem "gebastelten" Halter und ein wenig Übung das Löten auch bei 0.5Pitch ein Spaziergang ist. Gruß Rainer
Uwe schrieb: > Ich möchte mich an meinem Lebensabend mit den Arm-Cortex Controllern > beschäftigen, entweder M0(+) oder M3 Schön. Aber ohne konkrete Anwendung, die diese Controller wirklich erfordert? Ich wüsste ohnehin gerne mal, wieviele solcher Fragensteller es tatsächlich bis zur Beherrschung und dem produktiven Einsatz solcher Powercontroller bringen. Ich vermute, es ist ein verschwindender Bruchteil.
Rudolph schrieb: > Uwe schrieb: >> Ich möchte mich an meinem Lebensabend mit den Arm-Cortex Controllern >> beschäftigen, entweder M0(+) oder M3 > > Schön. Aber ohne konkrete Anwendung, die diese Controller wirklich > erfordert? Ich wüsste ohnehin gerne mal, wieviele solcher Fragensteller > es tatsächlich bis zur Beherrschung und dem produktiven Einsatz solcher > Powercontroller bringen. Ich vermute, es ist ein verschwindender > Bruchteil. Wenn man die in c programmiert, geht das an einem Nachmittag.
Guten Abend Rudolph! Es gibt schon eine sehr konkrete Anwendung, mit der ich mich seit Monaten beschäftige, das Gegenstromladen von Ernst Beer, erfunden 1954. Eine geniale Erfindung, leider weitgehend in Vergessenheit geraten. Ich wende sie seit etwa 15 Jahren an zum Laden von Akkus, die es mir mit einer langen Lebensdauer bisher gedankt haben trotz so mancher Überladung bei NiMh und Pb. Bis vor wenigen Monaten habe ich die Ströme durch Halogenlampen begrenzt, was eine einfache Methode ist. Da ich ziemlich viel Zeit habe, dachte ich mir, das automatisiere ich mal mit einem schnellen AVR ATMega, der mit 18.432 MHz gehetzt wird. Dennoch brauchte dieser beim Durchrechnen einer Entladeformel mit 4 Multiplikationen und einer Division bei 32 Bit Operationen anfangs 200 us. Wenn als Ergebnis nach 200 us herauskommt, nach 100 us hätte der Entladestrom schon abgeschaltet werden müssen, dann hat man schon verloren. Zwar konnte ich durch einige Optimierungen des Algorithmuses zu Lasten der Lesbarkeit des Codes die Rechenzeit auf 110 us verringern, dennoch stehe ich bei kleinen Ladeströmen, die ich momentan vermeide, am Anschlag. Natürlich wird eine CPU mit 32 Bit ALUs solche 32 Bit Operationen mindestens um den Faktor 10 schneller rechnen. Kurzum, bei 32 Bit Operationen brechen die Achtbiter brutal ein, da lohnt sich durchaus so eine Kanone. Es gibt aber auch noch einen zweiten Grund: Wenn mittlerweile so ein 32 Bit Geschoss preiswerter ist als 8 und 16 Bit Technik, und bietet genug Reserven, dann sollte man die Flotte auf 32 Bit ARMs umstellen, eine Tendenz, die ich seit paar Jahren beobachte. Oder würdest du beim Autokauf eine 75 PS Maschine nehmen, wenn man dir 250 PS billiger anbietet? Gruß Uwe
Hallo Pegge! Also wenn die Datasheets der einfachen ARM-Cortex uCs schon 900 Seiten umfassen, die AVRs etwa nur ein drittel, dann wird man so ein komplexes Ding nicht an einem Nachmittag in C hardwarenah programmieren! Dafür bietet es zu viele Möglichkeiten. Auch wird man Schwachpunkte entdecken in der Hardware, die aufhalten. So war es beim AVR, wenn man versucht, mit den angegebenen 1.1 V Referenzspannung genaue ADC Ergebnisse zu erhalten. Da vergehen schon einige Nachmittage inklusive Hardwareänderung. Gruß Uwe
Hallo Uwe, nachdem Du eine plausible, rechenintensive Anwendung genannt hast will ich Dich mal ausdrücklich aus meiner pessimistischen Einschätzung ausnehmen. Denn Pegge schrieb: > an einem Nachmittag ist es mit der Einarbeitung in Entwicklungsumgebung, Architektur und Bibliotheken gewiss nicht getan, daß verlangt schon nach einer (solchen) guten Begründung.
Uwe schrieb: > Also wenn die Datasheets der einfachen ARM-Cortex uCs schon 900 Seiten > umfassen, die AVRs etwa nur ein drittel, dann wird man so ein komplexes > Ding nicht an einem Nachmittag in C hardwarenah programmieren! Du kannst aber doch nur die Peripherie ansehen, die Du wirklich programmieren willst. Also wenn Du z.B. beim LPC einen Timer brauchst, dann schaust Du Dir die Beschreibung vom MRT Timer an. Der ist einfacher als jeder AVR Timer. Und wenn Du State-Machine Sachen machen willst, siehst Du Dir den SCT Timer an. Der ist so kompliziert, dass es dazu sogar ein zusätzliches Manual gibt: https://community.arm.com/iot/embedded/f/discussions/3723/what-s-the-big-deal-in-nxp-s-sctimer
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
> Also wenn die Datasheets der einfachen ARM-Cortex uCs schon 900 Seiten > umfassen, die AVRs etwa nur ein drittel, dann wird man so ein komplexes > Ding nicht an einem Nachmittag in C hardwarenah programmieren! Ja und nein. Alle Microcontroller werden ja heute in C programmiert. Es ist daher vollkommen egal ob man einen dummen kleinen AVR oder was richtiges wie einen SH2 oder grossen ARM programmiert. Man merkt es schlicht nicht. Die Datenblaetter haben deshalb soviele Seiten weil in den grossen Microcontrollern auch sehr viel mehr Peripherie drin ist. Aber du musst ja nur das lesen was du gerade nutzt. Und wenn man beim kleinen AVR nur die RS232 genutzt haette dann nutzt du beim fetten Teil eben auch nur die RS232. Es kann Unterschiede geben, aber die liegen dann eher am Hersteller und wie er die Peripherie gestaltet. (z.B ist I2C beim STM32F103 eine Katastrophe) In der Praxis kann es trotzdem komplizierter werden. Dafuer gibt es aber zwei andere Gruende. 1. Die Entwicklungsumgebung. Da ist ja heute in der Regel Eclipse oder eine Abart davon ueblich. Das ist ein hoellenkomplexes vollkommen unlogisch zusammengeschustertes Etwas. Damit kann man viel Spass im negativen Sinne haben. 2. Die Faulheit der Nutzer. Die meisten Anfaenger sind heute zu faul oder zu bloed etwas lernen zu wollen. Es ist ueblich geworden sich Source aus dem Internet zusammenzustehlen. Am Ende hat man dann ein untotes Gebastel wo keiner mehr genau weiss was darin passiert. Das gab es so bei kleinen Controllern mit 8kFlash und 128Byte Ram nicht. Einfach weil nicht genug Platz war um die ganzen Fehler einzubauen. :-) Dafuer haben fette Controller aber auch Vorteile. Du hast genug Platz um vernuenftig zu programmieren. Du hast immer noch eine serielle uebrig um dort Fehlerzustaende auszugeben. Es gibt sehr leistungsfaehiger Debugger. Man muss das nur nutzen. Dann machen solche Controller viel mehr Spass. Ich wuerde privat jedenfalls auch immer einen fetten Controller verwenden. Was interessiert mich ob der 2Euro mehr kostet? Ich wuerde sogar einen moeglichst fetten nehmen und denn dann fuer alle privaten Projekte verwenden damit man nicht immer unterschiedliche Typen fuer Projekte mit der Stueckzahl 1 hat. .-) Und noch was. USB-Mikroskope sind im Prueffeld okay, aber zum loeten sind sie unbrauchbar. Weil sie nicht Stereo sind. Ohne 3D-Sehen kann man seine Haende nur so ungefaehr positionieren. Wie soll das klappen wenn man etwas tut was sowieso bereits an der Grenze der menschlichen Faehigkeiten liegt? Ich hab gerade einen defekten Cortex M4 im DFN64 Gehaeuse mit 0,5er Pitch auf einer beidseitig voll bestueckten Platine gewechselt. Das will ich mal sehen wie ihr das mit USB-Mikroskop macht. Olaf
Uwe schrieb: > Es gibt schon eine sehr konkrete Anwendung, mit der ich mich seit > Monaten beschäftige, Dann nimm doch einfach ein Discovery-Board, mit dem Du ohne große Löterei gleich loslegen kannst. Danach kannst Du besser beurteilen, was Du tatsächlich brauchst. > Oder würdest du beim > Autokauf eine 75 PS Maschine nehmen, wenn man dir 250 PS billiger > anbietet? Das ist kein Argument! Ich gehe davon aus, daß der stärkere Motor einen höheren Verbrauch hat - insbesondere, wenn man im Stau steht. Für den Gang zum Bäcker reicht auch ein Fahrrad.
Uwe schrieb: > Es gibt schon eine sehr konkrete Anwendung (...) mit einem schnellen > AVR ATMega, der mit 18.432 MHz gehetzt wird. Dennoch brauchte dieser > beim Durchrechnen einer Entladeformel mit 4 Multiplikationen und > einer Division bei 32 Bit Operationen anfangs 200 us. Das ist sogar ein Argument für einen M3 oder M4. Die M0 können nämlich nicht dividieren! Jedenfalls nicht in Hardware. Wer designed so kranke Chips? Uwe schrieb: > Alle Microcontroller werden ja heute in C programmiert. Es ist daher > vollkommen egal ob man einen dummen kleinen AVR oder was richtiges wie > einen SH2 oder grossen ARM programmiert. Man merkt es schlicht nicht. Ist das jetzt gut oder schlecht? Ich bin froh, dass ich es an einer fehlenden library gemerkt habe. Die braucht der GCC für eine Division auf dem M0. Die gehört nicht zur Grundausstattung und für 25000 Zeilen C für den M3 hatte mir diese library nicht gefehlt.
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.
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
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.
Jörg W. schrieb: > CM0/CM0+ sind auf minimale Chipfläche designt Die Historie war doch in etwa so: man wollte einen ARM7 Nachfolger bei dem Exceptions komplett in C programmiert werden können. Dafür hat man Register-Banking durch Auto-Stacking ersetzt und raus kam der CM3. Hinterher hat man dann gemerkt, dass dadurch Latenzen auftreten, keine Rekursion mehr möglich ist, und bei Stacküberlauf Hardfault. Daher musste man für sicherheitskritische Anwendungen die Cortex-R Serie nachschieben. Dann wollte man einen billigen CM3 machen. Anstatt aber einzelne Funktionen wegzulassen, wurde eine ältere Thumb-Version genommen. Folge: C-Code vom CM3 läuft oft auch neu kompiliert nicht auf dem M0 z.B. Alignment Hardfault. Und Assembler-Code vom CM0 läuft trotz "Aufwärtskompatibilität" nicht auf dem CM3 z.B. MOVS / MOV > Division ist die kostspieligste der Grundrechenarten, daher hat man > diese dort weggelassen Beim Hardware-Multiplier hatte man sich zunächst auch einen Preisunterschied vorgestellt. Daraus wurde aber nichts. Fast : This allows the MULS instruction to execute in a single cycle Small : An iterative multiplier that takes 32 cycles to execute a MULS instruction.
A. K. schrieb: > Andererseits ist der Chipaufwand für eine kombinatorische Multiplikation > recht hoch Jetzt haben sich unsere Posts überschnitten - komplett zeitgleich :-) Wie geschrieben will aber Stand heute niemand mehr bezahlen für den Fast. Alle NXP CM0 haben daher Fast.
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
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:
1 | 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.
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 :-)
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.
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.
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.
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.
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
dumdideldei schrieb: > - Knackige Logikrätsel beim Debuggen von DMA dank Adressvirtualisierung Haben die kleinen Cortexe nicht. Eine Sorge weniger. :)
> 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
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.
A. K. schrieb: > Hinsichtlich Stack-Überlauf besteht der Unterschied dann nur darin, dass > die CMx Interrupts auf dem System-Stack arbeiten, die beiden CRx > Interrupts hingegen eigenen Stacks besitzen Dafür muss der System-Stackpointer initialisiert werden. Dennoch kann es dann durch das Autostacking by Exceptions zum Stacküberlauf kommen. Auch im NMI-Handler kann das nicht behoben werden, der braucht auch Stack. Der FIQ-Handler braucht erst mal keinen Stack, da eigene Registerbank ab R8 Alles würde ohne Probleme funktionieren, hätte man für jeden Mode einfach eine komplette Registerbank gemacht, wie beim 8051. Die Notlösung ist ja Dual-Core CM4/CM0 wie im LPC54 um "echt parallel" zu werden. > Der CM3 hingegen arbeitet ausschliesslich im Thumb2-Befehlssatz und > dessen Exception-System ist von Haus aus reentrant Es ist dadurch nicht echtzeitfähig: https://books.google.de/books?id=9YxqAAAAQBAJ&pg=SL5-PA198&lpg=SL5-PA198&dq=cortex-m+recursive+interrupt&source=bl&ots=Ub31N8dyfy&sig=owT9d-BewFO2JGzQxp0ae9CWFyw&hl=de&sa=X&ved=0ahUKEwjvi-L1tMPXAhVFXhoKHTehCycQ6AEIRjAD#v=onepage&q=cortex-m%20recursive%20interrupt&f=false
Die Argumentation, dass ARM Controller für Anfänger schwieriger anzuwenden sind, als 8bit Mikrocontroller ist korrekt. Aber nicht jeder empfindet das als Hindernis. Immerhin benutzen viele von uns auch den ATmega328P lieber, als den ATmega8. Auch dort gibt es erhebliche Unterschiede im Umfang der Datenblätter. Beim Hobby ist doch oft der Weg das Ziel. Ich erforsche einen Chip, und freue mich dann, dann ich ihn für etwas nützliches benutzen kann. Ob das nun die technische optimale oder preisliche günstigste Lösung ist, spielt im Hobby meistens nur eine untergeordnete Rolle.
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.
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
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
> 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
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
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
Angehängte Dateien:
-
ARM1.png
290 KB
A.K. schrieb >Es gibt aber keinen ARM ohne Barrel Shifter. Der war von vorneherein aus >der Implementierung der ARM Architekturen nicht wegzudenken. Und der hat schon beim ARM1 ziemlich viel Chip-Fläche verbraucht. von http://www.righto.com/2015/12/reverse-engineering-arm1-ancestor-of.html Es hat mich erstaunt, dass der Barrelshifter so wichtig ist, dass man so viel Fläche dafür spendiert. Der Befehlssatz wurde von Sophie Wilson entwickelt https://www.youtube.com/watch?v=re5xAqgKqc0 womit sie wahrscheinlich zu den einflussreichsten Frauen der Computerära gehören dürfte.
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
Uwe schrieb: > Werde > mich nun daher mal mit Rechenzeiten des M0 fit machen, und dann mal > schauen, ob es bei dem M3s auch Gehäuseformen mit 1.27 mm oder 0.8 mm > Pitches gibt. Beides ist nicht zielführend. Wenn du viel rechnen willst, dann greife zum M4F und rechne in Gleitkomma. Wenn du es dort dann passend formulierst, benutzt der Compiler dabei auch die DSP-Befehle. Das ist durchaus schnell. Und das Zweite ist, daß es zwar bei Freescale (soweit ich weiß in der MKE-Serie) Chips im etwas gröberen Raster als 0.5 gibt (mag sein 0.65 oder 0.8, hab's nicht auswendig gelernt), aber das sind dann eben wieder M0 oder M0+ und weder M3 noch M4 und schon gar nicht M4F. Obendrein kann ich die Freescale-Chips nicht wirklich empfehlen. W.S.
A. K. schrieb: > Demgegenüber empfinde ich es als Kardinalfehler des ursprünglichen ARM > Designs, dass der PC des unterbrochenen Kontextes im LR des > Interrupt-Kontextes gesichert wird Aber nur so kann doch die ISR mit MOV PC, LR beendet werden ??? Sonst bräuchte man doch wieder einen Stack für LDMIA SP!, {PC}
Hallo W.S.! . Stimmt der M4 hat ja schon DSP Funktionalitäten, da könnte man sich ja auch gleich in Fourier Analyse austoben. :-) Deine gesunden Ansichten und Technikbegeisterung in allen Ehren, aber mir kommt die Situation vor, als wenn man einem Fahrschüler, der gerade auf einem Golf die Führerscheinprüfung bestanden hat, einen 40 Tonner hinstellt nach dem Motto, damit kannste nicht nur zum Discounter fahren, sondern auch gleich deine Umzüge mit machen..... Ich möchte keinen brutalen Umstieg machen, sondern schrittweise die ARM-Cortexe kennenlernen in entspannter Atmosphäre! Der M4 wird bestimmt mal bei mir an der Reihe sein, aber nicht sofort, will ja meinen Lebensabend nicht verfluchen! Beste Grüße, U.H.
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
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 ;-)
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
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"
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.
> 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.
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.
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.
> 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.
>Da gab es aber schon den 16/32-bit ARM2 und der war als Derivat des >8-bit 6502 wesentlich einfacher in Assembler zu programmieren. Leider >ist der ARM-Erfinder Acorn vor Commodore Pleite gegangen. Trotzdem: wo >ist heute das 68000 Zeug wie 68HC, Coldfire und PowerPC? Und wo ist ARM? PowerPc wird noch millionenfach in der Automobilindustrie verbaut: https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/mpc5xxx-55xx-32-bit-mcus:POWER_ARCH_5XXX Coldfire ist die Weiterentwicklung des 68000 : https://en.wikipedia.org/wiki/NXP_ColdFire Wo der noch verwendet wird, weiß ich nicht.
> Wohl kaum, denn die SH2A sind Edelprozessoren und in Bastelkreisen eher > nicht anzutreffen. Bei mir laeuft er seit Jahren als MP3-Player. :) > Es sind übrigens 16 Registerbänke - für jede Priorität eine eigene Bank. Stimmt, hab mich da vertan. > Richtig edle Teile, kennt hier allerdings kein Schwein ;-) Schnuckelig ist auch das echte Dualportram. Und überhaubt die interne RAM-Groesse. Die Bastlerschweine mögen die aber natuerlich nicht weil es die sicher nicht in DIL gibt. Ausserdem hat das Datenblatt auch 2000Seiten. Aber immerhin sind die nicht in BGA. Und sie werden problemlos vom Gcc unterstuetzt. Problem bei den Teilen ist eher das einem da Projektideen fehlen wo man so eine Leistung wirklich braucht. Als Weihnachtsbaum-LED-Ansteuerung ist er auch mir etwas zu schade. Im Prinzip ist das ein neues Luxusproblem. Waehrend man beim MCS48 noch ueber jedes SpeicherBIT nachgedacht hat, so bekommt man heute Microcontroller kaum noch ausgelastet. Olaf
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.
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
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.
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.
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.
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.
Ist die Komplexität des Befehlssatzes ziemlich egal, solange es einen passenden Compiler für irgendeine Hochsprache gibt?
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.
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
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.
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.
A. K. (prx) >Nur IBM ist noch dabei, auf einem zwar sehr >kleinen Markt, kann aber enorme Preise verlangen. Wenn Du damit die Desktop PowerPCs meinst, dann vielleicht. Es gibt aber eben auch die MPC Serie für Embedded-Anwendungen, die "noch" massiv in der Automotive-Industrie eingesetzt wird. z.B.: https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/mpc5xxx-55xx-32-bit-mcus/ultra-reliable-mpc57xx-32-bit-automotive-industrial-microcontrollers-mcus:MPC57XX
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).
m.n. schrieb: > Richtig edle Teile, kennt hier allerdings kein Schwein Oink, oink... allerdings ist die Unterstützung durch WinCE seit langem eingestellt - nur so am Rande. Also mal im Klartext: Das ist/war ne andere Liga als das, was hier auf dem Programm steht. Uwe schrieb: > als wenn man einem Fahrschüler, der gerade auf einem Golf die > Führerscheinprüfung bestanden hat,... leg einfach die Angst ab. Es sind auch bloß Chips im TQFP mit 48..64..80..100..120 Pins, je nach Typ. Und die zugehörige Dokumentation ist auch nicht viel anders als bei den M0 Typen. W.S.
Uwe schrieb: > Hallo W.S.! > . > Stimmt der M4 hat ja schon DSP Funktionalitäten, da könnte man sich ja > auch gleich in Fourier Analyse austoben. :-) Deine gesunden Ansichten > und Technikbegeisterung in allen Ehren, aber mir kommt die Situation > vor, als wenn man einem Fahrschüler, der gerade auf einem Golf die > Führerscheinprüfung bestanden hat, einen 40 Tonner hinstellt nach dem > Motto, damit kannste nicht nur zum Discounter fahren, sondern auch > gleich deine Umzüge mit machen..... Ich möchte keinen brutalen Umstieg > machen, sondern schrittweise die ARM-Cortexe kennenlernen in entspannter > Atmosphäre! Der M4 wird bestimmt mal bei mir an der Reihe sein, aber > nicht sofort, will ja meinen Lebensabend nicht verfluchen! > Beste Grüße, > > U.H. Hi Uwe, Ich denke du machst dir unnötig einen Kopf. Du musst die volle Funktionalität ja nicht nutzen. Ich habe zum Beispiel CortexM3 Platinen im 10er Pack zu Hause liegen und nutze die für alles. Egal ob es nur ein Lauflicht ist, eine Schaltung für einen LED-Dimmer, oder die Steuerung eines Quadrokopters. Absolut irrelevant, denn der Preis ist so niedrig, dass es keine Rolle spielt. Wenn man C nutzt ist die Komplexität egal. Selbst 14-Jährige können ARM-Prozessoren spielend einfach programmieren. Ich selbst habe einem Mechaniker die Thematik an Hand eines ARMs nähergebracht. Er programmiert natürlich in c und nutzt vorhandene Librarys von ST. Es ist kinderleicht und wirklich nicht schwer. Hier im Forum gibt es jemanden der sogar Kindern die Elektronik an Hand von CortexM3 näherbringt. Er hat ein nettes Buch geschrieben. Beitrag "Buch Vorstellung in eigener Sache - für Weihnachten?" Also: Nur Mut. Schritt für Schritt. Und erstmal mit einem Blinki anfangen :-)
Angehängte Dateien:
-
nutiny-m451v.jpg
28 KB
Lothar schrieb: > Wobei ein M4F jetzt auch nicht die FPU Performance hat und der Preis in > der Nähe eines Pi Zero liegt Schreib keinen Unsinn. Bei Farnell liegen die einschlägigen STM32F4xxx um und bei 5 Euro netto und bei Nuvoto-direct fangen die M4F bei etwa 2.50 Euro an, ab 10 Stück wird's billiger. Bastel-Boards dazu gibt's auch, die liegen bei etwa 19..20 Euro, siehe Bild. Der Pi-Zero liegt m.W. nackt ohne alles bei etwa 11..12 Euro und mit Adaptern bei etwa 17..20 Euro. Dazu dann noch die SD-Karte.. und das Ganze ist ne völlig andere Liga als ein Cortex M0..4, deswegen auch völlig andere Softwareumgebung, andere Paradigmen usw. W.S.
W.S. schrieb: > Der Pi-Zero liegt m.W. nackt ohne alles bei etwa 11..12 Euro Der Pi Zero kostet 5 EUR. Du verwechselst das mit dem Pi Zero W: https://shop.pimoroni.de/products/raspberry-pi-zero > das Ganze ist ne völlig andere Liga als ein Cortex M0..4 Das ist falsch. Ohne Linux geht problemlos: BASCOM-ähnliches BASIC mit Inline-Assembler z.B. Blinky LED1 = 21 toggle = 0 SYS "GPIO_WriteMode", LED1, 1 REPEAT SYS "GPIO_WriteData", LED1, toggle toggle = 1 - toggle timeact = TIME + 25 REPEAT UNTIL TIME > timeact UNTIL FALSE Auf PC BIN-File erzeugen und vom Bootloader statt einem Kernel laden lassen z.B. https://github.com/PeterLemon/RaspberryPi/blob/master/HelloWorld/CPU/kernel.asm
Lothar schrieb: > 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.
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
:
Bearbeitet durch User
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.
Lothar schrieb: > Das ist falsch. Ohne Linux geht problemlos: ... > https://github.com/PeterLemon/RaspberryPi/blob/master/HelloWorld/CPU/kernel.asm Willst du mich auf'n Arm nehmen? Mal ganz davon abgesehen, daß all diese Githubianer es partout nicht fertig bringen, zu ihrem Krempel ein Konzept und eine Dokumantation ihres Krempels im PDF Format zuwege zu bringen. Wurschtel-Kruscht. W.S.
A. K. schrieb: > Pegge schrieb: >> Selbst 14-Jährige können ARM-Prozessoren spielend einfach programmieren. > > Bizarrer Vergleich. Mit 70 dauert manches Neue etwas länger als mit 14. Das stimmt allerdings. Als Jungspund vergisst man das oft.
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
W.S. schrieb: > Dokumantation ihres Krempels im PDF Format zuwege zu bringen Die BASIC Doku wurde erst am 04.11. komplett renoviert.
W.S. schrieb: > m.n. schrieb: >> Richtig edle Teile, kennt hier allerdings kein Schwein > > Oink, oink... allerdings ist die Unterstützung durch WinCE seit langem > eingestellt - nur so am Rande. Ich weiß nicht, wie Du in diesem Zusammenhang (SH2A) auf WinCE kommst. > Also mal im Klartext: Das ist/war ne andere Liga als das, was hier auf > dem Programm steht. Von der reinen Rechenleistung her, spielen die von mir erwähnten 7211 bzw. 7216 in der gleichen Liga wie Cortex-M4/-M7. Die fehlende Verbreitung führe ich darauf zurück, daß es nie bastlergünstige Demo-Boards gab. Renesas war/ist sich vermutlich zu fein dafür oder hat es durch seine Großkunden nicht nötig gehabt, so etwas anzubieten. Neuerdings hat man aber auch noch ARM als Kernprozessor entdeckt. Vermutlich, weil man auf Kundendruck mit auf diesen Zug aufspringen mußte. Wie auch immer: sieh Dir das Pinout von SH, H8SX oder auch RX-Controllern an und was die Peripherie bietet, dann verstehst Du, was ich als edel bezeichne.
Lothar schrieb: > Die BASIC Doku wurde erst am 04.11. komplett renoviert. Wo finde ich dieses BASIC? Bitte poste einen Link.
Sven D. schrieb: > Wo finde ich dieses BASIC? Bitte poste einen Link. Gab hier im Forum schon eine Diskussion zu: Es handelt sich um "RISC OS Pico" Das ist kein Image wie z.B. Raspbian sondern der Inhalt des ZIP wird auf eine FAT-formattierte SD-Karte gezogen. Dann startet das Pi im BASIC https://www.riscosopen.org/content/downloads/raspberry-pi Da es natürlich dann keinen Desktop gibt, ist die Programmierung, auch mit Editor, umständlich. Daher nimmt man üblicherweise einen PC oder ein zweites Pi mit Desktop zum Programmieren, und schiebt das Ergebnis rüber. Es gibt auch Auto-Boot, dann wird das BASIC Programm auf der SD-Karte beim Einschalten gestartet. Das funktioniert ohne Monitor und Tastatur, also gut für Embedded. Es gibt mehrere Foren z.B. https://www.raspberrypi.org/forums/viewtopic.php?t=185715 Und hier hatte ich mal eine Grafik-Demo gepostet: Beitrag "Re: Raspberry Pi als "dicker" Mikrocontroller"
Beitrag #5214712 wurde von einem Moderator gelöscht.
Hatte ich noch vergessen: Ein Online-Manual gibt es auch z.B. https://www.riscosopen.org/wiki/documentation/show/IIC_Control
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.
> Von der reinen Rechenleistung her, spielen die von mir erwähnten 7211 > bzw. 7216 in der gleichen Liga wie Cortex-M4/-M7. > Die fehlende Verbreitung führe ich darauf zurück, daß es nie > bastlergünstige Demo-Boards gab. In Deutschland. Ich bin ja auf den SH2A aufmerksam geworden weil so ein Board in Japan der Elektronikzeitschrift kostenlos beilag. Und es gab dort auch immer irgendwelche anderen billigen Boards von Renesas in den Elektronikgeschaeften. Ich glaub sogar mal gesehen zu haben das Elektor hier auch mal ein Board mit so einem Controller hatte, bin mir aber nicht sicher. Olaf
Olaf schrieb: > Ich glaub sogar mal gesehen zu haben das Elektor hier auch mal ein Board > mit so einem Controller hatte, bin mir aber nicht sicher. Mit dem R8C. 16-Bit Architektur. Völlig andere Linie.
Olaf schrieb: > Ich glaub sogar mal gesehen zu haben das Elektor hier auch mal ein Board > mit so einem Controller hatte, bin mir aber nicht sicher. Du meinst dieses Board: https://www.reichelt.de/MC-68HC-Controller/EVB-R8C13/3/index.html?ACTION=3&LA=2&ARTICLE=69672&GROUPID=2944&artnr=EVB+R8C13&SEARCH=%252A Das sieht sich aber hier einer Konkurrenz von 'blauen Pillen' gegenüber, die jedem Schinagrabscher als portofreies 5er-Pack bekannt sein dürfte, und den R8C13 im Regen stehen lassen. Für die SH2A µCs braucht man zum Einstieg allein schon einen E10A Emulator, der vor ein paar Jahren bei € 200/Stk. lag. Erst die neueren Renesas µCs (RX) werden mit 1- bzw. Mehrdraht Debug-Interface angeboten. SWD ist da im Vorteil und in der Praxis pflegeleichter zu benutzen. > In Deutschland. Wegen langer Lieferzeiten hatte ich mir Renesas-Teile wiederholt in USA besorgt. Jetzt bin ich beim STM32F4xx gelandet, den - wie oben geschrieben - selbst Farnell aktuell in guter Stückzahl zu gutem Preis anbietet. Der F4 ist ein Spatz in der Hand - aber auch ein ganz flotter ;-)
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.
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/edge/solution/16-rz.html > 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)
Arc N. schrieb: >> Die fehlende Verbreitung führe ich darauf zurück, daß es nie >> bastlergünstige Demo-Boards gab. > > Mittlerweile gibt's die zumindest für RX und Synergy, afair alle mit > J-Link eingebaut > http://www.renesasshop.com/promotion-board Bei den aufgeführten Boards würde ich wegen der Leistungsfähigkeit und des Alters nicht unter RX210 einsteigen wollen. RX210, ein schönes Teil, für das ich vor fünf Jahren ein bißchen (nutzlos) die Trommel gerührt habe: Beitrag "Verlosung RX210 Promo-Board" Trotz J-Link Unterstützung sind die Endpreise > € 50, was hier im Forum schon als Wucher gilt. Nucleo-Boards mit ST-Link gibt es für weniger als ein Drittel (https://www.reichelt.de/Einplatinen-Microcontroller/NUCLEO-F411RE/3/index.html?ACTION=3&LA=446&ARTICLE=154272&GROUPID=6667&artnr=NUCLEO+F411RE&SEARCH=nucleo) und beim Kauf in Schina bekommt man (vermutlich) noch Geld dazu. Das ist, was hier zählt. Daß diese RX einen fein konfigurierbaren Adress-/Datenbus bieten, rafft das Bastlerherz doch garnicht. Daß es neben einem DMA, der nicht nur vorwärts sondern auch rückwärts und teilweise mit beliebigen In-/Dekrement arbeiten kann, auch einen exDMA gibt, der ext. getriggert werden kann: merkt doch keiner, wozu braucht man DMA? Und daß es für Peripherie viele, separate Interrupt-Vektoren für fast jedes einzelne Ereignis gibt: das habe ich noch nie gebraucht. Was soll man da argumentieren? Aber wie gesagt, auch Spatzen können fliegen, auch wenn es nicht immer so schön aussieht ;-)
Beitrag #5215362 wurde von einem Moderator gelöscht.
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.
> 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
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.
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.
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.
> 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
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.
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.
> 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.
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.
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
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.
Beitrag #5222486 wurde von einem Moderator gelöscht.
Ich bin als Anfänger darüber gestolpert, dass der ADC des STM32F103 zum verrecken keine (Single-Shot) Messung machen wollte. Nach 4 Stunden try&error fand ich dann die Lösung. Ich muss ihn für jede einzelne Messung immer wieder erst einschalten und dann starten:
1 | // Start a conversion
|
2 | SET_BIT(ADC1->CR2, ADC_CR2_ADON); |
3 | SET_BIT(ADC1->CR2, ADC_CR2_SWSTART); |
4 | |
5 | // Wait until the conversion is finished
|
6 | while (!READ_BIT(ADC1->SR, ADC_SR_EOC)); |
7 | |
8 | // Return the lower 12 bits of the result
|
9 | return ADC1->DR & 0b111111111111; |
Die beiden Bits in einem Abwasch zu setzen, bringt nichts. Und dass man ADON immer wieder erneut einschalten muss, steht auch nicht im Datenblatt. Jedenfalls habe ich dazu nichts gefunden. Da sind die Datenblätter der AVR's deutlich klarer geschrieben. Das gängige Totschlag-Argument von wegen "verfusen" zählt für mich nicht, denn diesen Fehler macht man höchstens 2 mal, wenn man bei Verstand ist.#
Beitrag #5222496 wurde von einem Moderator gelöscht.
Beitrag #5222499 wurde von einem Moderator gelöscht.
Beitrag #5222501 wurde von einem Moderator gelöscht.
Beitrag #5222531 wurde von einem Moderator gelöscht.
Tja, mein Beitrag ist noch da (juhu). Aber nun fragen sich alle, was will der stefanus uns damit sagen? Kurze Erklärung für diejenigen, die die gelöschten Beiträge nicht gelesen haben: Es ging darum, dass AVR Mikrocontroller deutlich einfacher zu verstehen und klarer dokumentiert sind, als so mancher ARM Controller. Da ich mich gerade mit der schlechten Doku eines ARM Modell abgekämpft habe, wollte ich ein konkretes Beispiel dazu zeigen.
Thread beobachten
Seitenaufteilung abschalten