Arduio Zero mit ARM Cortex M0.

Gast
Bernd K. schrieb:
> dann wird ein DigitalWrite() wohl endlich so performant sein wie ein
> PORTx |= BLUB auf einem nackten Tiny 44. Oder wahrscheinlich eher doch
> wieder nicht.


Schau an...

Ein "Arduino ist doof" Troll Sprüchlein und wird sofort positiv 
bewertet....
Ein dreifach Hoch auf dieses Forum!


Tipp 1:
Keiner zwingt ich, oder jemanden anders, auf "PORTx |= BLUB" zu 
verzichten.
Keiner zwingt dich digitalWrite() zu verwenden.

Am Rande:
Ja, es heißt digitalWrite() und nicht DigitalWrite()!
Ein bisschen mehr Sorgfalt könntest du schon walten lassen.
Gast
Dennis S. schrieb:
> ...kommt Arduino damit aus der Kinderecke raus ?

Du glaubst doch nicht, dass die nochmal lernen Datenblätter zu lesen um 
aus Versehen mal ein halbwegs taugliches Hardware-Design zu machen?

Aber im Moment sind die sowieso mehr damit beschäftigt sich
gegenseitig zu verklagen:
http://www.golem.de/news/rosenkrieg-arduino-zahlt-arduino-keine-lizenzgebuehren-1503-113071.html
(Firma: guloshop.de)
Ulrich F. schrieb:
> Tipp 1:
> Keiner zwingt ich, oder jemanden anders, auf "PORTx |= BLUB" zu
> verzichten.
> Keiner zwingt dich digitalWrite() zu verwenden.

Das ist richtig, wird oft vergessen. Die Arduinos lassen sich auch 
"native" programmieren.

Ich vermute aber, dass die M0-Registerbreite von 32 bit für viele 
Anwendungen gar nicht gebraucht wird, weil es meistens darum geht, 
irgendwelche Bits hin- und herzuschubsen.

Wenn ich das aber richtig lese, kann der Arduino mit M0 einen 
Ausgangspin auch nicht sehr viel schneller schalten als ein 8-Bit-AVR, 
auch wenn der CPU-Takt mehr als doppelt so hoch ist. Statt einem 
einfachen "sbi" braucht man beim M0 vier einzelne Assembler-Befehle: 
Load, Move, Or, Store. Oder habe ich da etwas übersehen?

Dann ist er auch noch beschränkt auf maximal 3,6 Volt... oder?
Je Pin nur 7 mA statt 20 (bzw. 40) wie bei den robusten 8-Bittern.

OK, ich geb zu, dass ich nicht viel Ahnung habe, aber wirklich 
begeistert haben mich die technischen Daten des Arduino Zero nicht.
Gast
Markus Weber schrieb:
> Statt einem einfachen "sbi" braucht man beim M0 vier einzelne
> Assembler-Befehle: Load, Move, Or, Store

Viele M0 z.B. LPC11A haben einen Block Bit-addressierbaren Speicher (wie 
8051) so dass mit Move, Store gesetzt / gelöscht werden kann. Wobei man 
üblicherweise je ein Register immer 0 und 1 lässt für solche Zwecke also 
eigentlich nur Store braucht.

Beim hier verwendeteten SAMD21 durckblicke ich das Datenblatt nicht 
ganz, aber der scheint keinen Bit-addressierbaren Speicher zu haben. 
Allerdings ist es ein M0+ und sollte somit Bit-Banding unterstützen, 
auch damit kann mit Move, Store gesetzt / gelöscht werden.
Gast
Also zumindest die SAMD20 haben zig Register pro Port.
Je eines zum Setzen, Löschen, Wackeln zum Beispiel.

Wie man an die Register rankommt habe ich immer noch nicht ganz raus, 
geht aber, irgendwas in der Art:

PORT.bla.blupp.SET = 23;

