HALMX :: MXBluePillF103C8 Roadmap

Development of new Cores using the STMCubeMX and HAL
User avatar
Vassilis
Posts: 294
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

HALMX :: MXBluePillF103C8 Roadmap

Postby Vassilis » Mon Apr 18, 2016 6:46 am

On March 2016 I started working on Sheepdoll's (Julie S. Porter) great work on HALMX core files. I focused on STM32F103C8 MCU because it's widely used by STM32Duino members. I think it is very hard for members to watch the whole forum posts and see what feature is added to the HALMX core.
I saw that Sheepdoll has a generic HALMX roadmap but the changes I have done so far are tested only MXBluePillF103C8 variant. Not to the entire HALMX variants. For that reason, I created this post that informs the members with the changes are made by me or any other member, to the MXBluePillF103C8 variant.



Things that work:

[14 May 2016]
* USBSerial. Added support to USB Virtual COM port.
* Bootloader. The Maple DFU firmware upload method is used to upload the compiled sketches to HALMX.

[09 May 2016]
* Added the interrupt based Serial transmission function on Serial1, 2 and 3 ports.

[19 April 2016]
* wiring_analog.c Support to AnalogRead() and AnalogWrite() functions

[14 April 2016]
* SPI library
* wiring.h The delayMicroseconds() was re-written for STM32. The previous assembly code wasn't work correct to the tests I had made.
* wiring_digital.c The LOW and HIGH were placed in reverse on digitalRead(...). Fixed!

[09 April 2016]
* Hardware Serial ports. Serial 1, Serial 2 and Serial 3 work in Interrupt mode.


Things to do:
* Wiring library. Support to I2C interface
* SPI library in DMA and Interrupt mode.
Last edited by Vassilis on Fri Jun 03, 2016 1:36 pm, edited 5 times in total.

User avatar
Vassilis
Posts: 294
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby Vassilis » Mon Apr 18, 2016 5:43 pm

The analogRead() and analogWrite() functions are ready. I will send the PR in 1-2 days.

User avatar
RogerClark
Posts: 5470
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby RogerClark » Mon Apr 18, 2016 10:27 pm

Thanks Vassilis

Sorry I dont have time to do much of this myself.

Im not sure if you did a pull from my repo into yours, as I updated some files to allow use with the bootloader.

Re:Bootloader for all STM32

I dont think we can write one bootloader that would work for all.

I am not sure if all STM32 devices have USB support ??

We could write a serial bootloader for those devices that only have serial, but I doubt there would be much point as I suspect those devices have a built in serial bootloader, or people would just use STLink.

The F4 has built in DFU, but I dont know if its possible to enter DFU bootloader mode from code, or whether it can only be accessed by Boot0 and Boot1.

Anyway I think that writing new bootloaders would be the last think to do.

User avatar
Vassilis
Posts: 294
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby Vassilis » Tue Apr 19, 2016 8:59 pm

I did a pull and I saw your files. Thanks!
On March I did some tests to combine the stm32duino bootloader with CubeMX. That was totally failure. I had changed the flash address from the *.ld file but ... nothing. The bootloader was partially worked. I had unpluged the blupill from the usp port. I pressed the upload button on arduino IDE and simultaneously I plugged in the bluepill to the usb port. With that trick the bluepill was programed successfully.
I am thinking right now one more test to do but it is too late for that now. I will try it tomorrow.

User avatar
RogerClark
Posts: 5470
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby RogerClark » Tue Apr 19, 2016 9:15 pm

Vassilis

The only way I could get the BluePill to work with the bootloader was to unplug it, and then plug it back in, just when dfu-util was searching for dfu devices.

The maple mini worked better, as I just press the reset button when dfu-util is searching.

I dont know why the reset button is not resetting the usb on the BluePill, but the problem may also be because of the Skylake chipset in my new PC, as it is not BluePill friendly and it does not work with the GD32 at all.


Some of the problem with the BluePill is that when the sketch runs, the Windows device manager still shows the DFU device, even though the dfu code is no longer running in the BluePill.

We could force USB enumeration when the sketch starts, but it would then show probably show an unknown device.

I think we need to find some small CDC code to provide USB Serial, as the STM code seems far to big.

