~1€ ARM-Cortex-M0 (STM32)-Bord selbstgestrickt

[Dirk K. (dekoepi)]

Anfang des Monats habe ich ein Minimal-Board mit Cortex-M0-Kern basteln 
wollen: ein Minimum STM32 Board. Zwei Wochen später startete ein Thread 
im EEVBlog 
(http://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/) mit 
ähnlicher Idee. Informationen dort waren zunächst spärlich, weshalb ich 
das hier zum Nachbauen vorstellen möchte.

Ganz ohne Zusatzbeschaltung ist gar nicht nötig, ich habe noch 
Blockkondensatoren mit 100nF zwischen Vcc/AVcc und GND gelötet sowie für 
beide einen gemeinsamen 10µF-Kerko integriert. Am Ende habe ich den 
"frei schwebenden" 10µF mit einem Tropfen Sekundenkleber auf freier 
Fläche fixiert. Das Löten ging erstaunlich gut und einfach - ordentlich 
Lotfluss (RMA 223 ging gut) auf die Platinenkontakte, Prozessor 
ausrichten und mit einem Tropfen Lötzinn auf der Spitze von den 
Prozessorpins über die Kontaktflächen streichen. Entlötlitze hilft, 
überschüssiges Lot aufzunehmen.

Zwei Pinreihen einlöten, anschließend die Kondensatoren dazu. Wie man 
auf dem Foto sieht, nicht optimal, aber in dem Frequenzbereich noch 
unkritisch. AVcc ist mit Kupferlackdraht an Vcc angeschlossen. Das 
sollte also auch für ADC-Messungen ausreichen.

Als Test dient ein schnell gestricktes Blinky (ich nutze die STM 
Standard Peripheral Lib):

#include "stm32f0xx.h"
#include <stdio.h>
#include "main.h"

void init(void) {
  GPIO_InitTypeDef GPIO_InitStructure;
  RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);

  // LED: Configure PA0 and PA1 in output pushpull mode
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOA, &GPIO_InitStructure);
}

int main (void) {
  init();

  while (1) {
    GPIOA->BSRR = GPIO_Pin_1;  // Set PA! HIGH
    GPIOA->BRR = GPIO_Pin_0;  // Set PA0 to GND (LED on)
    Delay(500000L);
    GPIOA->BRR = GPIO_Pin_1;  // Set PA1 to GND (LED off)
    Delay(500000L);
  }
}

void Delay(__IO uint32_t nCount) {
  while(nCount--) {
  }
}

Via SWD / ST-LINKv2 kann ich den µC verbinden - das Flashen schlägt 
jedoch nach dem "Flash erase" fehl. Daher der Preisklasse angemessen die 
Alternative, den Bootloader zu verwenden und einfach via UART (TX - PA9, 
RX PA10) und stm32flash zu flashen. Das klappt dann auch einwandfrei:

MacBook-Air:Release koepi$ ./flash.sh 
stm32flash - http://stm32flash.googlecode.com/

Using Parser : Intel HEX
Serial Config: 57600 8E1
Version      : 0x31
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0444 (STM32F030)
- RAM        : 8KiB  (4096b reserved by bootloader)
- Flash      : 64KiB (sector size: 4x1024)
- Option RAM : 12b
- System RAM : 3KiB

Wrote and verified address 0x080003bc (100.00%) Done.

Resetting device... failed.

Unter Windows gibt es dazu den 
"Flash_Loader_Demonstrator_v2.6.0_Setup.exe" direkt bei ST zum Download. 
In den Flash-Modus gelangt man, indem man BOOT0 auf NRST verbindet und 
den µC neu startet/bestromt.

Die µCs gibt es für rund 8 Euro inlusive Versand für das Zehnerpack aus 
China. Ist etwa vier Wochen unterwegs:
http://www.ebay.de/itm/321426013659

20 TSSOP20-zu-DIL-Adapterplatinchen gibt es für rund 2,50€:
http://www.ebay.de/itm/121382728173

Die Pinreihen und die Kondensatoren kosten auch nur wenige Cent und hat 
man idealerweise schon herumfliegen, sonst gibt es 50er- bis 500er-Packs 
aus dem Reich der Mitte für 2-3 Euro (etwa 10 µF 16V X5R/X7R, auch 100nF 
16V X5R/X7R).

