Nucleo F103 + mbed

Ich kenne mbed nicht.

Die STM32F1 Mikrocontroller starten mit internem 8Mhz R/C Oszillator.

Per Software kann man dann auf eine externe Taktquelle umstellen und 
wenn man will die Taktfrequenz per PLL erhöhen.

Das Nucleo Board hat eine Verbindung vom 8Mhz Quarz-Oszillator des 
ST-Link Adapters zum Takteingang des STM32F1 Mikrocontrollers. Diese 
Verbindung kann man nutzen, muss man aber nicht.

> Woher weiss der Compiler, mit welcher Frequenz der Controller
> eigentlich arbeitet bzw. wo sage ich es ihm?

Im Gegensatz zu AVR muss der Compiler das gar nicht wissen.

Alle mir bekannten Frameworks bauen auf der CMSIS Library auf, die ARM 
standarisiert hat. Sie sieht vor, dass es diese globale Variable gibt:

1

uint32_t SystemCoreClock=8000000;

Wenn das programm die Taktfrequenz ändert, soll es diese Variable 
entsprechend aktualisieren. Ich schätze, daß diese Variable auch bei 
mbed existiert.

Verzögerungen werden normalerweise mit dem SysTick Timer realisiert, der 
Bestandteil des ARM Kerns ist. Er wird vom Programm so initialisiert, so 
daß er z.B. jede Millisekunde einen Interrupt generiert, womit eine 
Variable hochgezählt wird (wie bei Linux und Windows auf dem PC). Er 
muss beim Wechsel der Taktfrequenz neu konfiguriert werden.

Ob wait() diesen Timer verwendet, solltest du prüfen.

> Funktioniert der download eigentlich wenn der Zielprozessor
> gar keinen Takt hat?

Nein, aber beim Reset hat er immer einen Takt, nämlich den internen 8Mhz 
R/C Oszillator.

> X3 ist nicht bestückt

Ja, die haben sich einfach einen Quarz gespart und borgen sich 
stattdessen den Quarzgenauen takt des ST-Link. Aber wenn du den 
abbrichst und den µC mit einem Quarz takten willst, dann musst du ihn 
nachrüsten und die Brücken entsprechend anpassen.

Das könnte Dich interessieren: http://stefanfrings.de/stm32/index.html

Wie hast du das kompiliert, mit dem Online Compiler? Da musst du ja 
vorher die Hardware angeben und dann ist zu den Boards passend die 
Peripherie in den defines. Wenn du auf die Konstante LED1 mit der Maus 
zeigts sollte im Online Compiler rechts oben Hilfe erscheinen die du 
anklicken kannst.
Alternativ kannst du für LED1 auch einen PortPin (etwa PC_13 oder sowas) 
angeben, nutze dazu die bunte Hardwaremap die es zu jeder unterstützen 
mbed Hardware gibt.
Der Takt wird in der mbed Lib für die meisten boards auf max. gestellt. 
Wenn das Board den Quarz per default nicht drauf hat wird das schon 
richtig initialisiert (über die PLL).
Damit sollte auch die Zeit in wait() korrekt sein. Da wird auch nicht 
einfach der SysTick benutzt sondern ein Timer wird auf 1 µs gestellt und 
die Timer sind Ereignisse die nach der eingestellten Zeit auslösen.
Leider hatte diese Implementierung beim F103 mit einem 16 Bit Timer 
lange Zeit nicht richtig funktioniert, die ist aber vor kurzem 
überarbeitet worden. Wenn du das Programm in den Online Compiler 
importiert hast solltest du auf die mbed Lib im Projekt klicken und 
rechts auf 'update' wenn das enabled ist, sonst wird evtl. eine ältere 
Version verwendet.

Nachtrag:
LED1 ist PA_5:
https://developer.mbed.org/users/mbed_official/code/mbed-dev/file/default/targets/TARGET_STM/TARGET_STM32F1/TARGET_NUCLEO_F103RB/PinNames.h
Bei mir blinkts (grüne LD2 auf dem Board).

Operator S. schrieb:
> Hast du die beiden Jumper bei ST-LINK gesetzt?
ja
> Jumper für Stromversorgung über USB gesetzt? Auf U5V stellen.
ja
>> Fragen: wo steht eigentlich, an welchem Port LED1 hängt?
> in PinNames.h
Und wo steht die?

