Forum: Mikrocontroller und Digitale Elektronik STM32F401 Embitz1.1 Toolchain gesucht


von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

N'Abend,

beim Batseln mit dem Black Pill Board wird leider bei der RNG Einheit 
ein Busfehler erzeugt, der den Hardfault Handler triggert.

Da scheint ein Fehler in den Libs vor zu liegen, vielleicht ein falsche 
Adresse. Da Lesen des DR erzeugt schon den Fehler.

Nun ist es so, dass Embitz 1.1 die SPL Library / API von 2011 mitbringt, 
die leider nicht fehlerfrei ist. Die 2016er, die auch erheblich 
umfangreicher ist, zb Cryptofunktionen habe ich komplett hier liegen und 
habe versucht alles zu überschreiben, CMSIS und die SPL, sowie auch die 
Startup Files usw. aber das macht alles nur noch schlimmer. Dann wird 
ein Mini projekt nicht mal kompiliert weil da tausend Fehler beim 
Kompilieren der SPL auftauchen. Da zu suchen ist müssig, da sind viel zu 
viele Abhängigkeiten drin.

Könnte mir daher jemand ein Template für den STM32F401 mit einer 
aktuellen StandardPeriph Libary und CMSIS hier einspielen, was ich so 
übernehmen kann? Das ist ein ganzer Verzeichnisbaum, der wohl eher in 
eine Cloud hochgeladen werden müsste.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Die Original-Version von Embitz 1.11 läuft bei mir mit STM32F401 
(Nucleo) einwandfrei. Es könnte daher sein, dass Deine Update-Versuche 
der Libs eher mehr kaputtgemacht haben als irgend etwas zu verbessern.

Ich würde Dir raten, EmBitz neu zu installieren, um einen sauberen Stand 
zu haben.

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Ich würde Dir raten, EmBitz neu zu installieren, um einen sauberen Stand
> zu haben.

Ist alles frisch und neu.. trotzdem sollte man das Neue einspielen und 
nicht eine 2011er Version. Da sind Bugs sind, das weiss ich. Vieles 
läuft und manches nicht. Finde jedenfalls nicht, der Unterbau ist aber 
zu komplex um da alles zu checken.

PS: Wenn du erstmal Eblink installiert hast wirst du auch nicht mal eben 
alles neu aufsetzen... dann bist du froh dass es läuft, denn ganz trival 
war das nicht :-)

von pegel (Gast)


Lesenswert?

Der arme kleine F401 hat doch gar keine RNG Hardware.
Der F407 z.B. dagegen schon.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> Da sind Bugs sind, das weiss ich.

Aber welche Bugs, das weisst Du nicht. Blindes Rumpatchen halte ich für 
kontraproduktiv.

> PS: Wenn du erstmal Eblink installiert hast wirst du auch nicht mal eben
> alles neu aufsetzen... dann bist du froh dass es läuft, denn ganz trival
> war das nicht :-)

Wie ich oben schrieb: Bei mir läuft alles perfekt.

pegel schrieb:
> Der arme kleine F401 hat doch gar keine RNG Hardware.
> Der F407 z.B. dagegen schon.

Haha :)

von Christian J. (Gast)


Lesenswert?

pegel schrieb:
> Der arme kleine F401 hat doch gar keine RNG Hardware.
> Der F407 z.B. dagegen schon.

Puhhh.... dann stimmt schonwas bei der Auswahl der ifdef Geschichten 
nicht, denn ich habe alles reingeschrieben was nach 401 ausschaut. GPIOJ 
hat er auch nicht.... wird grad gemeckert. Der nimmt sonst ja nur das, 
was zwischen den 10.000 ifdefs steht. Da blickt aber keiner mehr durch.

ARM_MATH_CM4
__FPU_USED
USE_STDPERIPH_DRIVER
STM32F401
STM32F401xx
HSE_VALUE=25000000

Das Rum-Patschen ist was für Doofe... kaum glaubst du eine Sache behoben 
zu haben wird die nächste angemeckert.

Ich mache mir jetzt nen Bier auf... Ende für heute!

von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> Wie ich oben schrieb: Bei mir läuft alles perfekt.

Was läuft denn perfekt? st-link v2 Debugger mit STLINK DBG Server? Haben 
deine Bluepills auch 128kb? Naaa.... EBlink ist einfach klasse, schnell 
und brennt alles.

Hilf doch mal einer einem alten Mann.. was hat der 401er denn noch alles 
nicht? Damit wir das gleich totlegen.