Insgesamt komme ich auf rund einen Euro für einen fertig aufgebauten 
32-bittigen Mikroprozessor mit 48 MHz, 16 kByte Flash und 4 kByte RAM. 
Für viele Dinge reichen die ~15 nutzbaren IOs (Alternate Function für 
PF0 und PF1 verwenden, ...) schon aus. Der ADC löst mit 12 anstatt 10 
Bit auf im Vergleich zu Arduino/AVR; es gibt zahlreiche Timer/PWM. Wenn 
ich das jetzt mit dem ebenso teuren ATtiny13 oder teureren ATtiny85 
vergleiche ...

Hier noch ein Clip von dem Board im Einsatz - es funktioniert wirklich 
:)
http://youtu.be/oX-A-OXUrns

Ach ja, das Datenblatt/Reference Manual könnte noch hilfreich sein zum 
Programmieren des kleinen Schmuckstücks:
http://www.st.com/web/en/resource/technical/document/reference_manual/DM00091010.pdf

Vielleicht hat ja noch jemand Spaß daran, so ein minimales µC-Board 
aufzubauen und einzusetzen :)

[chris (Gast)]

Danke für den Link zu den STMs bei ebay ;)
Habe mir gleich mal 20 Stück bestellt

lg
Chris

[frg (Gast)]

Dirk K. schrieb:
> Insgesamt komme ich auf rund einen Euro für einen fertig aufgebauten
> 32-bittigen Mikroprozessor mit 48 MHz, 16 kByte Flash und 4 kByte RAM.


Herzlichen Glückwunsch.

Sie haben erkannt, warum viele Firmen auf ARM-based µCs wechseln.

Laut unseren FAEs zeichnet sich der Trend ab, dass 16-Bit-µCs
aussterben und 8-Bit-µCs in Nischenanwendungen gedrückt werden.
Und auch nur das, wenn der Preis günstiger ist, als der günstigste
Cortex-M0 (was schwer wird!).

Die ARM-based µCs überrollen zur Zeit den Markt und stellen schon jetzt
einen Quasi-Standard dar.

[Dirk K. (dekoepi)]

Ich hoffe auf eine radikale Moderation. (Wenn die 3,37kB-große main.c 
gelöscht werden könnte, wäre das auch super. Habe da noch etwas 
aufgeräumt.)

Das Projekt macht richtig Spaß - bekomme das Teil langsam in den Griff 
und kann es als richtiges µC-Board nutzen :)

Zwei "Meilensteine" habe ich soweit: Zum Einen Feedback via UART. Ist 
doch langweilig, wenn der µC nur eine LED blinkt und nicht mit mir 
spricht, dafür reicht auch ein NE555. Außerdem hängt der 
USB-zu-Seriell-Wandler doch eh schon dran zum Programmieren.
Und dann wäre da zum Anderen noch der Haken des internen Quarzes mit 8 
MHz. Da der µC 48 MHz kann, muss also der PLL dazugeschaltet werden - 
quasi den Turbo einschalten.

Erster Zwischenstand auf 57.6kBit-Terminal:

STM32F030-Test begins.
HCLK is 8 MHz, PCLK 8 MHz, System 8 MHz.

Zweiter Zwischenstand:

STM32F030-Test begins.
HCLK is 48 MHz, PCLK 48 MHz, System 48 MHz.

Anstatt nur zu blinken, dimme ich die LED jetzt gemütlich.
http://youtu.be/hkWmO3jxxbs

Den vollständigen Code habe ich angehängt. Für das PLL-Setup habe ich 
einen Codeschnippsel aus den weiten des Netzes angepasst, daher stehen 
da nur sinnfreie "Bit-Werte" für die Register drin. War noch zu sehr mit 
"bring es endlich hin" und Freuen beschäftigt, sodass ich die 
Inverssuche im Datenblatt nicht vollzogen habe.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Jedes Avr Asm-Blinky auf einem Tiny ist um Welten einfacher und kürzer.
Und mit einem astabilen Multivibrator blinkt es sogar ganz ohne 
Code...
Aber es geht HIER nicht darum, ob irgendwas mit irgendwas Anderem 
schneller und/oder einfacher ginge. Können wir also bei der Sache 
bleiben?

[Dirk K. (dekoepi)]

Beim Weiterbasteln beiße ich mir am ADC die Zähne aus - den hatte ich 
auf STMs bislang noch gar nicht benutzt (derzeitiger Code im Anhang, der 
unterscheidet sich schon von dem, was auf STM32F1xx üblich war; 
physikalisch hängt zwischen PA3 und PA4 einfach ein Temperaturfühler aus 
einem alten Akkupack. Die ADC-Wandlung jetzt wartet sich tot, daher 
auskommentiert).

