STM32F401 Embitz1.1 Toolchain gesucht

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 :-)

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

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!

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"

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.

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.

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 ....

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....

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.

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.

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

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

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 */

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.

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.