Das board habe ich beim Start angegeben.
Die beiden Lötbrücken MCO habe ich jetzt draufgepappt, ändert nichts. Da 
blinkt nichts. Die rote (power) ist an.
Anbei mal das erzeugte binary (geil, 20kB für ne blinkende LED :-)
Vielleicht kann das mal jemand auf so ein board schaufeln.

Ich dachte, das wäre einfacher.

funktioniert nicht. Im Anhang ist mein blinky.

Den Link auf die PinNames.h hatte ich meinem Link angehängt, findest du 
auch in Boardbeschreibung auf mbed 
https://developer.mbed.org/platforms/ST-Nucleo-F103RB/

Hattest du die Lib aktualisiert?

Nachtrag:
korrektur, deine Version funktioniert doch, 0.2 s an 1.0 s aus.

Hm, das ist ja dann ein toller Start. Dein Programm funtioniert bei mir 
auch nicht.
Das heisst dann entweder Hardwaredefekt (war noch OVP) oder bei der 
C-01-Version liegt die LED an einem anderen Port?

hier sind noch die Jumper, wenn ich IDD oder PWR rausnehme blinkts auch 
nicht. Die Quarze X2 und X3 sind auch nicht bestückt.

Auf der Rückseite steht auch MB1136 C-01

Genauso schaut es bei mir auch aus.

DigitalOut myled(PA_3);