/* Includes 
------------------------------------------------------------------*/
/* Uncomment the line below to enable peripheral header file inclusion 
*/
#include "stm32f4xx_adc.h"
#include "stm32f4xx_can.h"
#include "stm32f4xx_crc.h"
#include "stm32f4xx_dac.h"
#include "stm32f4xx_dbgmcu.h"
#include "stm32f4xx_dcmi.h"
#include "stm32f4xx_dma.h"
#include "stm32f4xx_exti.h"
//#include "stm32f4xx_fsmc.h"
//#include "stm32f4xx_hash.h"
#include "stm32f4xx_gpio.h"
#include "stm32f4xx_i2c.h"
#include "stm32f4xx_iwdg.h"
#include "stm32f4xx_pwr.h"
#include "stm32f4xx_rcc.h"
//#include "stm32f4xx_rng.h"
#include "stm32f4xx_rtc.h"
#include "stm32f4xx_sdio.h"
#include "stm32f4xx_spi.h"
#include "stm32f4xx_syscfg.h"
#include "stm32f4xx_tim.h"
#include "stm32f4xx_usart.h"
#include "stm32f4xx_wwdg.h"
#include "system_stm32f4xx.h"
#include "misc.h"

von jo mei (Gast)


Lesenswert?

pegel schrieb:
> Der arme kleine F401 hat doch gar keine RNG Hardware.

Der F411 (auf dem "besseren" Blackpill) offensichtlich auch nicht.

Sagt mir jedenfalls CubeMX.

Seitdem manche neuere Controller nicht von der Embitz IDE unter-
stützt werden verwende ich CubeMX dafür und bin ganz zufrieden.
Denn auch dort kann ich für die meisten Anwendungen (ja es gibt
Ausnahmen) Low-Level Code für die Register-Interfaces erzeugen,
und wenn mir die LL-Calls als zu "overheadig" erscheinen kann
ich mir den Low-Level-Zugriff aus den LL-Sourcen - wie früher
gehabt - herauskopieren und damit optimal schnell arbeiten.

Also CubeMX und HAL sind nicht so Einbahnstrassen-mässig wie es
oft erscheint und/oder dargestellt wird. Bleibt halt noch das
Geschmäckle der etwas trägen STM-IDE (Eclipse-lastig) und die
sonstigen fehlenden Eigenschaften der Embitz IDE. Aber immer
noch besser als mit vielen Negertricks ein Library-Gemenge
aus verschiedenen Quellen zusammenzubasteln das dann doch vorne
und hinten nicht richtig passt.

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Bei den Datenblättern kriegt man nicht mal auf einen Blick raus, 
wieviele Timer das Steinchen denn nun hat, weil alle Sorten in einem 
Buch verquickt sind.

So, jedenfalls habe ich den 401er jetzt wieder am Laufen mit der 2011er 
SPL, musste nur die Takte ändern, weil die auf 168 Mhz standen und nicht 
auf 84 Mhz. 84 Mhz sind aber in der 2016er SPL mit drin, die aber nicht 
zum Laufen zu kriegen ist .... grrr......

Das ist die angepasste system_stm32f4xx.c die auch die Blackpills mit 
drin hat, die ja damals gar nicht bekannt waren.

von jo mei (Gast)


Lesenswert?

Christian J. schrieb:
> Bei den Datenblättern kriegt man nicht mal auf einen Blick raus,
> wieviele Timer das Steinchen denn nun hat, weil alle Sorten in einem
> Buch verquickt sind.

Auch dafür ist CubeMX sehr nützlich. Man braucht ja gar keinen
Code erzeugen, es reicht ja sich die Peripherie-Liste für den
gewünschten Controller anzuschauen. Pinout und alternative
Pin-Belegungen sind auch gleich dabei.

Aber immer schön meckern auf die STM-Datenblätter ....

Beitrag #6689408 wurde von einem Moderator gelöscht.
von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Jaja... ich lade es grad runter..... geht ja kein Weg dran vorbei, auch 
wenn das alles HAL ist....

PS: Ist ja alles schön klicki-bunti....

von jo mei (Gast)


Lesenswert?

Christian J. schrieb:
> geht ja kein Weg dran vorbei, auch
> wenn das alles HAL ist....

Schon wieder diese Desinformation. Erst mal ausführlich damit
arbeiten, bevor du solche pauschale Aussagen triffst, dann meckern.

Aber bitte nicht: CubeMX = HAL (only). Das ist nämlich
nicht zutreffend.

von Christian J. (Gast)


Lesenswert?

jo mei schrieb:
> Aber bitte nicht: CubeMX = HAL (only). Das ist nämlich
> nicht zutreffend.

Naja, wenn nicht auf Code Generator klicke erzeugt er mir einen HAL Tree 
und alles sieht aus wie HAL. Ok, für 5min Beschäftigung mit diesem Tool 
ist das vielleicht eine suboptimale Aussage.. Wäre mi auch recht, wenn 
er das alles auf Registerbasis ausgeben würde.

von jo mei (Gast)


Lesenswert?

Christian J. schrieb:
> erzeugt er mir einen HAL Tree
> und alles sieht aus wie HAL

