Spark Logic

HALMX :: MXBluePillF103C8 Roadmap

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.

Replies

RogerClark Sun May 15, 2016 7:46 pm

thanks

ekawahyu Sun May 15, 2016 11:18 pm

I am trying to build MXBluePillF103C8 using SW4STM32. I imported the project and there was an error saying that it could not find variant.h. I added the root folder of MXBluePillF103C8 and I am getting another error:
Documents/Arduino/hardware/HALMX_Arduino_STM32/HALMX/variants/MXBluePillF103C8/variant.h:36:21: fatal error: Arduino.h: No such file or directory

Vassilis Mon May 16, 2016 12:40 am

Do you use arduino IDE 1.6.5 or 1.6.9 ?

ekawahyu Mon May 16, 2016 12:54 am

It works just fine when I build with Arduino IDE 1.6.5 or 1.6.9. But no success to build within SW4STM32. Is there any definition I need to add when I call make?

ekawahyu Wed May 18, 2016 12:04 am

@Vassilis: I have one question about this constant variable declaration:
extern const Pin2PortMapArray g_Pin2PortMapArray[]

sheepdoll Wed May 18, 2016 1:31 am

ekawahyu wrote:@Vassilis: I have one question about this constant variable declaration:
extern const Pin2PortMapArray g_Pin2PortMapArray[]

ekawahyu Wed May 18, 2016 3:36 am

@sheepdoll: thanks for explaining it in detail. I finally managed to make the blink sketch to work with Makefile!

I had to comment out these two lines due to conflict (itoa.h):

#if 0

extern void itoa( int n, char s[] ) ;

#else

extern char* itoa( int value, char *string, int radix ) ;
extern char* ltoa( long value, char *string, int radix ) ;
//extern char* utoa( unsigned long value, char *string, int radix ) ;
//extern char* ultoa( unsigned long value, char *string, int radix ) ;
#endif /* 0 */

sheepdoll Wed May 18, 2016 4:40 am

By chance I am at the local maker space it is “Arduino night.” So I was merging in some of Vasslils code and my Nuleo project stopped compiling. So I find that the Pin2PortMapArray has been extended to handle the ADC and timer settings. So much for a quick fetch, merge compile and push.

The good thing is Vassilis made the changess to the global that I was planning and saves me a lot of time. Yay for collaboration.

Now I have to make these changes manually for the F103 Nucleo pins.

there was another thread here about itoa adding a lot of bloat to the code. Probably because most big iron implementations just call sprintf to do itoa. Not efficient, but effective.

Back when I was learning code 40 years ago you had to learn how to code itoa and ftoa from first principles. Hint it involves modulus and divide by 10. So good code needs to use a fpu if available. Ftoa is much more complex. The difference between Woznick and Gates as according to Issacson’s Biography this may be the one thing Gates did at MIT. On the other hand my example was from the HP2100 manual, so it was more of a case of knowing where to look.

ekawahyu Wed May 18, 2016 6:35 am

Gosh! I would never be able to beat you bear metal! I just recently started to play with the 32-bit platforms. Mostly what I did was on 8-bit MCS51 and its derivatives. I can do C very well, but never done anything like mixing C and C++, or call C function with C++ (or vice versa).

Anyway, I tried to build again the code with gcc 4.8.3 and those commented lines are fine to be included. I guess with the latest compiler (or maybe the new library), we need to put #if #endif to exclude those lines.

Slammer Wed May 18, 2016 7:21 am

ekawahyu wrote:
…
I had to comment out these two lines due to conflict (itoa.h):
…

ekawahyu Wed May 18, 2016 7:34 am

Ok, that works! I am using 5.2.1

ekawahyu Thu May 19, 2016 5:33 am

I got a little issue with STM32CubeMX, you guys probably already know the answer. I am trying to configure an auto-reload timer with an interrupt. I can enable/disable it, but the Preemption Priority number is always greyed out. I could modify the source code, but that would defeat the purpose of generating the code from STM32CubeMX. Do I need to configure something else so that this Preemption Priority can be modified?

stevech Thu May 19, 2016 4:00 pm

It’s rare to need preemption. Is there a particular rationale for needing it?

I have one situation where it’s needed, due to high frequency EXTI interrupts from an ASIC than needs a few tens of microseconds’ interrupt latency worst case. CubeMX lets me set that preemption priority.

For recurring timer interrupts, as I recall, the timer hardware (not the ISR) reloads the interval counter automatically if configured for such.

Vassilis Thu May 19, 2016 6:52 pm

ekawahyu wrote:I got a little issue with STM32CubeMX, you guys probably already know the answer. I am trying to configure an auto-reload timer with an interrupt. I can enable/disable it, but the Preemption Priority number is always greyed out. I could modify the source code, but that would defeat the purpose of generating the code from STM32CubeMX. Do I need to configure something else so that this Preemption Priority can be modified?

ekawahyu Thu May 19, 2016 7:59 pm

I have been there and enabled the interrupt, but it is still greyed out. Even I tried to save it, generate the code, etc. Could you show it the exact steps you did on BluePill? I must have missed one step somewhere.

Vassilis Thu May 19, 2016 8:47 pm

nvic_.jpg
nvic_.jpg (145.94 KiB) Viewed 1036 times

ekawahyu Thu May 19, 2016 9:49 pm

Got it! My bad, I didn’t look at the System tab for the NVIC. All is good! Thanks Vassilis!

ekawahyu Fri May 27, 2016 6:24 am

@Vassilis: I can see that the USBSerial has RX (and potentially TX) buffers, but I also see that usb_cdc_if.c has both RX and TX buffers declared instead of pointing to the USBSerial’s. What is your plan with this? Which one you would get rid of?

Vassilis Fri May 27, 2016 11:35 am

ekawahyu wrote:@Vassilis: I can see that the USBSerial has RX (and potentially TX) buffers, but I also see that usb_cdc_if.c has both RX and TX buffers declared instead of pointing to the USBSerial’s. What is your plan with this? Which one you would get rid of?

ekawahyu Fri May 27, 2016 5:11 pm

I have both implementations of buffered TX and RX using the generated code by STM32CubeMX. I just increased the size of APP_TX_DATA_SIZE and APP_RX_DATA_SIZE from 4 to 128. Then I added the __io_putchar() and __io_getchar() to make it work with printf() and getchar(). I can try to point rx_buffer to use UserRxBufferFS and see if we can make it work the same way with tx_buffer. What do you think?

The new ring_buffer structure should look like this:

struct ring_buffer{
//uint8_t buffer[CDC_SERIAL_BUFFER_SIZE];
uint8_t *buffer;
volatile uint16_t iHead;
volatile uint16_t iTail;
};

Sign in to reply