Das ist der Arduino-connector D0, da tut sich auch nichts :-(
So kann man fast einen ganzen Tag vertun, um eine popelige LED nicht 
blinken zu lassen.

Aber ich gebe noch nicht ganz auf, meist sitzt das Problem ja doch vor 
dem Bildschirm.

Die Binärdatei wird einfach direkt ins Hauptverzeichnis NUCLEO 
geschoben?

Gerhard schrieb:
> Die Binärdatei wird einfach direkt ins Hauptverzeichnis NUCLEO
> geschoben?

ja, richtig. Nach einem Refresh ist die sofort wieder weg.

Ich habe jetzt noch ein Update auf den aktuellen STLink Treiber und die 
STLink/v2 Firmware gemacht, es hatte aber auch vorher schon 
funktioniert.

Hast du ein Terminalprogramm an dem virtuellen Com Port des Boards? Da 
könntest du ein printf("HelloWorld\n"); probieren. Über den virtuellen 
COM port werden auch Fehler ausgegeben wenn man z.B. ein SPI anlegt mit 
Pins die nicht passen. Da habe ich gerade gesehen das der SPI_CS Pin 
falsch definiert ist.

Gerhard schrieb:
> Genauso schaut es bei mir auch aus.

Der Screenshot sieht nach Windows 10 aus, da gibt es einige 
Problemberichte, auch mit dem Arduino Zeug.

Das Firmware Update könnte hier tatsächlich die Lösung sein, in der 
STSW-LINK009 History steht 'Updated Features to add Windows10 in the 
list of supported systems.'

Ja, ist Windows10.
Dann werde ich noch das Treiberupdate probieren. Habe auch noch einen 
Win7-Rechner, das wäre natürlich auch noch eine Option.
Und wenn das alles nichts hilft schmeiss ich den Kram weg.

Gerhard schrieb:
> Aber: tut nichts, blinkt nicht. Aber einfcher kann ja ein Programm nicht
> sein

Wie blauäugig muß man sein, um derart sein Projekt anzugehen?

Hast du denn nicht das Datenblatt und das Referenzmanual wenigstens 
einmal angeschaut? Erwartest du, daß sich der µC selbst programmiert, um 
die Pins, den Takt, die Peripherie-Clocks, die Systemuhr und so weiter 
richtig aufzusetzen, damit du mit so einem Dreizeiler deine LED blinken 
siehst?

Setz dich einfach mal hin und lies die Dokumente, um das ganze verstehen 
zu lernen. Das ist der wirkliche Anfang  - und nicht Blinky!

W.S.

Schmarrn. Genau das was Gerhard gemacht hat funktioniert bei mir. 
Einziger Unterschied bis jetzt: das Host OS das eigentlich nix damit zu 
tun haben soll.

Dann biete ich mal ein mit CubeMX und SW4 erzeugtes Blinky zum Test an.
Hat mich eigentlich noch nie im Stich gelassen.

https://www.youtube.com/watch?v=BrMw5TNQROo

pegel schrieb:
> Dann biete ich mal ein mit CubeMX und SW4 erzeugtes Blinky zum
> Test an.
> Hat mich eigentlich noch nie im Stich gelassen.

Das blinkt bei mir auch, aber das Problem ist eher wie Win10 den USB 
Massenspeicher behandelt. Da gibt es unterschiedlichste Fehlerbilder und 
es gibt es auch Win10 Versionen bei denen es klappt.

Alternativ geht kann man noch probieren den Nucleo über die Debug 
Schnittstelle zu programmieren, also z.B. mit dem STLink Tool das bin 
file schreiben lassen. Auch das funktioniert bei mir, habe aber nur Win7 
zum Testen hier.

@W.S. du bist ja ein toller.
In der Tat habe ich ein bisschen was davon angesehen und beschlossen, 
dass ich das nicht kapieren werde. Nach Recherchen bin ich ja gerade auf 
mbed (alternativ Arduino) gekommen, die mir diesen Teil abnimmt, die 20k 
müssen ja auch irgendwas machen.
Ja, ich weiss, ist verpönt, mir aber egal. Ich will einfach mal ein 
bisschen damit spielen und dann schaue ich weiter.

So, und jetzt wird es interessant:
update ist erst mal fehlgeschlagen.
Aber auch ohne update funktioniert das Programm von pegel, grüne LED 
blinkt, ca. 0,5s/0,5s.
Also scheint weder das Nucleo-board fehlerhaft zu sein noch das ein 
Windows/Treiberproblem vorzuliegen.
Und das von mir erstellte "Programm" funktioniert bei johannes aber bei 
mir nicht.
Muss man das verstehen??

Da ist wohl auch noch ein Problem.

Gerhard schrieb:
> @W.S. du bist ja ein toller.

so kennen wir ihn, nicht aufregen.

Wie gesagt, das ST-Link Utility STSW-LINK004 wäre noch interessant, das 
installiert auch die richtigen Treiber und startet das Firmwareupdate 
wenn ein ST-Link gefunden wurde.

Probier doch mal das mbed blinky aus dem Video oben.
Nicht das es wieder an irgendwelchen Sonder- oder Leerzeichen im 
Verzeichnis oder Dateinamen liegt.

Gerhard schrieb:
> DigitalOut myled(PA_3);

Hab nicht noch mal alles durchgelesen, aber die Grüne hängt an PA5.

pegel schrieb:
> Nicht das es wieder an irgendwelchen Sonder- oder Leerzeichen im
> Verzeichnis oder Dateinamen liegt.

da würde doch ein einfaches umbenennen helfen.

pegel schrieb:
> aber die Grüne hängt an PA5.

so ist die auch im mbed Programm. Und auf meinem Board läuft Gerhards 
Programm ja (bei mir unter Win7 auf den USB MSD kopiert).

@ Gerhard,

benenne deine erzeugte Datei vor dem kopieren in etwas einfaches um, wie 
z.B. blinky.bin
Möglicherweise macht W10 aus dem *_.bin etwas anderes?

pegel schrieb:
> Nicht das es wieder an irgendwelchen Sonder- oder Leerzeichen im
> Verzeichnis oder Dateinamen liegt.

Ich glaub mich laust der Affe - das wars.
PA_3 war nur drin, um mal einen anderen Port auszuprobieren.

Vielen Dank Leute für die Geduld, besonders Johannes und Pegel, excl. 
W.S.

Jetzt die serielle Verbindung hinbekommen und einen CAN-Transceiver dran 
und mich dann der eigentlichen Aufgabe widmen. Ich glaub, das wird ne 
lange Nacht.

Gerhard schrieb:
> Ich glaub mich laust der Affe - das wars.

Glückwunsch - bzw. traurig, mit Win10 zurück zu DOS? Immer noch 
komisch...

In den 20k sind übrigens noch Debug printf() drin die im Fehlerfall 
Klartext Meldungen auf den virtuellen COM Port ausgeben.
Man kann auch mbed_dev statt mbed importieren und das Macro NDEBUG 
setzen, aber alleine der mbed_dev import dauert einige Minuten und das 
kompilieren braucht dann auch länger. Die 128k von dem Käfer muss man 
aber erstmal voll kriegen, deshalb würde ich das nicht machen.

Sinn macht das wenn man debuggen und ins eingemachte gehen möchte, wenn 
man das Projekt exportiert hat man das komplette OS mit Quellen im 
Projekt.

Alternativ kann man auch mbed-cli installieren, das sind erstmal einige 
Python basierende Tools und man kann ein Projekt in der Kommandozeile 
mit 'mbed compile' übersetzen. Und auch von da aus mit 'mbed export' ein 
Projekt für eine IDE oder auch GNU make erzeugen. Die Exporter 
funktionieren nicht in allen MCU/IDE Kombinationen, aber ST ist da sehr 
engagiert und da funktioniert vieles besser als z.Zt. bei älteren LPCs. 
Gut läuft da die Kombi Eclipe + GNU ARM Eclipse Plugin + GNU ARM 
toolchain nach Wahl. Wenn man nicht nur auf den Online Compiler 
angewiesen sein möchte und auch mal durch die Quellen steppen möchte.

Johannes S. schrieb:
> das ST-Link Utility STSW-LINK004 wäre noch interessant

Super, das hat problemlos geklappt :-)
Jetzt funktioniert auch der download mit den vorher nicht 
funktionierenden  Dateinamen und auch der STLink Virtual COM Port. Es 
entwickelt sich.

