OBS Pro - Automatisiert bestückbare Hardware

Design & Entwicklung Elektronik & Gehäuse
#82

Hallo @fabian,

Wir benutzen die Karte im SPI Modus denke ich - das SD-Modul, das wir nutzen wird per an SPI angeschlossen und ist auch so beschriftet. Wir nutzen softwareseitig SD (spi basierte lib), nicht SD_MMC (glaube das wäre die library für den native SD modus von espressif).

Der Grund dürfte weniger eine bewusste Entscheidung sein, sondern mehr, dass der SPI Modus im Arduino Universum der bestdokumentierte Modus ist, in dem man auf die SD Karte zugreifen kann - weil nicht alle Microcontroller ein SD-Karten Interface haben. Und die OpenBikeSensor Firmware im Arduino Universum geboren wurde.

Falls für den nativen SD-Modus mehr Pins benötigt werden, könnte es auch sein, dass das SD-Modul, was im OBS Classic verwendet wird dafür gar nicht geeignet ist.

Das Problem mit dem SPI wäre dann evtl. doch noch ein Argument für die I²C variante des displays, je nach dem, wie lange das noch erhältlich ist.

#83

Moin,
danke für die Infos.
Also wenn die SD Karte aktuell im SPI Modus läuft, kann man das Display da ja einfach parallel hängen - hatte irgendwann mal im Hinterkopf dass der SPI Modus bei modernen SD Karten schon seit einigen Jahren nicht mehr funktioniert.
@j000bs hatte vor das mal zu testen, für Ergebnisse wäre ich dankbar.
Aktuell sehe ich eh nicht mehr, dass die Firmware für den OBSPro kompatibel zum classic bleiben kann bzw alles automatisch erkannt wird. Von daher könnte ich die SD jetzt halt ans SD interface hängen, müsste mich aber drum kümmern das ans laufen zu bringen.
Es wäre halt gut wenn SD und Display an einem Hardware SPI hingen, um bessere Performance zu haben. Die US-Sensoren können ruhig per bit-bang betrieben werden, da passiert ja fast nichts.

Fabian

#84

Hmm, irgendwie haut das mit dem SPi-Modus nicht so ganz hin. Warum geht der MOSI pin denn auf SD_CMD? Oder habt ihr irgend ein alternatives Pin-Muxing verwendet?

#85

Hallo,

Ja, nächsten Dienstag bin ich wieder bei der Hardware und kann mal testen, ob ich Display und SD-Karte gleichzeitig verkabelt und richtig angesprochen bekomme.

Wenn ich das richtig sehe sind im Schaltplan des OBS 0.03 als Pinbezeichnung für die SD-Karten die SD-bus-modus-Bezeichnugen verwendet, angeschlossen sind sie dann aber an den SPI-Bus.
Der englische Wikipedia-Artikel hat dafür zwei Tabellen. Der physische SD-Pin 2 bzw. Micro-SD-Pin 3 ist also bei SPI DI / MOSI, beim SD-Bus-Modus dagegen CMD.

#86

Schau mal in den Branch wip-simplify so wie es im readme steht. Dort ist die Versionsnummer 1.0.0-alpha.2

#87

Danke, den Branch hatte ich nicht auf dem Schirm.
Die Bezeichnungen und Anschlüsse von der SD-Karte sehen für mich aber gleich zur Version 0.03 aus.

#88

Danke für die Infos, das mit den anderen Pin-Bezeichnungen hatte ich auch gerade rausgefunden. Ich konnte aber nach etwas Suche im Source-Code nicht herausfinden ob/wie/wo der Chip-Select definiert wird. Der SPI scheint hardware-seitig nur einen dedizierten zu haben. Die Frage ist jetzt, ob ich die SPI-Schnittstelle einfach parallel mit einem GPIO als CS für anderen Krams verwenden kann. Die Hardware kann das sicher, aber ich blick durch die verwendeten Bibliotheken nicht durch. Die Variable/Instanz SD fällt im Code einfach vom Himmel.

#89