Das Rumgestecke der Kabel ging mir arg auf die Nerven, daher habe ich 
jetzt zwei 5x5mm-Print-Taster eingelötet. Einer verbindet BOOT0 mit nRST 
und hält durch anlöten der Beinchen an die Pin-Basis.
Der zweite Taster zwischen Vss und nRST hält durch Sekundenkleber, die 
Verbdindung selbst ist mit Kupferlackdraht aufgebaut.

Da ist natürlich nichts entprellt, manchmal muss man mehrmals drücken - 
aber immer noch besser, als immer Kabel hin- und herzustöpseln. Das tut 
den Kontakten nicht gut und verbessert die nicht grade.

Zum Flashen dann also: BOOT0-Taster drücken und halten, Reset drücken. 
Flashprogramm starten bei gedrücktem BOOT0-Taster. Wenn fertig, 
loslassen und nochmals Reset drücken. Klingt komplizierter, als es ist. 
Und ist auf dem Platz auf dem Adapterplatinchen gerade noch so 
unterzubringen.

[Christian J. (Gast)]

Ähm..... wo kommen denn die tausend Zeiger bei einer so einfachen 
Anwendung her? Ich finde den Source schon echt unverständlich und extrem 
lange Ausdrücke, die man ohne eine Autoergänzung mühsam eintippen muss.

Auf meinem LPC2378 sieht sowas lesbarer aus.... LED1_OFF ist nur ein 
Makro.

// ------- Setzt die Pin Matrix und andere Sachemn -------
void IO_Setup(void)
{

 // LED Ausgänge setzen, Config Pin GPIO3[26:25]
  PINSEL7  &= 0xFFC3FFFF;           // P3[26:25] = GPIO Function(xxxx xxxx xx00 00xx xxxx xxxx xxxx xxxx)
  PINMODE7 &= 0xFFC3FFFF;           // Enable Pull-Up on P3[26:25]
  FIO3DIR  |= LED1;                 // Set GPIO-3[26:25] = Output(xxxx x11x xxxx xxxx xxxx xxxx xxxx xxxx)
  FIO3DIR  |= LED2;
  LED1_OFF();                       // Default LED Status
  LED2_OFF();

}

Unf für die verwöhnte Arduino (Jehova!  klatsch bums* knock*) Jünger, 
das simple Setzen einer Taktrate sieht bei ARM etwas "mehr" aus .... 
aber man freut sich wenn es fertig ist und man alle Plutimikatoren und 
Divisatoren *örks+ richtig hat.

/*
    Einstellen der PLL auf gewünschte Taktrate, Taktrate
    der Peripherie festlegen
    Eingabe: 1=PLL an, 0=aus, APB Teiler
*/

void Init_PLL(uint8_t mode, uint8_t apb_div)
{
  unsigned long MValue, NValue;

  // Anleitung Kap 6.14, 50 UM

  if (mode == PLL_ON)
  {
      // Ist die PLL durch Boot Code angeschlossen?
      if ( PLLSTAT & (1 << 25) )
      {
    // Dann trennen wir sie vom Clock ab
        PLLCON = 1;
        PLLFEED = 0xaa;
        PLLFEED = 0x55;
      }

      // ...und schalten sie aus
      PLLCON  = 0;
      PLLFEED = 0xaa;
      PLLFEED = 0x55;

      CLKSRCSEL = 0x1;          // PLL Source = Main Oscillator

      // PLL neu konfigurieren
      PLLCFG = PLL_M | (PLL_N << 16);
      PLLFEED = 0xaa;
      PLLFEED = 0x55;

      // PLL einschalten aber abgetrennt
      PLLCON = 1;
      PLLFEED = 0xaa;
      PLLFEED = 0x55;
      while ( ((PLLSTAT & (1 << 26)) == 0) );   // Warte bis stabil

      // CPU Clock Teiler setzen
      CCLKCFG = CCLKDiv;

      // PLL an Main Oscillator andocken....
      PLLCON = 3;
      PLLFEED = 0xaa;
      PLLFEED = 0x55;
      while ( ((PLLSTAT & (1 << 25)) == 0) );   /* Check connect bit status */
  }
  else if (mode == PLL_OFF)
  {
      // Dann trennen wir sie vom Clock ab
      PLLCON = 1;
      PLLFEED = 0xaa;
      PLLFEED = 0x55;

      // ...und schalten sie aus
      PLLCON = 0;
      PLLFEED = 0xaa;
      PLLFEED = 0x55;
  }

  MAMCR    = 0x00;        // MAM Funktion ausschalten
  MAMTIM   = 0x03;        // MAM fetch Zyklen sind 3 Prozessor Clock's
  MAMCR    = 0x02;        // MAM komplett aktivieren

  MEMMAP = MEMMAP_FLASH;

  SCS     |= 0x01;          // Fast GPIO
  SCS     &= ~SCS_MCIPWR;   // MCI_POWER low  aktiv

  // APB Teiler einstellen, nur 1/4 oder 1/2 Fcclk
  switch (apb_div)
  {
    case 1: PCLKSEL0 = 0x55555555;
            PCLKSEL1 = 0x55555555;
            break;

    case 2: PCLKSEL0 = 0xAAAAAAAA;
            PCLKSEL1 = 0xAAAAAAAA;
            break;

    case 4: PCLKSEL0 = 0x00000000;
            PCLKSEL1 = 0x00000000;
            break;
  }

}