Perhaps the libopencm3 code, as used by the BMP could be used to provide the USB.
The interesting thing about the BMP is that it has 3 devices at the same time, i.e. it behaves as a composite device. I think this is the way forward, as I know there is a lot of interest in USB midi and also USB HID ( mouse and keyboard)

If we start with a USB composite device, even with only 1 sub device, it would make it much easier to add additional devices.

User avatar
mrburnette
Posts: 1774
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby mrburnette » Wed Apr 20, 2016 12:34 pm

RogerClark wrote:<...>
The maple mini worked better, as I just press the reset button when dfu-util is searching.
<...>


Generally, my Maple Mini does reset over the comm on Linux Mint 17.3. There has been a few cases recently when I have had to do the unplug-replug procedure but that is on an old Dell (memory challenged) with 32-bit Mint and I cannot remember this happening on the Acer in the lab, a 64-bit Linux install. When using Windows 8.1 64-bit OS, I can remember a time or two of having to press Reset+DFU to lock the bootloader.

IMO there is just a lots of state changes in both the host computer and the maple mini and a reset failure and synchronizing DFU simply fails miserably. The bane of bootloaders.

Ray

User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby Slammer » Mon Apr 25, 2016 9:11 am

I used CubeMX to add support for CDC serial device. I managed to get/put bytes to USB serial but, indeed, the code is much larger than libmaple.
Code raised to 17KB, and the BSS segment to 5KB!, for the typical blink program with some printing. The same code with libmaple is about 14.5KB/1KB.
While this size increase is not a problem for larger devices, is a serious drawback for the small.
I am examining the map file to see what is allocated and why. Maybe, we have to "touch" the MX generated code specially in small devices like "Pills".

User avatar
RogerClark
Posts: 5470
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby RogerClark » Mon Apr 25, 2016 10:28 am

@slammer

I presume somehow the linker is linking functions that are not actually used.

We use the --whole-archive flag on libmaple, on the "archive" code, to ensure that things like the hardware timer ISR's get linked correctly.

I tried removing it from the HALMX core, but unfortunately it didnt seem to reduce the code size.
So either I modified the wrong code in platform.txt, or its not the --whole-archive flag that could be causing the large code.

The other thing that could be tried is somehow compiling the code from the Cube using just a makefile, and see if the CDC code is still too large.

I think @sheepdoll has been trying to compile using Eclipse on OSX, but I'm not sure if she was using an Arduino plugin, or just the files from the Cube.

User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby Slammer » Mon Apr 25, 2016 10:39 am

I am building the code outside Arduino environment using makefile. Comparison is done using the same makefile and maybe the results are a bit different than Arduino's build system. I will play with cflags to see if there is change in size. I am pretty sure that some cleanup is needed specially in arduino core files as many functions are almost implemented in HAL.
The most important is that the code works! Nice job Vassilis and Sheepdoll!

Here is the size report of libcore.a (is the library of all sources):

Code: Select all