jo mei schrieb:
> Denn auch dort kann ich für die meisten Anwendungen ....
> ..... Low-Level Code für die Register-Interfaces erzeugen

jo mei schrieb:
> Erst mal ausführlich damit arbeiten, ..... dann meckern

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Erstmal schlafen, das sieht ja schon nett aus....

von Christian J. (Gast)


Lesenswert?

Ich drehe ab... mal fix nen Timer konfiguriert das sieht doch stark nach 
SPL aus!
1
static void MX_TIM1_Init(void)
2
{
3
4
  /* USER CODE BEGIN TIM1_Init 0 */
5
6
  /* USER CODE END TIM1_Init 0 */
7
8
  LL_TIM_InitTypeDef TIM_InitStruct = {0};
9
10
  /* Peripheral clock enable */
11
  LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_TIM1);
12
13
  /* TIM1 interrupt Init */
14
  NVIC_SetPriority(TIM1_UP_TIM10_IRQn, NVIC_EncodePriority(NVIC_GetPriorityGrouping(),0, 0));
15
  NVIC_EnableIRQ(TIM1_UP_TIM10_IRQn);
16
17
  /* USER CODE BEGIN TIM1_Init 1 */
18
19
  /* USER CODE END TIM1_Init 1 */
20
  TIM_InitStruct.Prescaler = 1000;
21
  TIM_InitStruct.CounterMode = LL_TIM_COUNTERMODE_UP;
22
  TIM_InitStruct.Autoreload = 20000;
23
  TIM_InitStruct.ClockDivision = LL_TIM_CLOCKDIVISION_DIV1;
24
  TIM_InitStruct.RepetitionCounter = 0;
25
  LL_TIM_Init(TIM1, &TIM_InitStruct);
26
  LL_TIM_EnableARRPreload(TIM1);
27
  LL_TIM_SetClockSource(TIM1, LL_TIM_CLOCKSOURCE_INTERNAL);
28
  LL_TIM_SetTriggerOutput(TIM1, LL_TIM_TRGO_RESET);
29
  LL_TIM_DisableMasterSlaveMode(TIM1);
30
  /* USER CODE BEGIN TIM1_Init 2 */

von pegel (Gast)


Lesenswert?

Sei doch froh.

Übrigens wenn Du eine Funktion markierst und F3 drückst, oder rechte 
Maustaste "Open Declaration" benutzt, kannst Du deren Inhalt einsehen.

Damit kannst Du dann das minimale herauskopieren und auf LLL bringen.
Dies dann direkt in deine Quellen einfügen, ohne LL Funkionen benutzen 
zu müssen.

Damit kommst Du bei Bedarf der Hardware sehr nah.

von Christian J. (Gast)


Lesenswert?

Embitz1.1 ist ein sehr guter Editor, allein die Möglichkeiten ganz fix 
durch den Code zu navigieren mit der rechten Maustaste sind spitze. Wo 
taucht welche Variable auf, wo ist sie deklariert, wo sind Funktionen 
implementiert. Structs eintippen, nach dem . oder dem -> wird direkt die 
Liste der Elemente angezeigt usw. Alles was ifdef ist kann man grau 
machen. Wenn ich da an das Arduino Grauen denke, wo es nicht mal eine 
Auto Ergänzung gibt und keinerlei Möglichkeiten durch de Code zu zappen.

Blöd nur, dass es an einer einzigen Person hängt das Ding mal ins Jahr 
2021 zu bringen. Klar, Windows Programmierung ist nicht jedermanns 
Sache, das Teil ist komplex. Die SPL ist alt aber die funktioniert, ok 
an HAL muss man sich eben gewöhnen, auch wenn ich keinen Bock drauf 
habe. Umarbeiten kann man die SPL wohl nicht, dafür ist sie zu komplex 
und ein undurchschaubares Grab von ifdef Anweisungen der bedingten 
Kompilierung, weil sie ganze Familien in einer Datei abdeckt. Hier was 
ändern und woanders wackelt es dann auch.

Was ich jetzt habe ist eine Frickel Version. Der RNG wurde ja erlaubt 
obwohl es ihn gar nicht gibt, weil der 407 als Basis genommen wurde. 
nDen 401CE kennt es eben nicht. Ein Extended Mem Interface gibt es auch, 
obwohl er keines hat, wie auch mit 64 Pins.

Ich warte sehnlichst auf Embitz 2.0...

Zu den Fehlern: In der CMSIS 2011 und den SPL sind zb Sachen wie 
GetFlags und GetITFlags ab und an mal falsch. Da sucht man sich nen 
Wolf. Wer es schafft die SPL 2016 und CMSIS 2016 als Template zu 
installieren, wäre schon klasse. Ich habe aufgegeben, das ging alles 
schief. Beim 407er klappte es zufällig, weil der ja auch voll 
unterstützt wird von EmBitz.

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
Noch kein Account? Hier anmelden.