[Dirk K. (dekoepi)]

Toll, es gibt andere µProzis, wo man das anders macht, wo der 
Programmcode anders aussieht? Also Religionskrieg NXP vs ST?

Ist heute "Troll melde dich"-Tag? Was hat das jetzt zu dem Thema 
beigetragen ...*selbst zesnier*?

[Besorgter Gast (Gast)]

Dirk K. schrieb:
> Toll, es gibt andere µProzis, wo man das anders macht?
>
> Ist heute "Troll melde dich"-Tag? Was hat das jetzt zu dem Thema
> beigetragen, außer, dass du dein Glied in der Öffentlichkeit präsentiert
> hast?

Kritik ist keine Einbahnstraße !!!

Wer immer austeilt sollte auch einstecken können !!!

Christian J. schrieb:
> Ähm..... wo kommen denn die tausend Zeiger bei einer so einfachen
> Anwendung her?

>>> Ironie On

Das sind seine Wegweiser damit er sich beim Kopieren der Code nicht 
verläuft.

>>> Ironie Off

[Beinly (Gast)]

> Hier noch ein Clip von dem Board im Einsatz - es funktioniert wirklich :)
> Youtube-Video "30.08.2014 Minimum STM32 Board!"

Am besten gefällt mit der Kommentar zum Video. Danke :)

[Besorgter Gast (Gast)]

Dirk K. schrieb:
> Toll, es gibt andere µProzis, wo man das anders macht, wo der
> Programmcode anders aussieht? Also Religionskrieg NXP vs ST?
>
> Ist heute "Troll melde dich"-Tag? Was hat das jetzt zu dem Thema
> beigetragen ...*selbst zesnier*?

Das hat doch aber auch nichts mit dem Beitrag zu tun.

Beinly schrieb:
>> Hier noch ein Clip von dem Board im Einsatz - es funktioniert wirklich :)
>> Youtube-Video "30.08.2014 Minimum STM32 Board!"
>
> Am besten gefällt mit der Kommentar zum Video. Danke :)

>>> Ironie On

Ja ist halt kurz und knapp so wie sein Programmcode, ein Typischer 
Minimalist.

>>> Ironie Off

[Dirk K. (dekoepi)]

Tjo, habe halt mal alles ausprobiert und sogar dokumentiert und dabei 
andere Geräte und Software angetestet. Ich will nämlich viel Lernen, 
daher auch das hiesige Projekt. Deine Einwürfe haben echt richtig was 
mit einem Minimal-Board zu tun. Applaus! (Ich verstecke mich auch nicht 
hinter einem anonymen Zugang.)

[JojoS (Gast)]

Besorgter Gast schrieb im Beitrag #3784552:
> Das kann ich euch nicht vorenthalten.
>
> Blink Blink
> Youtube-Video "15.03.2014 Blink Blink!"


Das interessante Teil darin ist das Mini Oszi, ist das ein 
umprogrammierter Meizu MP3 Player?

[Franz (Gast)]

>Unf für die verwöhnte Arduino (Jehova!  klatsch bums* knock*) Jünger,
>das simple Setzen einer Taktrate sieht bei ARM etwas "mehr" aus ....

Aber, aber wer wird denn gleich ... guck mal hier:
https://github.com/leaflabs/libmaple

;-P

[Dirk K. (dekoepi)]

Den ADC hätte ich nach eingehender Lektüre der 
STM-Peripheral-Lib/stm32f0xx_adc.c dann doch noch in Betrieb genommen :) 
Die Taster machen das Austesten von einzelnen 
Programmversionen/Iterationen sehr einfach und komfortabel, also habe 
ich das auch für die anderen vorbereiteten Platinchen übernommen. Kann 
das für Nachbauer nur empfehlen!

