SDCC compiler for STM8

[spth]

Currently, atomthreads supports the STM8 via non-free compilers only. How about adding support via free SDCC?

Philipp

[kelvinlawson]

This would be nice. Particularly if the ucsim simulator works on STM8 so that we can run the automated test suite without real hardware.

Is this something you would consider contributing if I were to provide some advice if you needed it? There typically isn't a huge amount of code to add a new compiler and there are fairly detailed comments.

[spth]

On 02.01.2016 00:28, Kelvin Lawson wrote:

This would be nice. Particularly if the ucsim simulator works on STM8 so that we can run the automated test suite without real hardware.

How much work in ucsim would this require? AFAIK ucsim for STM8 does not have support for any peripherals or interrupts yet.

Philipp

[kelvinlawson]

How much work in ucsim would this require? AFAIK ucsim for STM8 does not have support for any peripherals or interrupts yet.

That's a shame - it would have been nice to have it working in a simulator.

So we'll have to run it on STM8 hardware instead then. How would you feel about looking into adding the SDCC port, if I give you some guidance when you need it? It would be great to have it working on a Linux-hosted compiler.

[spth]

On 02.01.2016 11:16, Kelvin Lawson wrote:

How much work in ucsim would this require? AFAIK ucsim for STM8 does not
have support for any peripherals or interrupts yet.

That's a shame - it would have been nice to have it working in a simulator.

What would be necessary apart from interrupts? GPIO? UART? Timers?

Philipp

[spth]

On 02.01.2016 11:16, Kelvin Lawson wrote:

So we'll have to run it on STM8 hardware instead then. How would you feel about looking into adding the SDCC port, if I give you some guidance when you need it? It would be great to have it working on a Linux-hosted compiler.

I'm open to that, but don't know how much time I'll find in the near future.

Philipp

[spth]

On 02.01.2016 00:28, Kelvin Lawson wrote:

This would be nice. […]

Is it likely that some of SDCC's current limitations would become serious problems for porting?

IMO, SDCC is doing rather well in standard compliance, but there are still some gaps. Most notable for C90 is probably that struct and union cannot be assigned, passed or returned. Also, there are some STM8-specific aspects not yet supported. Most notable 24-bit pointers, limiting code size to 32K.

Philipp

[kelvinlawson]

What would be necessary apart from interrupts? GPIO? UART? Timers?

Should be just one timer, an interrupt for the timer, and UART. No GPIO required.

Is it likely that some of SDCC's current limitations would become serious problems for porting? IMO, SDCC is doing rather well in standard compliance, but there are still some gaps. Most notable for C90 is probably that struct and union cannot be assigned, passed or returned. Also, there are some STM8-specific aspects not yet supported. Most notable 24-bit pointers, limiting code size to 32K.

I don't think there are any struct or union assignments - it's all fairly simple, portable and lightweight. 32K should also be fine for STM8.

[spth]

I have started a port to SDCC in my fork. Current state: kern1 and kern2 pass, kern3 and kern4 hang, didn't try any other tests yet.

Philipp

[spth]

timer1 and timer3 to timer8 pass. timer2 hangs.

Philipp

[spth]

Hmm, recompiling with current SDCC, I get "Main stack overflow" on all kern? tests.

Philipp

[spth]

To be exact, I get this:

Main stack overflow MainUse:0 Fail(1)

Odd, the stack is both overflowing and of size 0. And that's the only error.

Philipp

[kelvinlawson]

Great to hear that you're working on an SDCC port.

Those stack errors imply that the stack_size element of the task's TCB is zero, could it be getting zeroed after starting the thread?

[spth]

Now I put debug printf() around the Go in main_thread_func():

printf("%d \n", (int)main_tcb.stacksize); /* Put a message out on the UART / printf ("Go\n"); printf("%d \n", (int)main_tcb.stacksize); / Start test. All tests use the same start API. */ test_status = test_start();

I get

256 Go 8194 Main stack overflow MainUse:13794 Fail(1

Before the "Go" the tsack size is till correct. But after it is not. So even that early the stack size gets messed up.

Philipp

[tidklaas]

What libc are you using? I ran into similar problems on Cortex-M and was unpleasantly surprised by how much stack space newlib's non-nano printf() needs. You could call the first printf() twice, just to make sure that it is not the printf() overflowing the stack.

[spth]

I'm using the libc that comes with SDCC. It has different printf() variants, and I'm using the default (in the SDCC sources aka printf_large). And that's indeed the problem. Increasing the main thread stack size, I get for kern1:

Go MainUse:281 Pass

I'll have a look at the other tests next.

Philipp

[spth]

I increased the main thread stack size in my fork to 384 bytes. All tests except for queue5 and queue6 now pass. I have not yet been able to run queue5 or queue6. For these two test I only see the "Go" output. I don't know if there is a real problem or the tests just take a very long time.

Philipp

[spth]

I left queue5 running for 8 hours. I still don't see any output beyond the "Go". Any idea why these two tests don't complete? Where should I look for the problem?

Philipp

[tidklaas]

Have you tried increasing TEST_THREAD_STACK_SIZE in atomport-tests.h?

[spth]

I had tried doubling it to 256 before, but that didn't work. Now I had a closer look, and finally changed it to 192. All tests now pass. 256 is too much for the STM8S105C6 on the STM8S-Discovery, but 128 is not enough for queue5 and queue6.

Philipp

[spth]

The SDCC port has been complete for a while. Any chance of it getting merged? Is there anything that still needs to be done?

Philipp

[kelvinlawson]

Hi Philipp, sorry for the long delay - I was hoping to find the time to do regression tests on Raisonance etc compilers but business has been getting in the way. In any case it looks like there are minimal changes that would affect the other compilers other than the larger stack size.

Looks like a nice port and really good to have a Linux compile option for STM8, thanks a lot for the contribution!