arm-none-eabi-size _build/g103c/libcore.a
   text      data       bss       dec       hex   filename
     49         0         0        49        31   dtostrf.o (ex _build/g103c/libcore.a)
    200         0         0       200        c8   itoa.o (ex _build/g103c/libcore.a)
     16         0         0        16        10   new.o (ex _build/g103c/libcore.a)
    904         0         0       904       388   Print.o (ex _build/g103c/libcore.a)
     56         0         0        56        38   RingBuffer.o (ex _build/g103c/libcore.a)
    891         0         0       891       37b   Stream.o (ex _build/g103c/libcore.a)
    292         0         4       296       128   syscalls.o (ex _build/g103c/libcore.a)
    594         0         2       596       254   UARTClass.o (ex _build/g103c/libcore.a)
     94         0         0        94        5e   USARTClass.o (ex _build/g103c/libcore.a)
      6                  0         0         6         6         wiring.o (ex _build/g103c/libcore.a)
    132         0         0       132        84   wiring_digital.o (ex _build/g103c/libcore.a)
    144         0         0       144        90   wiring_shift.o (ex _build/g103c/libcore.a)
     78         0         0        78        4e   WMath.o (ex _build/g103c/libcore.a)
   1897         0         1      1898       76a   WString.o (ex _build/g103c/libcore.a)
    372         0         0       372       174   startup_stm32f103xb.o (ex _build/g103c/libcore.a)
    184         4         0       188        bc   system_stm32f1xx.o (ex _build/g103c/libcore.a)
    342         0         4       346       15a   stm32f1xx_hal.o (ex _build/g103c/libcore.a)
    518         0         0       518       206   stm32f1xx_hal_cortex.o (ex _build/g103c/libcore.a)
   1778         0         0      1778       6f2   stm32f1xx_hal_dma.o (ex _build/g103c/libcore.a)
    826         0         0       826       33a   stm32f1xx_hal_flash.o (ex _build/g103c/libcore.a)
   1136         0         0      1136       470   stm32f1xx_hal_flash_ex.o (ex _build/g103c/libcore.a)
    680         0         0       680       2a8   stm32f1xx_hal_gpio.o (ex _build/g103c/libcore.a)
   7434         0         0      7434      1d0a   stm32f1xx_hal_i2c.o (ex _build/g103c/libcore.a)
   2146         0         0      2146       862   stm32f1xx_hal_pcd.o (ex _build/g103c/libcore.a)
     50         0         0        50        32   stm32f1xx_hal_pcd_ex.o (ex _build/g103c/libcore.a)
    524         0         0       524       20c   stm32f1xx_hal_pwr.o (ex _build/g103c/libcore.a)
   2716         0         0      2716       a9c   stm32f1xx_hal_rcc.o (ex _build/g103c/libcore.a)
    606         0         0       606       25e   stm32f1xx_hal_rcc_ex.o (ex _build/g103c/libcore.a)
   4440         0         0      4440      1158   stm32f1xx_hal_spi.o (ex _build/g103c/libcore.a)
    128         0         1       129        81   stm32f1xx_hal_spi_ex.o (ex _build/g103c/libcore.a)
      0         0         0         0         0   stm32f1xx_hal_tim.o (ex _build/g103c/libcore.a)
      0         0         0         0         0   stm32f1xx_hal_tim_ex.o (ex _build/g103c/libcore.a)
   2590         0         0      2590       a1e   stm32f1xx_hal_uart.o (ex _build/g103c/libcore.a)
   2054         0         0      2054       806   stm32f1xx_ll_usb.o (ex _build/g103c/libcore.a)
    578       272         1       851       353   usbd_cdc.o (ex _build/g103c/libcore.a)
    664         0         0       664       298   usbd_core.o (ex _build/g103c/libcore.a)
    906         0         1       907       38b   usbd_ctlreq.o (ex _build/g103c/libcore.a)
    150         0         0       150        96   usbd_ioreq.o (ex _build/g103c/libcore.a)
    396         0         0       396       18c   _spi.o (ex _build/g103c/libcore.a)
    128         0         0       128        80   gpio.o (ex _build/g103c/libcore.a)
    184         0         0       184        b8   i2c.o (ex _build/g103c/libcore.a)
    200         0         0       200        c8   main.o (ex _build/g103c/libcore.a)
    116         0         0       116        74   stm32f1xx_hal_msp.o (ex _build/g103c/libcore.a)
     98         0         0        98        62   stm32f1xx_it.o (ex _build/g103c/libcore.a)
    360         0         0       360       168   usart.o (ex _build/g103c/libcore.a)
     56         0         0        56        38   usb_device.o (ex _build/g103c/libcore.a)
    124        16         0       140        8c   usbd_cdc_if.o (ex _build/g103c/libcore.a)
    588         0       544      1132       46c   usbd_conf.o (ex _build/g103c/libcore.a)
    243        52         0       295       127   usbd_desc.o (ex _build/g103c/libcore.a)
    448         4       624      1076       434   variant.o (ex _build/g103c/libcore.a)


It is strange how big is the hal_i2c code (almost 7.5K!!!), hal_spi (4.5K), and all parts of usb support
Last edited by Slammer on Mon Apr 25, 2016 11:04 am, edited 2 times in total.

User avatar
RogerClark
Posts: 5470
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby RogerClark » Mon Apr 25, 2016 10:49 am

Ummm

Perhaps there are some postings on STM's own forums about the code size when using the Cube.

Its strange that compiler must be linking so much code that is never being used.


Return to “CubeMX and HAL”

Who is online

Users browsing this forum: No registered users and 2 guests