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.
Mein USB-Tutorial mit STM32 basiert auf dem STM32F103 und nutzt C++, bietet aber keine komplett fertige Bibliothek.
> Ist der Code Standard-C kompatibel?
Bool ist seit C99 im Standard enthalten.
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 | typedef union |
2 | {
|
3 | uint16_t memory; |
4 | uint32_t placeholder; |
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?
> Zu HID wisst ihr nichts, oder?
Vielleicht noch ein Freibier dazu?
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: > Wo genau fehlt da ein Cast und in was? muuuh schrieb: > USB_Memory* mem = 0x40006000; muss
1 | USB_Memory* mem = reinterpret_cast<USB_Memory*> (0x40006000); |
sein, bzw. in C:
1 | USB_Memory* mem = (USB_Memory*) 0x40006000; |
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!
1 | * @version V3.5.0 |
2 | * @date 11-March-2011 |
Die 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:
1 | * @version V4.2.0 |
2 | * @date 31-March-2017 |
und enthält das Gewünschte:
1 | #define USB ((USB_TypeDef *)USB_BASE)
|
2 | typedef struct |
3 | {
|
4 | __IO uint16_t EP0R; /*!< USB Endpoint 0 register, Address offset: 0x00 */ |
5 | ...
|
6 | } USB_TypeDef; |
Hier wird übrigens auch mit Variablen als Lückenfüller und nicht mit unions gearbeitet.
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?
:
Bearbeitet durch User
> 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 abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.