Hallo,
ich bin derzeit auf der Suche nach zwei C-Libraries für die Ansteuerung
eines OLED-Displays für sowohl einen ATmega328P als auch für einen
STM32F103 sowie für USB für den STM32F103.
Habt ihr da Empfehlungen?
Wenn es keine fertigen gibt, sind auch gerne Vorschläge für z.B.
C++-Libs willkommen, die würde ich halt entsprechend umschreiben.
Ich frage nur lieber erst einmal hier, bevor ich mir für diese doch
anspruchsvolleren Aufgaben irgendetwas mühsam zusammenschustere, was
eigentlich bereits 5-mal gemacht wurde. Wichtig bei der Lib wäre, dass
diese OpenSource ist und ggf. auch modifiziert werden darf.
Danke!
Natürlich, das habe ich ganz vergessen zu erwähnen.
Ich gehe davon aus, dass es ein SSD1306 mit I2C ist. Ich weiß es
allerdings nicht mehr gesichert, da nichts draufsteht und ich das nur
zuföllig noch einmal in meiner Kramkiste gefunden habe.
http://stefanfrings.de/esp8266/WIFI-Kit-8-Test2.zip
Ist für ESP8266 unter Arduino vorgesehen, müsste theoretisch auch auf
anderen Mikrocontrollern laufen. jemand bestätigte, dass es auch auf
einem ATmega328 klappte.
Wenn du kein Arduino verwenden möchtest, musst du nur die wenigen
Codezeilen ändern, wo die Pins getoggelt werden.
Nachdem ich die Lib umgeschrieben habe, funktionierte es problemlos,
danke.
Kennt noch jemand eine Lib für USB für den STM32F103? Oder zumindest
einen verwandten Controller?
C++ oder C ist eigentlich tatsächlich egal, lässt sich relativ schnell
umschreiben.
> Kennt noch jemand eine Lib für USB für den STM32F103?
Siehe http://stefanfrings.de/stm32/index.html#usb
Mein Favorit ist die Variante, die W.S. hier veröffentlicht hat. Eine
für das Bluepill Board angepasste Version kannst du auf meiner Seite
herunterladen.
Okay, danke. Ich werde es mir einmal ansehen, wobei ich wohl frühstens
übermorgen dazu kommen werde.
Was mir allerdings jetzt gerade schon auffällt:
es wird der Datentyp bool verwendet ohne irgendwelche Header, die das
definieren (stdbool.h). Ist der Code Standard-C kompatibel?
Wobei das eigentlich auch nicht allzu schwer umzuschreiben sein sollte.
Was mir noch eingefallen ist, was ich für mein nächstes Projekt auch
noch brauchen werde:
gibt es USB-HID-Implementationen, die ihr empfehlen könnt, für den
STM32F1 oder muss ich das selbst zu der USB-Lib schreiben?
Danke auf jeden Fall.
Niklas Gürtler schrieb:> Mein USB-Tutorial mit STM32 basiert auf dem STM32F103 und nutzt> C++,> bietet aber keine komplett fertige Bibliothek.
Ja, das habe ich auch schon gefunden. Ich hatte gehofft, dass das vllt.
schon einmal jemand gemacht hat.
Aber dann werde ich mich einmal ans Schreiben machen.
Eine Frage noch: könnte ich nicht auch statt dem Linkerscript folgendes
machen:
1
typedefunion
2
{
3
uint16_tmemory;
4
uint32_tplaceholder;
5
}USB_Memory;
6
7
USB_Memory*mem=0x40006000;
8
9
mem[x].memory;
Stefanus F. schrieb:>> Ist der Code Standard-C kompatibel?>> Bool ist seit C99 im Standard enthalten.
Okay. Ich dachte nur, dass man dafür <stdbool.h> inkludieren muss.
Zu HID wisst ihr nichts, oder?
Stefanus F. schrieb:> Ist für ESP8266 unter Arduino vorgesehen, müsste theoretisch auch auf> anderen Mikrocontrollern laufen. jemand bestätigte, dass es auch auf> einem ATmega328 klappte.
Dieser jemand war wohl ich. Wobei ohne Anpassung (auf TWI statt
Bitbanging) die I2C Geschwindigkeit wirklich madig ist. Hatte das auch
nur getestet um Stefan eine Rückeldung geben zu können und ein Pro Mini
eh gerade da war.
muuuh schrieb:> Eine Frage noch: könnte ich nicht auch statt dem Linkerscript folgendes> machen:
Ja müsste auch gehen, aber da fehlt ein Cast, und unions würde ich ohne
Not nicht benutzen. Ich finde das mit dem Linker-Script wesentlich
schöner.
muuuh schrieb:> Okay. Ich dachte nur, dass man dafür <stdbool.h> inkludieren muss.
Muss man. stdbool.h ist Teil des Standards.
muuuh schrieb:> Zu HID wisst ihr nichts, oder?
ST selbst bietet umfangreiche USB-Libraries, auch für HID. Deren Aufbau
finde ich aber nicht so toll, und passt auch nicht zum Tutorial.
> Dieser jemand war wohl ich. Wobei ohne Anpassung (auf TWI statt> Bitbanging) die I2C Geschwindigkeit wirklich madig ist.
Ich denke, dass hier das Arduino Framework auch noch eine Rolle spielt.
Aber ja, wenn man eine TWI Schnittstelle nutzen kann, sollte man das
natürlich auch tun. Wie gesagt war diese Implementierung für den ESP8266
vorgesehen, da ging es nicht anders und dank der 80Mhz lief es dort auch
schnell.
Entschuldigung, dass ich erst jetzt wieder antworte.
Ich hatte leider in den letzten Tagen absolut keine Zeit, mich dem Thema
zu widmen.
Niklas G. schrieb:> Ja müsste auch gehen, aber da fehlt ein Cast, und unions würde ich ohne> Not nicht benutzen. Ich finde das mit dem Linker-Script wesentlich> schöner.
Wo genau fehlt da ein Cast und in was?
Und weshalb eigentlich keine Unions? Die gibt es doch nicht umsonst.
Ich bevorzuge eben eigentlich ein einheitliches Linkerscript.
Das vereinfacht einfach vieles.
Niklas Gürtler schrieb:> Mein USB-Tutorial mit STM32 basiert auf dem STM32F103 und nutzt> C++,> bietet aber keine komplett fertige Bibliothek.
Ich versuche jetzt gerade einmal dieses Tutorial durchzuarbeiten, damit
ich auch ein bisschen Ahnung von der Materie bekomme.
Allerdings habe ich ein Problem: in "stm32f10x.h" wird das Makro USB
nicht definiert und es gibt auch keinen Typen USB_TypeDef wie sonst
immer. Es gibt auch kein anders benanntes struct mit den entsprechenden
Registernamen.
Es gibt nur die ganzen Definitionen für die einzelnen Bits in den
Registern.
Woher bekomme ich aber die USB-Register?
Anbei einmal die Header-Datei.
muuuh schrieb:> Und weshalb eigentlich keine Unions?
Weil man da immer sehr genau aufpassen muss auf was man wann zugreift.
unions erlauben weniger als oft angenommen wird :-) Da würde ich lieber
eine Lücken-Variable einfügen, das ist unverfänglicher.
muuuh schrieb:> Die gibt es doch nicht umsonst.
Die gibt es ausschließlich zum Sparen von Speicherplatz.
muuuh schrieb:> Ich bevorzuge eben eigentlich ein einheitliches Linkerscript.
So etwas ist halt leider nicht in den Standard-Linkerscripten drin, aber
es schadet ja nicht das grundsätzlich dort einzubauen, auch wenn man es
nicht braucht.
muuuh schrieb:> Allerdings habe ich ein Problem: in "stm32f10x.h" wird das Makro USB> nicht definiert und es gibt auch keinen Typen USB_TypeDef wie sonst> immer.
Die Datei ist ja auch uralt!
Niklas G. schrieb:> muuuh schrieb:>> Wo genau fehlt da ein Cast und in was?>> muuuh schrieb:>> USB_Memory* mem = 0x40006000;> mussUSB_Memory* mem = reinterpret_cast<USB_Memory*> (0x40006000);sein,> bzw. in C:USB_Memory* mem = (USB_Memory*) 0x40006000;
Wird das nicht implizit gemacht?
> muuuh schrieb:>> Ich bevorzuge eben eigentlich ein einheitliches Linkerscript.> So etwas ist halt leider nicht in den Standard-Linkerscripten drin, aber> es schadet ja nicht das grundsätzlich dort einzubauen, auch wenn man es> nicht braucht.
Das stimmt natürlich tatsächlich.
Ich werde es mir überlegen, danke. Wobei du mich überredet hast, dass
man wenn dann lieber structs nimmt.
> muuuh schrieb:>> Allerdings habe ich ein Problem: in "stm32f10x.h" wird das Makro USB>> nicht definiert und es gibt auch keinen Typen USB_TypeDef wie sonst>> immer.> Die Datei ist ja auch uralt! * @version V3.5.0> * @date 11-March-2011Die hier:> http://www.st.com/en/embedded-software/stm32cubef1.html (Download ganz> unten) enthaltene Register-Datei "stm32f103xb.h" (auch komplett ohne> HAL/Cube-Zeug nutzbar) ist: * @version V4.2.0> * @date 31-March-2017und enthält das Gewünschte:#define USB> ((USB_TypeDef *)USB_BASE)> typedef struct> {> __IO uint16_t EP0R; /*!< USB Endpoint 0 register, Address offset: 0x00> */> ...> } USB_TypeDef;Hier wird übrigens auch mit Variablen als Lückenfüller und> nicht mit> unions gearbeitet.
Tatsächlich, danke. Die habe ich noch aus der alten StdPeriphLib
herausgesucht.
Einziger Nachteil bei den neueren ist, dass die gerätespezifischer sind.
Aber darüber werde ich wohl hinwegkommen.
Als kleine Anmerkung auch noch für dein Tutorial:
du könntest sonst noch ergänzen, dass das Bluepill-Board keinen USB-DP
pullup Widerstand Transistor hat und das Nucleo-F103RB-Board einen
NPN-Transistor dafür an PA15 hat.
muuuh schrieb:> Wird das nicht implizit gemacht?
Nein, Integer <-> Pointer ist zu "gefährlich". Rein technisch ist in
C(++) nicht einmal festgelegt, dass ein Pointer eine Speicher-Adresse
enthält; eine Implementation könnte da auch eine Referenz-Nummer wie in
Java ablegen. Daher ist das Angeben einer fixen Adresse nicht so direkt
vorgesehen und muss mit einem Cast "freigeschaltet" werden. Oder man
hält es halt per Linker-Script ganz aus dem Code heraus.
muuuh schrieb:> Einziger Nachteil bei den neueren ist, dass die gerätespezifischer sind.
Der Vorteil ist, dass man so nicht versehentlich etwas nutzen kann, was
gar nicht existiert! Inkludiere einfach die stm32f1xx.h, die inkludiert
dann automatisch die richtige - man muss dann noch z.B. per
Compileroption z.B. das "STM32F103xB" definieren, um den konkreten
Controller auszuwählen.
muuuh schrieb:> Als kleine Anmerkung auch noch für dein Tutorial:
Danke für den Hinweis! Aber beim Nucleo ist die USB-Buchse doch eh nur
mit dem ST-Link verbunden?
> Aber beim Nucleo ist die USB-Buchse doch eh nur> mit dem ST-Link verbunden?
Die Frage ist ein bisschen zweideutig.
Die USB Buchse des ST-Link Adapter ist mit dem µC des ST-Link Adapters
verbunden. Sie ist zum Programmierem und Debuggen vorgesehen.
Der USB Port des Target µC ist nicht als USB Buchse herausgeführt. Wer
diese nutzen möchte, ist mit einem anderen Board vielleicht besser
bedient, falls man nicht löten möchte.
Niklas G. schrieb:> muuuh schrieb:>> Als kleine Anmerkung auch noch für dein Tutorial:> Danke für den Hinweis! Aber beim Nucleo ist die USB-Buchse doch eh nur> mit dem ST-Link verbunden?
Da habe ich mich tatsächlich vertan, Entschuldigung.
Der NPN-Transistor ist an dem PA15-Pin vom STM32F103CBT6, also dem
ST-Link-µC.
Zwischen der USB-Buchse und dem eigentlichen F103RB besteht doch keine
Verbindung, wie ich annahm.
Eigentlich echt schade, was meiner Meinung nach den Wert des Boardes
doch ein wenig mindert.
Werde ich für das Projekt doch auf ein Bluepill-Board ausweichen. Sollte
aber eigentlich auch reichen.
Thread beobachten
Seitenaufteilung abschalten