STM32CubeMX :: STM32F030F4 support

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

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Fri Apr 15, 2016 1:38 pm

I think it is a good idea for me to be focused on the core / libraries development on the STM32F103C8 variant that is widely used by many STM32Duino friends.
When we reach an acceptable development level (at least the basic interfaces such as Serial, SerialUSB, SPI, I2C and the bootloader) we will pass the final settings to the other variants.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Fri Apr 15, 2016 9:12 pm

Vassilis

Thanks, I will delete the old spi files.

Re:STM32F103C8

Yes. Its best to focus on that board, as I think 90% of forum members have that board or a Maple mini.

I have a F407 Discovery board and also a F3 Nucleo, I also have a EMW3195 and a Spark photon which I think contain STM devices.

But I only have time to test the F103

I think getting Serial USB working is the next logical step, as although we can now upload via the bootloader, we have to manually reset to upload, and also need an external USB to serial adaptor

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

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Fri Apr 15, 2016 9:43 pm

The Wire library is coming soon (I2C) ;)

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Fri Apr 15, 2016 10:14 pm

Thanks

I will try to test SPI to LCD screen today

Edit.

I just noticed that the Generic STM32F103C8 variant doesnt have Serial defined.

I will see if I can change the code to make this work, as it appears that Serial1 and Serial2 are defined, but I'm not sure where they point to (probably USART 1 and USART 2, so I may just need to rename the Serial1 object to Serial

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Fri Apr 15, 2016 11:03 pm

Vassilis

FYI

I've just noticed that some core features probably need to be done before the libs

e.g. analogRead does not exist yet.

User avatar
sheepdoll
Posts: 236
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by sheepdoll » Fri Apr 15, 2016 11:23 pm

RogerClark wrote:
I think getting Serial USB working is the next logical step, as although we can now upload via the bootloader, we have to manually reset to upload, and also need an external USB to serial adaptor

Roger;
I have been playing about with the CDC the last few weeks with my NucleoF401. Teasing out the CDC code from the STM "repository" examples and comparing against the code that is auto generated. For some reason, there is no CDC example for the F103 or F401 Nucleos. There are examples in other folders. Comparing them, shows that most of the functionality is identical. The example application is a simple USB/Serial com port adapter. The differences are mostly in the port settings init code. There also seems to be a periodic timer -- probably to poll the stream between the two peripherals.

I was also looking at the "Arduino avr" core. I notice that there is no UART/USART classes. Rather there are a number of "Hardware Serial" classes with a lot of ifdefs. The CDC class seems to be a subclass of Hardware Serial as well. I wonder if this might be a better approach. The awkward here is that AVRs have sort of a fixed serial that does not get re-allocated to other pins. Then there are cases where the USB on the STM32 uses part of the serial peripheral, so that instance serial port has to be disabled.

With the auto generated code I chose the option that splits the devices into separate files. The workflow still remains awkward. The Arduino user wants to instantiate a CDC class. CubeMX prefers that the settings be done inside the GUI. The means that when the Cube code and middlewares are setup. The CDC device is configured. Without the hooks, it does not do much.

CubeMX also provides "Middleware" for a DFU uploaded. I have not looked at that. There does not seem to be a way to enable more than one USB class at a time with CubeMX.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Sat Apr 16, 2016 12:05 am

Julie

Thanks

At least to start with, perhaps we can just use a global instantiation of Serial USB CDC, like libmaple does.

Though it does sound like spaghetti from you you've said.

There are possibly other ways to get a decent USB system using libopencm3, but I don't know if it really uses the CMSIS / HAL ?

Oh. BTW.

I think we should change the compiler warning level, as currently it compiles without errors even when there are critical link errors like analogRead not being implemented.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Sat Apr 16, 2016 7:49 am

I will try to write the wiring_analog.c for supporting the analogRead() and analogWrite() functions.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Sat Apr 16, 2016 8:22 am

Thanks Vassilis

I found this http://visualgdb.com/tutorials/arm/stm32/adc/

https://github.com/arduino/Arduino/blob ... g_analog.c

I think that probably using the Arduino SAM code as a base is probably the best starting point. We can't use their CMSIS calls but at least it gives the list of functions

User avatar
sheepdoll
Posts: 236
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by sheepdoll » Sat Apr 16, 2016 8:28 am

Still can not get CDC to enumerate. I put the code into eclipse, and ran gdb the functions are getting executed as far as USB start.

I compared what the CubeMX generates to the CDC standalone, The code looks really similar although formatting and names are different. With CubeMX you set the USB middleware and can use the Configuration tab to set the device descriptors. I left them alone as they generate the same as the CDC example.

I put some breakpoints on the device descriptor endpoints and when I re-connect the cable, they do get hit. I do not have any resistors on the D+ pr D- lines. from what I read, the VBUS is supposed to identify the device speed. Unless I missed something.


Had trouble with the Window Watchdog again. Not sure what I did to get it to work. I changed some of the linker settings in the makefile to be more like what the ardiuin ide puts out. I am not sure that eclipse is respecting the makefile. To get rid of some bogus warnings I had to set one of the compiler directives in the project. Otherwise the eclipse pre-processor does not see the right header file and GDB reports syntax errors on the macros.

Post Reply