STM32F030-Test begins.
HCLK is 48 MHz, PCLK 48 MHz, System 48 MHz.
ADC-Value: 5.
ADC-Value: 6.
ADC-Value: 8.
ADC-Value: 4.
ADC-Value: 8.
ADC-Value: 9.
ADC-Value: 5.
ADC-Value: 4.
ADC-Value: 7.
ADC-Value: 7.
ADC-Value: 9.
ADC-Value: 4.
ADC-Value: 5.
ADC-Value: 8.
ADC-Value: 7.
ADC-Value: 8.
ADC-Value: 7.
ADC-Value: 9.

[./. (Gast)]

Das Einstellen und Einschalten der PLL war auf einem 32L053 auch nicht 
mehr als ein 4-Zeiler, wenn man die passenden Werte gleich in die 
Register schreibt und auf die Segnungen von irgendwelchen 'Stdlibs' und 
'Frameworks' verzichtet.
Ditto das Konfigurieren des ADC...

[chris_ (Gast)]

Welchen Programmieradapter verwendest Du für das gute Stück?

[Dirk K. (dekoepi)]

Da meine ST-Link V2 nach dem Flash Erase nicht weiterkommen (und unter 
Windows das ST-util nicht einmal den µC identifiziert), ein simpler 
USB-zu-Seriell-Adapter (derzeit FTDI, geht aber jeder, der auch 3,3V 
Versorgungsspannung liefern kann).

Compilieren ganz normal in der IDE. Flashen des .hex/.bin selber 
anschließend mit stm32flash (Mac/Linux) oder dem 
Flash-Loader-Demonstrator von ST. Details dazu gibt es auch nach dem 
Blinky-Codeschnippsel im Start-Post.

[chris_ (Gast)]

Hmmm ... über Seriell zu programmieren finde ich nicht so gut. Ich habe 
vor kurzem einen LPC810 programmiert. Ich habe eine Demo-Code 
hochgeladen, der die serielle Schnittstelle zur Textausgabe benutzt. Das 
hat gut funktioniert, aber leider nur ein mal. Danach konnte ich den 
Prozessor nicht mehr programmieren, ich nehme an, der Code hat die Pins 
umkonfiguriert.

[Dirk K. (dekoepi)]

Bei STM32 kann da nichts passieren, da du zum Flashen - wie oben bereits 
beschrieben: Beitrag "Re: ~1€ ARM-Cortex-M0 (STM32)-Bord selbstgestrickt" - über 
einen Taster den Bootloader auswählst. Den kannst du darüber nicht 
kaputt flashen, der funktioniert immer.

[Dirk K. (dekoepi)]

Mit Datenblatt und stm32f0xx_rcc.h lässt sich das 48 MHz-Setup auch mit 
der Standard Peripheral Lib erreichen. Einfach den Block hiermit 
ersetzen:

  // ---- Setup PLL for 48 MHz :) ----
  RCC_PLLCmd(DISABLE);
  RCC_PLLConfig(RCC_PLLSource_HSI, RCC_PLLMul_12);
  // Flash: 1 WaitState for 24MHz < SysCLK < 48 MHz
  FLASH_SetLatency(FLASH_Latency_1);
  FLASH_PrefetchBufferCmd(ENABLE);
  // Set ADC clock to internal 14MHz HSI source
  RCC_HSI14Cmd(ENABLE);
  RCC_HSI14ADCRequestCmd(ENABLE);
  // and turn the PLL back on again
  RCC_PLLCmd(ENABLE);
  // set PLL as system clock source
  RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);
  // ---- End of Setup PLL for 48 MHz :) ----

Interessant ist der Overhead - die Binärdatei wuchs um 300 Byte an. 
Fluchen auf die Lib ist also schon berechtigt. Dafür liest sich der 
Quelltext viel einfacher.

[Stefan (Gast)]

Dirk K. schrieb:
> Bei STM32 kann da nichts passieren, da du zum Flashen - wie oben bereits
> beschrieben: Beitrag "Re: ~1€ ARM-Cortex-M0 (STM32)-Bord
> selbstgestrickt" - über
> einen Taster den Bootloader auswählst. Den kannst du darüber nicht
> kaputt flashen, der funktioniert immer

Ist bei den LPCs nicht anders. Einziger Unterschied: Der Loader wird 
nach einem Reset immer aufgerufen und prüft anhand einer Prüfsumme ob 
ein "gültiges" Programm im Flash liegt. Ist das der Fall, wird der 
Loader beendet und das Programm angesprungen - es sei denn der ISP Pin 
ist low. Dann wartet der Loader auf Kommandos.
Wird allerding kein Programm im Flash erkannt, bleibt der Loader aktiv 
und man kann ihm auch ohne daß der ISP Pin bedient wird ein Hexfile 
schicken.
Und das ist überlicherweise auch der Grund wenn sich ein LPC scheinbar 
nur einmal flashen läßt: Der ISP Pin wird nicht (richtig) bedient.