Gerhard schrieb:
> @W.S. du bist ja ein toller.
> In der Tat habe ich ein bisschen was davon angesehen und beschlossen,
> dass ich das nicht kapieren werde.

Ah ja.

Du willst musizieren ohne dein Instrument spielen zu können.
Und üben willst du auch nicht.
Genau DAS ist es, was mir weiter oben zu denken gegeben hat.
Wozu soll das führen?

Nachdem du schon keine Ahnung vom verwendeten µC haben WILLST, ebenso 
nicht mal in der Lage warst, aus eigener Kraft herauszubekommen, an 
welchem Pin deine LED hängt, willst du "Jetzt die serielle Verbindung 
hinbekommen" und dann obendrein noch "einen CAN-Transceiver dran" und 
dann dich "der eigentlichen Aufgabe widmen".

Und das alles, ohne auch nur im Geringsten über das Pferd, was du reiten 
willst Bescheid zu wissen - ja nicht einmal wissen zu WOLLEN?

W.S.

So, es hat sich viel getan - ich bin begeistert.
Jetzt habe ich aber ein Problem mit der SPI, die ist einfach zu langsam.
Code aufs nötigste runtergebrochen:

#include "mbed.h"
SPI device (D4, D5,D3);

int main() {
device.frequency (16000000);
    while(1) {
        device.write(0xFF);
        device.write(0xFF);
        device.write(0xFF);
        wait_us(400);
    }
}

Es soll ein ADC (ADS8317) mit bis zu 100kSPS angesteuert (variabel, 
FFT). Da komme ich bei weitem nicht hin. Im Bild die 3x8SPI-clks. Woher 
kommen die "Kunstpausen" zwischen den einzelnen Bytes? Und vor allem: 
wie kann man es besser (schneller) machen?

Ich würde es mal ohne Framework versuchen.

Du hast da eine ganz typische Situation: Du willst eine vermeintlich 
einfache Aufgabe mit einem komplexen Framework erledigen. Es tut irgend 
etwas, was du nicht befohlen oder nicht erwartet hast.

Um das Problem zu lösen, müsstest du jetzt die Quelltexte des Frameworks 
auseinander nehmen. Fremden Code zu lesen, ist aber viel schwerer als 
eigenen Code.

Hast du einen wichtigen grund, das Framework für diese Pillepalle 
Aufgabe zu verwenden? Wenn nicht, dann programmiere den Mikrocontroller 
selbst, ohne dazu irgendwelche vorgefertigtren Klassen zu verwenden.

Und tu Dir einen gefallen: Wechsle nicht nach Arduino, dadurch wird 
zumindest langfristig nichts besser.

Ichnhabe mir gerade mal die Doku zur SPI Klasse angesehen. Das ist ja 
ein schlechter Witz - genau so oberflächlich wie bei Arduino. Da kann 
ich echt nur raten: Wenn es nicht zum Glück auf Anhieb klappt, dann 
schmeiß weg den Kram und programmiere selbst. Du kannst es besser, wenn 
du willst.

