Druckbare Version
das Problem ist nicht, mit "Kanonen" auf Spatzen zu schießen, sondern der Glaube, unbedingt mit Wasserpistolen oder Blasrohren auf Strohhalmbasis das Ziel erreichen zu müssen :pZitat:
Zitat von Rabenauge
ein SAMD21=M0/Zero ist IMO der ggT zur Problemlösung, oder ein esp8266 mit ADS1115.
Blasrohre sind halt zuverlässiger...
Mal im Ernst: wenn wir uns nicht angewöhnt hätten, jedes Problem einfach mit geballter Rechenpower zu erschlagen, wären uns Seuchen wie Java erspart geblieben...und Windows inzwischen auch.
Ich find es durchaus interessanter, aus so nem schwachbrüstigen Rechner rauszuholen, was geht.
Die können mehr, als man oft meint- wenn man gescheit programmiert (naja....ich benutz ja auch nur die Arduino-IDE, insofern wäre da noch ne Menge Luft...)
Wenn sich rausstellen sollte, dass das Ding instabil läuft (woran ich _noch_ nicht glaube), dann wird sich ziemlich sicher ein Teensy finden, der das Problem aus der Welt schaffen kann.
Wie gesagt:vom ESP halte ich nicht viel- ich weiss zwar die Vorzüge durchaus auch zu schätzen (ein paar von hab ich auch schon verbaut)- aber ich trau den Chinesen einfach nicht. Wenn die nicht mit der Sprache rausrücken wollen, was der in Wirklichkeit noch alles treibt (deutlich mehr als man ihm sagt, das steht fest)-werden sie ihre Gründe haben...auf solche (möglichen) Sicherheitsprobleme reagier ich bisschen allergisch.
was die ESPs gundsätzlich angeht, hast du ntl Recht. Die ESP-cores und -libs für Arduino werden ja auch nur von einer Community privat "oben drauf" entwickelt, nicht von den Chinesen selber, und daher ist vieles noch komplett unfertig. Aber für "nicht trauen" besteht IMO bei denen kein Anlass, man baut sie ja nicht in sicherheitsrelevante IT Systeme mit Datenverschlüsselung ein.
Hätten die Nanos mehr RAM (8? 16kB?), wäre ja auch nichts gegen solche AVRs einzuwenden, aber 2 oder 2,5k sind einfach lächerlich, die werden ja schon von SPI+I2C fast komplett aufgebraucht, sodass kaum noch was für ein Programm übrig bleibt.
Wenn du den aber nur deshalb nimmst, weil er gerade da ist und du nichts besseres hast: klar, dann würde ich es auch erstmal damit versuchen.
Deinen Seitenhieb auf Windows etc verstehe ich aber nicht, cpus müssen mit den Sofwareanforderungen mitwachsen, genau wie hier, und die Preise dafür sinken ja zusehends - kein Grund also, in der IT-Steinzeit zu verweilen. Oder wolltest du ernsthaft auch noch mit CP/M und MSDOS auf deinem Homecomputer herumwerkeln?
Hm -ich benutz einfach Linux.
Schon seit Jahren... unproblematisch, zuverlässig, sicher und mit _weit_ moderateren Hardwareanforderungen.
Tatsächlich hatte ich mal ein Ubuntu (ich glaub, das war noch das 14er) auf nen "Sperrmüll-Rechner" (sah jedenfalls so aus..) ans laufen gebracht, der nicht mal mit XP flüssig lief- das Ding war so schwachbrüstig, dass ich die LXDE nachinstallieren musste, weil nicht mal Unity auf die Beine kam.
Lief dann aber völlig problemlos und überraschend schnell.
Aber lassen wir das- wird nur wieder ein Glaubenskrieg, und ich muss nix glauben.
Inzwischen hat es noch nen netten Rahmen ums Display gegeben (der den überschüssigen, anders-blau leuchtenden Rand fast komplett verdeckt), einen Einbau-Adapter für den letzten Button und nen neuen Drehknopf auch (den mache ich noch mal neu, der ist zu gross).
Wie ich die Joysticks verblenden soll, grüble ich noch...Anhang 34933
Sieht doch schon ganz nett aus (ich weiss, die Farben..... aber ich nehm, was grade da ist).
Muss mal wieder ein paar Rollen Filament besorgen.
Sodele.
Die Hardware dürfte fertig sein (es sei denn, mir fällt noch irgendwas ein).
Heute hab ich endlich mal die letzte Komponente noch verkabelt-der einzelnen Button.
Der ist mehr als ein simpler Knopf: er hat zusätzlich nen roten Ring eingelegt, der leuchten kann.
Den kann man auch separat steuern- ich werde den also als zusätzliche Anzeige benutzen (z.B. kann man ihn aufleuchten lassen, wenn das BT-Modul sich mit irgendwas verbunden hat).
Sehr praktisch- und sehr hübsch.
Damit ich später auch weiss, ob das BT-Modul sich mit _irgendwas_ koppeln konnte, habe ich die State-Leitung vom HC 05 auch noch an nen Digitalpin getüdelt.
Davon sind jetzt noch zwei Stück frei, hehe:
Aber ein paar analoge wären auch noch da, wenn sie gebraucht würden...Code:#define clockPin 13 // SPI Clock
#define csPin 12 // Chip-Select Display
#define mosiPin 11 // SPI-MOSI
#define statusPin 8 // High, wenn gekoppelt
#define bluetoothPin 7 // schaltet BT-Modul ein oder aus
#define ledPin 6 // die rote LED im Button
#define buttonPin 5 // der Button
#define encoderButton 4 // Button Encoder
#define encoderPinB 3 // zweiter Pin Encoder
#define encoderPinA 2 // erster Pin Rotationsencoder
#define lX A0 // X-Achse linker Stick
#define lY A1 // Y-Achse linker Stick
#define lB A2 // Button linker Stick
#define rX A7 // X-Achse rechter Stick
#define rY A6 // Y-Achse rechter Stick
#define rB A5 // Button rechter Stick
Ein bisschen ärgere ich mich jetzt, dass ich den Button nicht mit blauer Beleuchtung genommen hatte- das rot fällt ziemlich auf, hehe- aber man kanns auch sportlich nehmen und sagen "soll es ja auch".
Die Gehäuseteile sind inzwischen auch alle fertig gedruckt- die Abdeckungen für die Sticks waren grausam: bis die leidlich passten, hab ich sechs oder sieben Probeteile gedruckt...aber nun gehts.
Die kleinen Teile hab ich dann mit dem 3D-Stift kurzerhand von innen ins Gehäuse geschweisst.
Die hatte ich bewusst einzeln gezeichnet, und zwar so, dass man sie einsetzen, aber ein wenig hin und herschieben kann- so kann man alles schön anpassen, ohne die gesamte Abdeckplatte 15x zu drucken.
Dadurch, dass sie ihre Öffnungen aussen überlappen, sieht man davon jetzt nichts mehr.
Als nächstes muss jetzt der neue Button auch noch ne Anzeige im Display bekommen, keine grosse Sache: halt nen Kreis, der gefüllt dargestellt wird, wenn man den Button drückt- so ähnlich wie beim Encoder, nur ohne Wert in der Mitte eben.
Wenn die da ist, mach ich wiedermal ein Foto.
Hab eben mal eine Art kleines Video gemacht, von den bisherigen Funktionen.
Klick
Inzwischen bin ich noch ein kleines Stück weiter:
nach dem Einschalten werden die Sticks, nach einer kurzen Wartezeit, kalibriert (Wartezeit, damit man die Pfoten weg nehmen kann, das steht auch im Display), so weit waren wir schon.
Anschliessend fängt der Button an, zu blinken...solange er das macht (einige Sekunden) kann man ihn drücken, und damit die Fernsteuerung in den USB-Modus versetzen: das Bluetooth-Modul wird dann abgeschalten (genauer gesagt, gar nicht erst an), und man kann flashen, oder die seriellen Ausgaben im Monitor verfolgen. Dort kommt dann genau das an, was normal auch per Bluetooth gesendet würde...
Drückt man den Button nicht, wird ganz normal durchgestartet und das BT-Modul eingeschaltet.
Ich denke,das ist so ausreichend praxistauglich: wenn ich das Ding einfach nur benutzen will, schalte ich sie ein und muss mich nicht weiter drum kümmern.
Will ich in den USB-Modus, drücke ich halt mal den Button....
Insgesamt haben wir jetzt also vier analoge Kanäle, drei völlig frei verwendbare Buttons, zusätzlich nen Encoder, der quasi-analog arbeitet (tut er nicht, aber er kann, genau wie die Sticks, Werte zwischen 0 und 255 erzeugen), und den Button des Encoders, der allerdings den Encoder-Wert wieder auf 0 stellt. Daher ist der als Button nur eingeschränkt zu verwenden (wenn man den Encoderwert nich braucht, ist es kein Problem).
Ich denke, damit kann man erst mal eine ganze Menge anfangen...
Ein bisschen hab ich mal weiter codiert:
Es werden jetzt alle Werte tatsächlich auch per BT gesendet, in der Form:
lX128-> X-Achse links hat den Wert 128.
Auf die Weise geht das mit relativ wenigen Daten von statten-es werden _nur_ Änderungen gesendet.
Wenn man nix tut, dann nicht....
Die Auswertung auf der Gegenseite steht noch aus....ich denke aber, sehr schwierig wird das nicht.
Inzwischen merkt die Fernsteuerung auch, wenn sie sich mit irgendwem verbinden konnte (so lange sie das nicht hat, gibts ne Art "Fortschrittsbalken" im Display.
Ermittelt wird das über den STATE-Pin des HC-Moduls.
Das Nächste wird jetzt sein, dass sie, nach erfolgter Koppelung, die Gegenstelle fragt "wer bist du"- ich möchte den Namen des verbundenen Roboters dann im Display stehn haben.
Dazu brauch ich dann aber auch für den "Roboter" erst mal ein Software- Grundgerüst- momentan besteht der lediglich aus nem, neben das Steckbrett gespaxten Uno und einem weiteren HC 05-Modul, was lediglich per AT-Befehle passend konfiguriert ist.
Verbinden klappt-aber mehr kann das noch gar nich...allerdings hab ich die Tage schonmal einen kleinen Parser gebastelt, der Kommandos, die von der seriellen Schnittstelle kommen, auswertet-der muss aber noch aufgebohrt werden, um z.B. die Zahlen aus den eintreffenden Strings extrahieren zu können.
So nebenbei steigen meine Skills im RAM-Sparen, hehe: um diesen Fortschritts-Balken realisieren zu können (es werden einfach 1,2,3,4 Sternchen gezeichnet, und dann fängts von vorne an), brauchte ich ne Variable als Zähler-da hab ich kurzerhand eine der globalen, die an _dieser_ Stelle nicht gebraucht wird, mal eben ausgeliehen.
Somit _kein_ zusätzlicher Speicherverbrauch *freu
hallo,Zitat:
Zitat von Rabenauge
ich halte das für u.U. bedenklich bzw. gefährlich:
Folgender Fall:
wert lX128 gesendet und empfangen => alles ok, Empfänger führt entspr. Befehl aus (z.B. Motor links auf pwm128 )
danach
wert lX0 gesendet aber wegen Unterbrechung oder Block (Serial stream/buffer hardware/software sync/async wire/wireless) nicht empfangen => Empfänger führt immer noch entspr. alten Befehl aus (Motor links auf pwm128 statt 0), da sich für ihn nichts geändert hat.
Ganz abgesehen davon ist es ebenfalls denkbar, dass einzelne Bytes (l,X,1,2,8 ) durch Datenkorruption falsch übertragen bzw. empfangen werden - wie prüfst du auf Datenintegrität und korrekten Empfang? z.B.
wert lX128 gesendet aber wegen Datenkorruption falsch empfangen => Empfänger liest lY128 (anderer Motor auf pwm128 ) oder noch was ganz anderes
(edit: das müsste dann auf heartbeat und timeouts gecheckt und nach Rückmeldung auf Richtigkeit und Vollständigkeit überprüft werden; weitere Stichworte sind message-Startsignal, Ende-Signal, msg-Länge, checksum)
Zur Not kann er noch ein Paritätsbit mitsenden und auf der Gegenseite prüfen. Sehr genau beschrieben ist das hier: https://de.wikipedia.org/wiki/Parit%C3%A4tsbit
Eventuell kann das einfach so umgesetzt werden, dass man nur halbe Wertebereiche überträgt und das höchstwertige Bit als Paritätsbit verwendet.
Sollte kein Problem sein.
MfG
Heartbeat ist schon vorbereitet.
Ich habe schon einen Timer drin, der alle halbe Sekunde einen Tick erzeugt (den setze ich wahrscheinlich noch deutlich runter, in der Zeit), denn es stimmt: wenn das Stop-Signal nicht ankommt, fährt er endlos weiter.
Die HC 05 merken auch erst nach ungefähr zehn Sekunden, wenn die Verbindung weg ist-> zu lange.
Ich will also (wie gesagt, vermutlich wirds am Ende mindestens viermal pro Sekunde passieren) ein "alive" senden, und wenn das, sagen wir, zweimal, nicht kommt, weiss der Empfänger, dass da was faul ist, und kann sein fail-save aktivieren.
Auch richtig: gegen verstümmelte Signale hab ich noch nix...hat aber nicht das BT-Protokoll da sowieso was eingebaut?
Aber gut, dass der Einwand kam, ich werd das beim ausprobieren (vorerst sowieso nur trocken, mit dem UNO als Prügelknaben) mal im Auge behalten.