[Dirk K. (dekoepi)]

Weitere Fortschritte: BOOT0 floating ist eine schlechte Idee. Dadurch 
startet der µC manchmal nicht. Laut Datenblatt (S. 62) hat nRST einen 
internen Pullup von minimal 30kOhm, typisch 40kOhm, maximal 50kOhm. Den 
missbrauchen wir bislang zum Setzen von BOOT0 auf 1, für den Bootloader 
respektive Flash-Modus.
Also fehlt da noch ein Pulldown an BOOT0; Dank der doppelseitigen 
TSSOP20-zu-DIP-Platine ist noch etwas Platz zum Einlöten. Ich habe einen 
250kOhm-Widerstand genommen, das reicht schon: Der µC startet nun 
verlässlich durch :)

Unter Windows funktioniert jetzt auch das ST-Werkzeug ST-Util; ich habe 
neben den SWD-Verbindungen noch RST auf nRST gelegt. Damit konnte ich 
dann auch via ST-Link das .hex brennen. Debugging/Step-by-Step/Register 
auslesen klappt damit auch. Nur unter MacOS mag das st-util/texane noch 
immer nicht über "Flash erase"/"flashloader in den SRAM laden und 
starten" hinaus - immerhin ist der Speicher danach schön leer ;)

Und auch den ADC-Code habe ich nun im Griff:

// init:
  // ADC-init for Temperature probe
  ADC_DeInit(ADC1);
  ADC_InitStructure.ADC_Resolution = ADC_Resolution_12b;
  ADC_InitStructure.ADC_ContinuousConvMode = DISABLE;  // on demand
  ADC_InitStructure.ADC_ExternalTrigConv = ADC_ExternalTrigConv_T1_TRGO;
  ADC_InitStructure.ADC_ExternalTrigConvEdge = ADC_ExternalTrigConvEdge_None;
  ADC_InitStructure.ADC_DataAlign = ADC_DataAlign_Right;  // 12 bit right aligned
  ADC_InitStructure.ADC_ScanDirection = ADC_ScanDirection_Upward;
  ADC_Init(ADC1, &ADC_InitStructure);

  ADC_ChannelConfig(ADC1, ADC_Channel_4, ADC_SampleTime_7_5Cycles);
  ADC_DiscModeCmd(ADC1, ENABLE);
  // ADC calibration; but not used as returned value ends nowhere now...
  ADC_GetCalibrationFactor(ADC1);
  ADC_Cmd(ADC1, ENABLE);

  // Probe on PA3+4
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_4;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AN;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
  GPIO_Init(GPIOA, &GPIO_InitStructure);

  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOA, &GPIO_InitStructure);

// ...

int readADC(void) {
  uint32_t temp = 0;
  GPIOA->BRR |= (GPIO_Pin_3);  // Enable Sensor
  // throw awaynfirstresult like on AVR? first value is wrong.
  ADC_StartOfConversion(ADC1);
  while(ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET);

  for (uint8_t i = 0; i<16; i++) {  // oversampling
    ADC_StartOfConversion(ADC1);
    while(ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET);
    temp += ADC_GetConversionValue(ADC1);
  }
  GPIOA->BSRR |= (GPIO_Pin_3);  // Disable Sensor, save power
  return (temp>>4);
}

So, jetzt noch Pulldowns in die anderen beiden vorbereiteten Boards 
löten ...

[chris (Gast)]

Dirk K. schrieb:
> Den
> missbrauchen wir bislang zum Setzen von BOOT0 auf 1

wieso verbindest du BOOT0 überhaupt mit RESET?
BOOT0 gehört auf 0 für Starten aus dem Flash und auf 1 für Starten aus 
dem System-Memory.
Also einfach Pulldown und Taster gegen Vcc. Aber nicht gegen RESET.

lg
Chris

[Dirk K. (dekoepi)]

Hätte ich eigentlich auch so gemacht, aber der Platz ist knapp und an 
VCC/VSS hängen schon so viele Kupferlackdrähte. Da nRST einen Pullup 
benutzt, kann man also auch von dort den 1-Pegel abholen. Nachteile sehe 
ich bislang keine.
Der Denkfehler war nur, dass man BOOT0 vielleicht auch im Zustand 
floating lassen könnte für "Normalbetrieb". Und das geht gehörig schief.

[Lutz (Gast)]

