HALMX :: MXBluePillF103C8 Roadmap

I don’t thing a delay loop for microsecond delay makes sense. It will be interrupted by systick et al.

The one that I’ve seen uses micros() which computes the inter-systick time using the real time counter value from the systick timer, and knows the systick timer clock speed.

But none the less, there’s always that pesky systick interrupt, usually every 1,000 microseconds.

stevech wrote:I don’t thing a delay loop for microsecond delay makes sense. It will be interrupted by systick et al.

The one that I’ve seen uses micros() which computes the inter-systick time using the real time counter value from the systick timer, and knows the systick timer clock speed.
.

The micros() function is part of arduino api and it is good to have it in our implementation. The function is not dedicated to delays, is a generic function and can be used for measurement of execution time of a procedure or any other purpose.

GrumpyOldPizza, nice code. I included in my Big Book of snipplets….

long blurry day, why don’t i follow this line, it seems to be a potential race with the first line in the braces.

while (ms != HAL_GetTick());


zmemw16 wrote:@racemanic did your bulk buy arrive (10off 1g) ?

stephen

apols, didn’t realize, truly long and blurry
srp

zmemw16 wrote: long blurry day, why don’t i follow this line, it seems to be a potential race with the first line in the braces.

while (ms != HAL_GetTick());


zmemw16 wrote: long blurry day, why don’t i follow this line, it seems to be a potential race with the first line in the braces.

while (ms != HAL_GetTick());


The SerialUSB library is almost ready.

@vassilis I merged the PR

I have one other PR https://github.com/rogerclarkmelbourne/ … M32/pull/7, but I’m waiting for a reply from @sheepdoll, as it may effect the Mac

We also have the code for micros() which needs to be manually merged as its not a PR

Slammer wrote:zmemw16 wrote: long blurry day, why don’t i follow this line, it seems to be a potential race with the first line in the braces.
Thanks GrumpyOldPizza for clarify this…. yes, this value is changing very fast. I am not sure if the two nops are required…. No big difference anyway.

I think I found out why I was unable to run my Nuleo F103RB from the laptop running OS X 10.10.5

When I compared the build download output to the OS X 10.7.5 I found that the file startup_stm32f103xb.s was not being included. I noticed that on the 10.7.5 the suffix was uppercase ‘S’ changing this on the 10.10.5 machine the blink sketch ran.

I noticed that in the platforms.txt file the recipe for assembler is uppercase ‘S’ I also notice that on the F4 variant I had copied this file to the top of the variant tree and must have renamed it as there is both a file with a small ‘s’ in the drivers..gcc path and the one with the uppercase ‘S’ that is peer to variant.cpp and the .ioc file. So I must have run into this before and forgot about it.

@sheepdoll

I think @vassilis has a windows bat file which changes the case of assembler file extension (Or perhaps it was a script, I definitely remember seeing a script that changed it)

I have same issues with UARTs. The code of HALMX does not handle IRQ transmits in a way compatible with arduino core lib, actually the core sends the bytes one by one taking no advantage of IRQ nature of HAL. Some rework is needed but I will wait Vasilis to finish a “batch” of his work before any modification.

I will try to finish the interrupt based serial transmission as soon is possible.

Slammer wrote:I have same issues with UARTs. The code of HALMX does not handle IRQ transmits in a way compatible with arduino core lib, actually the core sends the bytes one by one taking no advantage of IRQ nature of HAL. Some rework is needed but I will wait Vasilis to finish a “batch” of his work before any modification.

Yes stevech, you are correct, UART transmission via DMA/IRQ is simple and correct as you know the data length, the problem is that arduino api calls the transmission function to send only one byte at a time making the DMA/IRQ useless as the next byte transmission waiting the previous to complete (at least with the current HALMX implementation).

Is added the Interrupt based transmission function on Serial1, 2 and 3 ports.
I sent a PR to Roger.

Slammer wrote:Yes stevech, you are correct, UART transmission via DMA/IRQ is simple and correct as you know the data length, the problem is that arduino api calls the transmission function to send only one byte at a time making the DMA/IRQ useless as the next byte transmission waiting the previous to complete (at least with the current HALMX implementation).

Arduino’s “gate” to lower routines (eg. HAL transmit) is the write function, which passes only one byte to transmit function. Any higher level routines like writeln(string) calls multiple times the write function sending bytes one by one.
Normally the write function “pushes” a byte to the ring buffer and triggers manually the transmit interrupt if the transmission is inactive. A next call of write function simply pushes a new byte to ring buffer if the previous is not completed. The irq transmit function checks the ring buffer and if is not empty sends the next byte. With this way every write takes only the time of pushing the byte into the ring buffer ( less than usec in our case) and the transmission is actually a chain of transmits initiated by first write and controlled by irq function itself, of course, somewhere there is a check to avoid overflow of buffer (eg. the write checks if buffer is full and if it is, waits or discards the new byte).

PS. I didn’t check the new version yet…