Die Pausen kommen durch das nachladen und das Polling für den Status. 
Die STM Implementierung basierst auf der STM HAL und die ist nicht die 
schnellste. Der F103 kann soweit ich weiß auch kein 24 Bit SPI in 
Hardware, du könntest probieren die Schnittstelle auf 32 Bit zu stellen 
und testen ob der ADC die überflüssigen Bits ignoriert.
Für den F103 ist eventuell auch die Asynchron Implementierung drin, die 
ist aber auch nicht schneller.
Dann gibt es noch eine BurstSPI Lib, die macht kein read nach dem write, 
spart Zeit aber dürfte beim ADC nix nutzen.
Und für die speziellen Features wie DMA gibt es auch 3rd Party Libs, da 
müsstest du die Suche bei mbed bemühen.
Als letztes bleibt natürlich noch das Datenblatt rauszuholen und selber 
bauen damit W. S. recht behält :)

Ps: oder nimm einen LPC von NXP, die sind da um Längen schneller und 
können 24 Bit in HW.

16bit habe ich auch schon probiert, hat irgendwie ein Eigenleben, was 
mir nicht gefällt, sendet von sich aus 2x16bit?
#include "mbed.h"

SPI device (D4, D5,D3);

int main() {
device.frequency (16000000);
device.format (16,0);
    while(1) {
        device.write(0xAAFF);
        //device.write(0xFF);
        //device.write(0xFF);
        wait_us(400);
    }
}

Mag ja sein, dass es besser wäre, mehr oder weniger alles zu Fuss zu 
machen, aber dafür bräuchte ich glaube ich Wochen, wenn ich es überhaupt 
schaffen würde.
Bei der PC-Programmierung nimmt man ja auch völlig selbstverständlich 
mächtige Werkzeuge in die Hand. Und wenn ich Metall sägen will, nehme 
ich ne "Eisensäge", ohne Ahnung von den einzelnen Zähnen zu haben. 
Funktioniert von Blei bis Stahl. Wahrscheinlich für kein Metall perfekt, 
aber ausreichend funktionierend. Brauch ich Höchstleistungen, brauche 
ich ne spezielle Säge. So sehe ich das hier auch, ich brauche nicht 
maximale performance, sondern ausreichende.
Wenn die SPI allerdings eigenständig 8fache Bytezeit Pause macht, ist 
das nicht ausreichend, sondern unterirdisch.

Hm, mit dem 2x16bit-Problem bin ich wohl nicht allein:

https://developer.mbed.org/forum/bugs-suggestions/topic/27200/?page=1#comment-52577