Wenn ich mich mal ernsthaft damit beschäftige brauche ich erstmal nen 
Tutorial das die Dinger ohne ASF erklärt.
(Firma: guloshop.de)
Rudolph schrieb:
> Je eines zum Setzen, Löschen, Wackeln zum Beispiel.

Klingt interessant. Gibt es irgendwo ein Assembler-Tutorial für den 
ATSAMD21G18A?

Man könnte den natürlich auch in C programmieren und dann schauen, was 
der Compiler so draus macht, aber der Weg ist wohl etwas mühsam.
Gast
Rudolph schrieb:
> Also zumindest die SAMD20 haben zig Register pro Port.
> Je eines zum Setzen, Löschen, Wackeln zum Beispiel.

Wenn das so ist braucht es immer noch einen zusätzlichen Shift um das 
entsprechende Bit anzusprechen. Bei Bit-addressierbarem Speicher hat 
jeder Pin eine eigene 8-Bit Adresse von der nur das Bit 0 tatsächlich 
existiert und mit STRB gesetzt / gelöscht wird. Bei Bit-Banding hat 
jeder Pin eine eigene 32-Bit Adresse, also etwas verschwenderisch.
@ Bernd K. (prof7bit)

>dann wird ein DigitalWrite() wohl endlich so performant sein wie ein
>PORTx |= BLUB auf einem nackten Tiny 44. Oder wahrscheinlich eher doch
>wieder nicht.

Naja, auch dort könnte man mi wenig Mühe auch ein digitalWrite() so 
schnell machen wie ein PORTx |= BLUB. Ich hab keine Ahnung von C++, 
würde aber mal vermuten, dass man u.a. mit dem Überladen von Funktionen 
erkennen kann, ob die Parameter konstant oder variabel sind. Sind sie 
konstant, kann man es auf sbi verkürzen. Und meistens sind sie konstant.
Gast
Lothar schrieb:
>> Also zumindest die SAMD20 haben zig Register pro Port.
>> Je eines zum Setzen, Löschen, Wackeln zum Beispiel.
>
> Wenn das so ist braucht es immer noch einen zusätzlichen Shift um das
> entsprechende Bit anzusprechen.

Was für ein Shift?
Sowas wie in "(1<<PA0)"? Das wird doch nicht zur Laufzeit gemacht.
Ausserdem ist da doch die Frage, wie die Includes definiert sind.

PORT.dings.SET = 1;
PORT.dings.CLEAR = 1;
PORT.dings.TOGGLE = 1;

Ist doch erstmal alles schön atomar, kein Read-Modify-Write.
Gast
Rudolph schrieb:
> PORT.dings.SET = 1; Das wird doch nicht zur Laufzeit gemacht.

Du musst Dich etwas mit ARM Assembler beschäftigen :-)

Wenn es Bit-addressierbaren Speicher oder Bit-Banding gibt, wird das 
z.B. zu:

MOV   R0, #1           ; die Dummy 1
LDR   R1, =0xA0002100  ; die Adresse von SET.P0.4 (ein Pin)
STRB  R0, [R1]         ; P0.4 wird gesetzt

Aber jetzt können weitere Pins z.B. P0.8 ohne weiteres auch gesetzt 
werden:

STRB  R0, [R1, #4]

Wenn es das nicht gibt:

MOV   R0, #10000B      ; gewünschtes Bit hier 4
LDR   R1, =0xA0002100  ; die Adresse von SET.P0 (Port mit 32 Pins)
STR   R0, [R1]         ; P0.4 wird gesetzt

Wenn jetzt z.B. auch P0.8 gesetzt werden soll wird das meist zu:

LSL   R0, R0, #4

Dazu kommt noch dass Werte >2^8 auf M0 nicht mit MOV geladen werden 
können, um also z.B. an P0.10 ranzukommen:

MOV   R0, #1
LSL   R0, R0, #10

Natürlich kann Atmel das "gelöst" haben indem alle Ports nur 8 Pins 
haben. Das gibt aber wieder andere Optimierungsprobleme.

Am besten ist Bit-addressierbarer Speicher und fortlaufende Pinnummern.
Gast
Franz schrieb:
> mbed ist ganz nett, aber mich stört der Online-Compiler.

Man kann mit jedem beliebigen Compiler (gcc, Keil, IAR, LPCXpresso) ein 
Binary machen und nur den mbed-Bootloader nutzen. Die mbed-Libraries 
kann man exportieren und linken.
Gast
Franz schrieb:
> Was konkret stört Dich an dem Schaltplan des Arduino Zero:
> http://download.arduino.org/products/ZEROPRO/Arduino-Zero-Pro-V3-SCH.pdf

Der Schaltplan sieht auf den ersten Blick nicht schlecht aus, da hat dem 
Designer wohl einer von Atmel mehrmals gegen das Tischbein getreten. :-)

