Forum: Mikrocontroller und Digitale Elektronik C-Libs for USB and OLED-Display


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von muuuh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Welches OLED Display?

von muuuh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von muuuh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich schaue es mir einmal an, schon einmal vielen Dank.

von muuuh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von muuuh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Niklas Gürtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mein USB-Tutorial mit STM32 basiert auf dem STM32F103 und nutzt C++, 
bietet aber keine komplett fertige Bibliothek.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Ist der Code Standard-C kompatibel?

Bool ist seit C99 im Standard enthalten.

von muuuh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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:
typedef union
{
  uint16_t memory;
  uint32_t placeholder;
} USB_Memory;

USB_Memory* mem = 0x40006000;

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?

von P.Loetmichel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Zu HID wisst ihr nichts, oder?

Vielleicht noch ein Freibier dazu?

von watz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von muuuh (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
muuuh schrieb:
> Wo genau fehlt da ein Cast und in was?

muuuh schrieb:
> USB_Memory* mem = 0x40006000;
muss
USB_Memory* mem = reinterpret_cast<USB_Memory*> (0x40006000);
sein, bzw. in C:
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!
  * @version V3.5.0
  * @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:
  * @version V4.2.0
  * @date    31-March-2017
und 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.

von muuuh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von muuuh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.