Mal wieder: Arduino und Rapsberry als Treiber-Boards - Deutsches Howto

also je mehr ich mich mit dem arduino beschaeftige, um so mehr komme ich zu dem schluss:
das ist n krampf!
fuer viel mehr als digital/analog-IO taugt der nicht

ich dachte, man koennte ein schoenes DRO mit einer 8x8-matrik draus bauen.
aber dieses lib-gewurschtel ist irgendwie ganz schoen nerviger kram,
wenn man gleichzeitig eth- und matrix-libs benutzen will.
die komme sich ins gehege - aber ohne einen error oder conflict zu melden.

das leg ich erst mal beiseite und probier das mal mit nem raspi.
da kann man wenigstens ordentliche compiler und tools benutzen.

kann doch garnicht sein
die ARDUINO CNC Gemeinde wächst täglich um mehrere Hundert Personen
alle Estlcam Platinen verkaufen sich wie Geschnitten brot
und die 3D drucker sind bei Hornbach und Bauhaus ständig ausverkauft

pl7i92 wrote:

kann doch garnicht sein

hoere ich da einen leicht sarkastischen, wenn nicht gar zynischen, unterton?

so ein arduino ist nicht sooo schlecht. und um ein laempchen anzusteuern oder
einen input zu liefern, ist er sogar in verbindung mit linuxCNC zu verwenden.

aber auf einem raspberry geht das dann doch alles deutlich flotter von der hand.

jetzt bekomme ich auch schon die position via eth am matrixdisplay angezeigt.
aber nun ist der ganze code natuerlich erst mal wieder verhunzt....

*grmbl*

Das Wird schon immer Weiter Wir Zählen auf dich

Sarkasmuss ist da nicht mit im Spiel
wenn windoof das hinbekommt sollte es auch bei den tuxlern funzen
ohrenschützer nicht vergessen

ein nebenprodukt des raw-eth-treibers:



wird einfach mit

net X ethraw.0.par-00-pos <= stepgen.0.position-fb

eingebunden.
das hier wird von einem raspberry-zero gesteuert (mit usb-eth dran).
ich glaube, ich baue fuer die gemaechlichen sachen noch einen
"normalen" IP-stack mit ein.

irgendwie kommen immer neue baustellen dazu...

Na dann hast de ja wat zu tun. Sonst wird Dir noch langweilig ;-()

Schön gross das Display es fehlt der "springende Punkt"

pl7i92 wrote:

Schön gross das Display es fehlt der "springende Punkt"

alles zu seiner zeit....
ich bau grade neben raw-eth noch udp ein (fuer "langsame" sachen wie display und so)

und bin da in eine falle gelaufen
(bei udp ist das allerdings kein problem - es tritt nur bei raw-eth auf)

ich frag mal hier rum, aber vermutlich ist das wohl ehr was fuer die developer-liste:

da ich die raw-pakete "von hand" filtern muss, erwies sich die idee, direkt mit einem
gemeisamen receive- und arbeits-buffer als eine scheissidee.
ueber-optimiert nennt man das wohl

denn wenn die daten da sind und ich merke, dass die ja gar nicht fuer mich sind,
dann haben sie ja schon die zuvor validen altdaten uberschrieben.

also muss ich den relevanten datenbereich aus dem empfangspuffer rausschaffen.
und nun die frage:
kann es passieren, wenn ich diese 20 bytes mit memcpy in den validen bereich
move, dass ein linuxCNC-thread waehrenddessen zuschlaegt ? - und das genau
dann, wenn der memcpy erst 10 der 20 bytes gemoved hat?

munter bleiben

wicki

matrixtreiber wie cool ist das denn
der MCP23017 oder S017 ist der oberhammer für displays

Ja, generell ein bekanntes und nicht immer einfaches Problem. Speziell wen Du keine RT Umgebung hast.
Wenn Du keine Möglichkeit hast DMA / Interrupt zu unterbinden (denke das kannst Du nicht) dann müsstest Du mit grösserem Ringbuffer arbeiten und anhand des Anfang/ End Pointers Dein Memcopy machen. Aber ob das im Raspi möglich ist weiss ich nicht. Beim Arduino würde ich solange die Interupts disablen.