Was mir nicht gefällt ist der Debugger auf dem Teil, das macht jede 
einzelne Platine deutlich teurer als sie sein müsste.
Den Atmel-ICE kann man kaufen, warum ist der da mit drauf verbaut?

Was ich ausserdem seltsam finde ist das der SAMD21 keinen richtigen 
Taktgeber hat, nur einen Uhrenquarz an dem komischerweise 22pF 
Kondensatoren dran hängen.
Aber ich habe auch noch keine Platine mit dem SAMD2x gemacht, vielleicht 
gehört das ja so?

Das Layout kann ich mir mit der EAGLE 6.6 Light die ich hier noch 
installiert habe nicht vollständig ansehen, das scheint mindestens vier 
Lagen zu haben, sehen kann ich nur zwei.

Also das V3 Referenz-Design.

Das Layout ist wieder so, dass es jemanden der das hier posten würde um 
die Ohren gehauen werden würde.
Die Kondensatoren am Controller zum Beispiel, C3 und C20 sind quasi 
unwirksam und C1 nicht wirklich prall angebunden.

Durchmesser und Bohrung von Durchkontkatierungen sind weder sinnvoll 
klein noch einheitlich.

0,6096 mm Drill, 1,2192mm Durchmesser? -> 24 / 48 mil
Andere haben 16 / 32 mil.

Aber unter dem BGA sind es 0,2 mm Bohrung mit 0,4286mm Durchmesser.

Mit 12 / 24 mil bzw. 0,3 mm Bohrung für die normalen VIAs könnte man das 
Board auch ein wenig entspannter routen und 0,3mm sind normal Standard 
für die Platinen-Fertigung.

Der DRC wirft (mit der Warnung das zwei Layer fehlen) 864 Fehler.
Der ERC wirft einen Fehler und 41 Warnungen.
Moderator Persönliche Seite
Rudolph schrieb:
> Was ich ausserdem seltsam finde ist das der SAMD21 keinen richtigen
> Taktgeber hat, nur einen Uhrenquarz

Das passt so.  Der FLL-Taktgenerator (frequency locked loop) kann nur
bis 33 kHz als Eingangstakt verarbeiten, sprich, er ist explizit auf
den durchlaufenden Uhrenquarz ausgelegt.  Davon kann er dann die
(bis zu) 48 MHz Haupttakt ableiten.
Gast
Jörg Wunsch schrieb:
> Das passt so.  Der FLL-Taktgenerator (frequency locked loop) kann nur
> bis 33 kHz als Eingangstakt verarbeiten, sprich, er ist explizit auf
> den durchlaufenden Uhrenquarz ausgelegt.  Davon kann er dann die
> (bis zu) 48 MHz Haupttakt ableiten.

Das gibt prächtige Phasenjitter. Hoffentlich nicht. In FPGAs
schaut das mit den digitalen PLLs jedenfalls "schrecklich" aus.
Gast
Jörg Wunsch schrieb:
> und nennen das dann “spread spectrum oscillator”. ;-)

Ja klar, it's not a bug, it's a feature (Zitat aus alten
Apple Zeiten).

Und die meisten werden es nie bemerken. Ist ja auch "nur"
grob der Vervielfachungsfaktor 1250.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 11 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.