Die SD-Instanz kommt aus der Header-Datei der SD-Bibliothek, bei mir liegt die in ~/.platformio/packages/framework-arduinoespressif32/libraries/SD/src/SD.h.
Bei der SD.begin()-Funktion, die an verschiedenen Stellen in der OBS-FW vorkommt, kann optional der CS-Pin angegeben weden – gerade wird keiner angegeben und somit der default-Pin gewählt. Ich denke es sollte daher ohne Probleme möglich sein, für SD und SPI-Display separate CS-Pins zu nehmen. Ich fände es, damit die FW nicht komplizierter wird, dennoch sinnvoll, beim Standard-CS-Pin für die SD zu bleiben, und einen separaten Pin als CS für das Display zu nehmen (was U8g2 ja unterstützt).

#90

Hat geklappt. Ich habe dafür GPIO 12 als CS, GPIO 13 als D/C und GPIO 14 als Reset genommen, da die drei beim OBS Rev. 1.0.0-alpha2 noch frei sind.

Transreflexives OBS-Display
#91

Danke für die Info. Bin gerade dabei die letzten Sachen an der neuen Platine zu machen und ich hoffe, dass ich die heute noch raus schicken kann. Welcher GPIO für den CS ist ja eigentlich egal? Oder ist das nen besondere Pin-Muxing?
Ich lege da jetzt keinen Wert mehr drauf großartig kompatibel zu sein. Es wird so vieles etwas anders, dass man in der Firmware sowieso ne Pin-Map erstellen muss je nach Hardware-Version. Da habe ich lieber entspanntes routen.

#92

Ich denke welchen Pin man genau nimmt sollte egal sein, solange er als Output fungieren kann (wenn ich das das Datenblatt des ESP richtig lese ist das bei den Sensor-Pins GPIO 36 und 39 ja nicht der Fall).
Kann aber auch anbieten, nochmal schnell andere Pins zu testen (heute Abend bin ich noch ein paar Stunden online).

