nun wollte ich dasa mal probieren - schien auch soweit (compile + aufs board schicken) zu klappen, die led auf dem st-link-Teil blinkt beim download rot/grün. #include "mbed.h" DigitalOut myled(LED1); int main() { while(1) { myled = 1; wait(0.2); myled = 0; wait(0.2); } Aber: tut nichts, blinkt nicht. Aber einfcher kann ja ein Programm nicht sein Versorgt über USB, MB1136 C-01 (liegt hier schon länger). Fragen: wo steht eigentlich, an welchem Port LED1 hängt? Woher weiss der Compiler, mit welcher Frequenz der Controller eigentlich arbeitet bzw. wo sage ich es ihm? Funktioniert der download eigentlich wenn der Zielprozessor gar keinen Takt hat? Oder läuft der mit internem Takt? X3 ist nicht bestückt, und auch die beiden Lötbrücken SB16 und SB50 (MCO) sind offen (im Schaltplan steht "default closed"?
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
Gerhard schrieb: > Versorgt über USB, MB1136 C-01 (liegt hier schon länger). Hast du die beiden Jumper bei ST-LINK gesetzt? Jumper für Stromversorgung über USB gesetzt? Auf U5V stellen. > Fragen: wo steht eigentlich, an welchem Port LED1 hängt? in PinNames.h > Woher weiss der Compiler, mit welcher Frequenz der Controller eigentlich > arbeitet bzw. wo sage ich es ihm? Ich vermute das ist SetSysClock(void); aus system_stm32f1xx.h Exportiere dir das Framework am besten einmal und angle dich durch die files. Unter mbed/ findest du dein TARGET_NUCLEO_F103 in dem alle IC und Boardspezifischen sachen drin sind. Auch ein lohnenswerter einblick bietet das github repository: https://github.com/ARMmbed/mbed-os/
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.
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??
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: > 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. Ja weil dort keine Datei auf den ST Link kopiert wird, dort geht es noch "altmodisch" seriell zu. ? Bzw... Der STLink CDC Port ist doch eigentlich immer aktiv?! Das hat doch erstmal mit ST-Link Util. nichts zu tun.
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 | }
|
Bitte 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.