2014-09-02-Boot0-250k-Pulldown-scaled.jpg

=> Vergiß bitte bei dem ganzen Entwickeln nicht, hin und wieder mal 
durchzusaugen...;-)

[Alexander B. (Firma: brickwedde.dev) (alexbrickwedde)]

Dirk K. schrieb:
> Da meine ST-Link V2 nach dem Flash Erase nicht weiterkommen (und unter
> Windows das ST-util nicht einmal den µC identifiziert)

Komme aus der AVR Ecke, habe mal PSoC4 angetestet (die cy8ckit-49 passen 
super auf's Steckbrett - aber die Windows-IDE und der generierte Code 
sind nicht mein Ding) und habe für mich noch nicht das "richtige" 
gefunden. Die ersten Tests mit STM32F4Discovery fühlten sich gut an und 
ich war zufrieden. Nur Steckbrett passt nicht. Daher habe ich auch den 
F030 TSSOP20 auf ein Adapterboard gelötet. Die weiteren notwendigen 
Komponenten kommen bei mir aber extern auf's Steckbrett.

STLink muss funktionieren, da ich debuggen will. Das STLink vom 
F4Discovery klappte nicht und ein China-Clone STLink-V2 kam auch nicht 
klar. Bis ich dann ein FX2LP Board an SWDIO/SWCLK angeklemmt habe um die 
Signale per PulseView mitzuschneiden, da hat der STLink den F030 erkannt 
- allerdings nur bis max. 450kbit (In der ST Windows-Software - openocd 
kann man nicht einstellen). Also FX2LP wieder weg und ein Pull-Down an 
SWDIO dran -> Flashen und Debuggen funktioniert einwandfrei.

Also bei meinem STM32F030 (TSSOP20) reicht: 100nF Zwischen NRES und VSS. 
10kOhm zwischen SWDIO und VSS. VDDA muss versorgt werden. Und 100nF + 
10µF zwischen VDD/VDDA und GND. Vom ST-Link NRES, SWDIO, SWCLK und GND 
anklemmen.

...Alex

[Alexander B. (Firma: brickwedde.dev) (alexbrickwedde)]

So, die aus Kanada bestellten LQFP48-DIP48 Adapterplatinen sind endlich 
gekommen. Die bleifrei vorverzinnte Platine mit bleihaltigem Lot 
"vorbehandelt", den Chip mit Tesa draufgeklebt und die Pins einzeln 
herunterdrücken und anlöten hat super geklappt (RDS80 bei 350° und 1mm 
Bleistiftspitze) - der 1. Versuch mit bleifreiem Lot ging schief...

Die für mich ausreichende Debugger-/STlink-kompatible 
Minimal-Beschaltung:
(im Prinzip wie beim STM32F030)

Pin7 (NRST) mit 100nF auf Gnd -> RST
Pin8 auf Gnd
Pin9 auf Vcc
Pin34 SWDIO mit 10k auf Gnd   -> SWDIO
Pin35 auf Gnd
Pin36 auf Vcc
Pin37 SWDCLK                  ->SWDCLK
Pin44 BOOT0 auf Gnd
Vcc mit 100nF und 10µF auf Gnd

...Alex

[TriHexagon (Gast)]

Christian J. schrieb:
> Ähm..... wo kommen denn die tausend Zeiger bei einer so einfachen
> Anwendung her? Ich finde den Source schon echt unverständlich und extrem
> lange Ausdrücke, die man ohne eine Autoergänzung mühsam eintippen muss.

Für alle die es nicht wissen, das was ihr da seht ist die Standard 
Peripheral Library. Niemand wird gezwungen dieses Ungetüm zu nutzen. Der 
µC lässt sich auch klassisch mit dem Setzen von Bits in Registern 
steuern:

//enable green LED PG13
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOGEN; //enable GPIOG clock
GPIOG->MODER |= GPIO_MODER_MODER13_0; //output mode
//push-pull
//low speed
//no pullup
GPIOG->BSRRL |= GPIO_BSRR_BS_13; //set PG13

Die ganzen Defines und Datenstrukturen sind in der stm32f4xx.h 
definiert.

[TriHexagon (Gast)]

TriHexagon schrieb:
> Die ganzen Defines und Datenstrukturen sind in der stm32f4xx.h
> definiert.

Hier natürlich "stm32f0xx.h".

[Rainer (Gast)]

Alexander Brickwedde schrieb:
> Pin7 (NRST) mit 100nF auf Gnd -> RST

Alexander Brickwedde schrieb:
> 100nF Zwischen NRES und VSS