Dann gäbe es also für den OBS Pro eine separate Firmware-Varianten, die man etwa durch bedingte Kompilierung erzeugt?
Aus meiner Sicht okay, könnte sogar etwas Speicher sparen. Heißt nur auch, dass die Infrastruktur für die Auslieferung der Software (https://install.openbikesensor.org/ und der FUOTA-Server) eben mehrere Varianten anbieten können müssten. Soweit ich das einschätzen kann aber kein riesiger Aufwand.

#93

Das mit den Pins 4/5 (SENSOR_*) habe ich aufm Schirm :wink:
Ich denke wir kommen da nicht drum rum zwei Firmware-Versionen anzubieten. Klar kann der das Display automatisch erkennen, aber er kann nur über Umwege rausfinden, ob es ein Pro oder Classic ist. Da ich aber recht viele Pins brauche, kann ich nicht nur freie benutzen für die ganzen zusätzlichen oder anderen Features.
Hier ein Sneak-Peak:

OBSPro_3D
OBSPro_3D963×1122 99.1 KB

3 „Gefällt mir“
#94

Sieht sehr schick aus!
Was mir eben noch aufgefallen ist: Der letzte Stand auf dem pga460-branch von gestern hat noch das ESP32-WROOM-32 Modul, aktueller ist ja das ESP32-WROOM-32E. Der Footprint ist leicht anders, und die MCU auch etwas… Ich hätte zugunsten der Zukunftssicherheit wohl dennoch den 32E bevorzugt.
Spricht für dich etwas gegen den 32E?

#95

Öhhh, wenn das von der aktuellen Firmware so unterstützt wird, gerne. Das normale eap-32 scheint ja obsolet zu sein. Hatte da etwas Probleme das zu finden.
Gibt es denn da auch nen Plan auf was größeres als die 4MB Variante zu wechseln?

#96

Das mit µC tauschen war mir jetzt auf die Schnelle doch etwas zu heikel und habe das erstmal so gelassen. Platine und Bauteile sind bestellt. Der aktuelle Stand ist im pga460 branch:

Ich rechne mit den ersten aufgebauten Prototypen in 2-3 Wochen.

1 „Gefällt mir“
#97

Ich wusste es bei meinem letzten Post auch nicht – aber die MCUs sind wohl Binärkompatibel.
Im ESP32 Chip Revision v3.0 User Guide heißt es unter 2.2.:

  1. Software Design Changes:
    Client can continue to use the same software and binary for deployed product. The
    same application binary will work on both chip revision v1.0 and chip revision v3.0.
1 „Gefällt mir“
#98

Na das wäre ja top :slight_smile:

#99

Zwischendurch mal ein Update:
Ich habe in den letzten Tagen viel für den OBSPro gemacht. Es gibt zwei neue Prototypen, auf denen vor allem die Ultraschall-Schaltung komplett getauscht wurde und jetzt auf einem PGA460 basiert - den gab es damals nicht (bezahlbar) dank Chip-Krise. Hier habe ich gerade die ersten Daten ausgelesen bekommen:
grafik
Man sieht in etwas über 2m schön die Decke :slight_smile: und ein paar Mehrfachreflektionen zwischen Tisch und Decke bei Vielfachen davon :stuck_out_tongue:
Das Gemüse am Anfang muss ich noch in Griff bekommen. Man kann da so viel einstellen, ich bin erst mal froh ein Hello-Word am Laufen zu haben und dort sogar was erkennen zu können.

Leider funktioniert das GPS (was jetzt ein MAX-M10M ist) nicht mehr, das habe ich erst einmal bei Seite geschoben. Hier ist ein NMEA-Decoder notfalls schnell implementiert. Dann halt ohne Almanac-Daten für den Warm-Start. Der sollte trotzdem in < 30 Sekunden nen Lock bekommen. Also das GPS läuft, nur funktionieren die UBX-Kommandos scheinbar nicht mehr.

3 „Gefällt mir“
#100

Nach etwas Optimierung kann ich Autos bis ~6m problemlos erkennen (geht vermutlich auch noch mehr) und auch das Nachklingeln konnte ich deutlich reduzieren, womit auch Objekte ab ~20 cm zuverlässig detektiert werden.

grafik
grafik908×814 30.4 KB

Das rote ist die einstellbare Detektions-Schwelle, das orangene ist die erkannte Distanz.
Was auch interessant sein könnte: Der Sensor kann prinzipiell bis zu 8 Ziele erkennen und einem die Amplitude und auch Länge der Pulse sagen. Oder man kommt wie in dem Screenshot zu sehen auch an die Rohdaten ran, wobei die eine deutlich schlechtere Zeitauflösung haben (je nach Einstellung bei unser Anwendung 16x oder 32x schlechter). Rohdaten und Entfernungen/Breiten/Amplituden gehen gleichzeitig in einer Messung leider nicht.
Außerdem kann der Sensor auch noch die Temperatur messen, womit man die etwas unterschiedliche Schallgeschwindigkeit (ca. 0,6 m/(s*K)) kompensieren kann. Bei 20K Unterschied macht das schon 3,5% aus.
Als nächstes folgt die Integration meines Codes in den OBS Code. Evtl. könnte ich da noch mal die Hilfe von @andreas brauchen. Viele Funktionen, die die Ultraschall Manager Klasse hat, habe ich noch nicht verstanden.

4 „Gefällt mir“
#101

Ich denke ich habe die Ultraschall-Software fertig, wobei man bei diesem Spinnen-Netz von Software nicht sagen kann, ob man nicht irgendwo einen Faden vergessen hat.
Jetzt beiße ich mir die Zähne am GPS aus. Die UBX-Befehle, die bislang verwendet wurden sind zumindest teilweise nicht mehr verfügbar bzw wurden durch andere ersetzt. Jetzt stehe ich vor der Wahl das UBX-Zeugs anzupassen oder da einen NMEA-Decoder einzubauen. Die NMEA Nachrichten gehen scheinbar aktuell ins Nirwana.
Frage an die Experten: Gibt es irgendwo ne Doku was eigentlich am Ende in der cvs an Daten benötigt wird? Beim Ultraschall waren jetzt irgendwie nen Dutzend Funktionen, die ich nicht nach-implementiert habe (bzw. nicht konnte), die scheinbar nur Debug-Foo waren und nie wieder raus genommen wurden. Ich fürchte, dass das beim GPS auch so ist. Die Anzahl an public-Methoden ist ja wahnsinnig um ne Position und ne Uhrzeit zu bekommen.
Dazu kommt, dass auch die GPS-Klasse wieder von allem Möglichen abhängt, wovon sie nicht abhängen sollte (dem Display z.B.). Was mich zu einem anderen Problem führt: Gibts ne Möglichkeit das Kompilieren/Hochladen schneller zu machen? Aktuell brauche ich für beides zusammen knappe 2 Minuten - was den Debug-Prozess echt nervig macht. Beim US hatte ich mir dann nen extra Projekt gemacht. Das ging beim GPS aber so einfach nicht, weil das wie gesagt von allem Möglichen abhängt, wovon es nicht abhängen sollte.

1 „Gefällt mir“