Und nochmal verschiedene clk-Raten probiert. Es bleibt immer eine Pause 
von knapp 10µs zwischen den einzelnen bytes, was letztendlich eine 
maximale effektive Bitrate <100kbit bedeutet. Und das bei einem 
tatsächlichen Bittakt von bis zu 18MHz - das nenne ich mal erfolgreich 
kastriert :-(

Nagut, muss ich wohl doch tiefer einsteigen als gewollt. Jetzt lege ich 
den Kram erst mal zur Seite.

Mit der SPI Hardware der STM32 hatten hier im Forum schon einige 
Probleme, du findest hier mehrere Threads dazu. Die Hardware ist so 
zickig das selbst ST da lange braucht das in den Griff zu bekommen. Der 
SPI Teil bekommt seine Daten und arbeitet dann asynchron weiter, aber 
die SW muss wissen wann die nächsten Daten eingeschoben werden dürfen, 
da hakt das irgendwie. Ich hatte gestern auch noch mal kurz geschaut und 
im ST Forum war ein Stück mit 8x _DSB() Befehlen nacheinander, das sieht 
auch irgendwie krank aus.

Aber trotzdem eine gute Nachricht:
Der Fehler mit den doppelten Takten ist schon länger bekannt und jetzt 
wurde ein Fix gemerged und sollte in wenigen Tagen auch im Online 
Compiler drin sein. Dieser nutzt jetzt LowLevel Funktionen der HAL und 
soll schneller sein. Wie gross die Differenz ist weiss ich nicht, kann 
ich evtl. mal am Wochenende testen.
https://github.com/ARMmbed/mbed-os/issues/3445
https://github.com/ARMmbed/mbed-os/pull/4375

Ansonsten wäre eben das ganze Konzept zu überprüfen ob nicht DMA besser 
ist für die Übertragungen, das ist allerdings auch nicht einfach. Oder 
eben mit der Async Variante spielen.

Johannes S. schrieb:
> Mit der SPI Hardware der STM32 hatten hier im Forum schon einige
> Probleme, du findest hier mehrere Threads dazu.

Jo...

Selbst wenn die 16bit-Übertragung bald funktioniert hilft mir das nicht. 
Ich brauche 24bit. Ok, vielleicht gingen 32 Takte auch, muss ich mal 
schauen/probieren. Aber wenn die Pause dann auch zwischen den 2 
16bit-Zugriffen bleibt ist das immer noch zu langsam, da komme ich auf 
keine 100kSPS.

So ganz schlau bin ich immer noch nicht geworden.
Liegt es an der STM32-SPI selbst?
Am HAL?
An mbed?
Einer Mischung aus allem?
Wäre es mit o.g. LPC tatsächlich besser? Oder mit einem F4 oder L4?

Hat alles so schön und problemlos funktioniert (FFT, CAN und XBee) und 
dann hängt man an so einer popeligen, eigentlich trivialen 
Schnittstelle? So kann man sich vertun, da hätte ich keine Probleme 
erwartet. Das ist eben der Unterschied zwischen Erfahrung und eben 
keiner.
Na, zum Glück habe ich noch keine Platinen machen lassen.
I2C reicht auch nicht. Und einen Wandler mit Parallelinterface will ich 
nicht LOL

Gerhard schrieb:
> Einer Mischung aus allem?

ich behaupte 'ja', wobei mbed das User API meist als nahezu leere C++ 
Klasse definiert und dann die targetspezifische Implementierung in C 
Code dazu gelinkt wird. Und diese kann einfach und schnell sein (so 
kenne ich das von den LPCs) oder etwas aufwändiger weil eine Hersteller 
Lib benutzt wird (wie beim STM halt). Historisch hat mbed ja mit dem 
LPC1768 angefangen, die ST Target sind jetzt in der Überzahl. Die 
konnten schnell adaptiert werden weil mit der HAL eine 
Hardwareunabhängikeit eingeführt wurde.
Das Gute an mbed ist das die Hardware jetzt relativ leicht getauscht 
werden kann solange keine MCU spezifischen Features genutzt wurden. Ob 
jetzt andere ad hoc besser laufen, dafür würde ich jetzt nicht die Hand 
ins Feuer legen. Ich benutze zwar für meine Projekte lieber die LPC, 
aber auch da habe ich schon Fehler gefunden. Ein vergleichbares Kaliber 
wie das Nucleo F103 wäre der LPCXpresso1549, der hat auch ein CAN IF.
Aber einfacher ist erstmal den Fix abzuwarten. Und den einfachen SPI 
write Test kann ich auch machen.

ich habe mal das mbed SPI zwischen LPC1549 und F103 verglichen und noch 
ein chip select eingebaut, damit kann man besser die Zeiten für die cs 
low Phase messen.

F103:
- kann nur 8 oder 16 Bit breiten Transfer, für die min. 22 Takte muss 
man dann 2 x 16 Bit nehmen
- mbed OS2: 27 µs, hat aber noch den Fehler mit dem doppelten Takten 
drin
- mbed OS5: 37 µs

LPC1549:
- kann 1..16 Bit Transfer (>16 Bit geht nicht wie ich erst geschrieben 
hatte)
- mbed OS2: 8,5 µs
- mbed OS5: noch nicht unterstützt

also die HAL Schicht frisst schon einiges...

1

#include "mbed.h"

2

3

#ifdef TARGET_LPC1549

4

5

#define PIN_MOSI    D11

6

#define PIN_MISO    D12

7

#define PIN_SCK     D13

8

#define PIN_SSEL    NC

9

10

DigitalOut led(LED1);

11

DigitalOut cs(D9);

12

13

#elif defined  TARGET_NUCLEO_F103RB

14

15

#define PIN_MOSI    D4

16

#define PIN_MISO    D5

17

#define PIN_SCK     D3

18

#define PIN_SSEL    NC

19

20

DigitalOut led(LED1);

21

DigitalOut cs(D9);

22

23

#endif

24

25

SPI spi(PIN_MOSI, PIN_MISO, PIN_SCK);

26

27

int main() {

28

    //spi.format(12, 0);

29

    spi.format(16, 0);

30

    spi.frequency(16e6);

31

32

    cs = 1;

33

34

    while(1) {

35

36

        cs = 0;

37

        uint32_t lo = spi.write(0x11);

38

        uint32_t hi = spi.write(0x33);

39

        cs = 1;

40

41

        wait_us(100);

42

    }

43

}