Alexander Brickwedde schrieb:
> Pin34 SWDIO mit 10k auf Gnd   -> SWDIO

Alexander Brickwedde schrieb:
> 10kOhm zwischen SWDIO und VSS


Hallo Zusammen,

nach einigen kleinen Spielereien mit den AVR's möchte ich mich mit den 
32 Bit uC befassen. Also habe ich das kleine Platinchen mit dem 
STM32F030 zusammengelötet und mache meine ersten Gehversuche unter Mac, 
ST-Link/V2, SWD, GDB, ... Das ganze funktioniert auch(manchmal), nur 
benötige ich meistens 2 bis 3 Versuche um den uC zu beschreiben / 
Debuggen. Es scheint also etwas zu stören. Deswegen würde mich 
interessieren welche Aussage richtig ist.

Danke und Gruß
Rainer

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Rainer schrieb:
>...
> Debuggen. Es scheint also etwas zu stören. Deswegen würde mich
> interessieren welche Aussage richtig ist.
>
Arbeitest Du mit Wire Jumpern zwischen Debugger/Programmierer und 
Target? Dann ist eine gute Masseverbindung zwischen beiden Platinen 
wichtig. Mehrere Masseleitungen statt nur einer zwichen den beiden 
Platinen hilft haeufig!

[Matze (Gast)]

Dirk K. schrieb:
> Interessant ist der Overhead - die Binärdatei wuchs um 300 Byte an.
> Fluchen auf die Lib ist also schon berechtigt. Dafür liest sich der
> Quelltext viel einfacher.

Echter Overhead oder besch... Compiler?

[Alexander B. (Firma: brickwedde.dev) (alexbrickwedde)]

Rainer schrieb:
> Alexander Brickwedde schrieb:
>> Pin7 (NRST) mit 100nF auf Gnd -> RST
>
> Alexander Brickwedde schrieb:
>> 100nF Zwischen NRES und VSS
>
>
>
> Alexander Brickwedde schrieb:
>> Pin34 SWDIO mit 10k auf Gnd   -> SWDIO
>
> Alexander Brickwedde schrieb:
>> 10kOhm zwischen SWDIO und VSS
>
> benötige ich meistens 2 bis 3 Versuche um den uC zu beschreiben /
> Debuggen. Es scheint also etwas zu stören. Deswegen würde mich
> interessieren welche Aussage richtig ist.



Welcher meiner 4 Aussagen? Die ersten beiden und die letzten beiden der 
4 zitierten sind jeweils redundant. Gnd entspricht doch Vss... oder?

[Rainer (Gast)]

Alexander Brickwedde schrieb:
> Gnd entspricht doch Vss... oder?

Ups, Sorry mein Fehler - VSS gelesen, VDD gedacht.

Uwe Bonnes schrieb:
> Arbeitest Du mit Wire Jumpern zwischen Debugger/Programmierer und
> Target?

Verbinde den ST-Link/V2 mit meinem Steckbrett über einzelne Kabel, oder 
Flachkabel (beides ausprobiert) auf dem die Platine aufgesteckt ist. Wie 
weiter oben auf dem Bild von Alexander Brickwedde.
Bekomme auch öfters Fehlermeldungen die ich noch nicht deuten kann.

z.B.:
> Warning: the current language does not match this frame.
> The target endianness is set automatically (currently little endian)
> Note: automatically using hardware breakpoints for read-only addresses.

> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x2000002e in impure_data ()
oder
> Error in final launch sequence
> Failed to execute MI command:
...
> Error message from debugger back end:
> Error finishing flash operation
> Error finishing flash operation

Wenn ich das stm32F4 discovery anschließe, läuft alles problemlos.

Gruß
Rainer

[Alexander B. (Firma: brickwedde.dev) (alexbrickwedde)]

Kannst Du die Frequenz des SWCLK einstellen? Mit Windows Tool gehe ich 
unter 500khz. Dann geht auch openocd.

[Kai (Gast)]

Dirk K. schrieb:
> sowie für beide einen gemeinsamen 10µF-Kerko integriert.

Hallo,

Wo wird denn der Kerko genau eingelötet? Direkt zwischen Vcc und VAcc?

Gruß
Kai

[Dirk K. (dekoepi)]

Ich habe mal einen größeren Ausschnitt fotografiert, vielleicht macht es 
das deutlicher. Eine Seite des Kerkos an Vcc, die andere an GND; von Vcc 
geht eine Strippe durch die Ferritperle an Vdda. Ein kleinerer Kerko 
dann mit einer Seite an Vdda und die andere Seite nach GND.

[Kai (Gast)]

Ok. Danke.