Forum : ST7/STM8
Original Post
Post Information | Post |
---|---|
December 15, 2009 - 11:53am
|
Hi, Is it STM8S-Discovery (http://st.com/stm8s-discovery) _officially_ supported by RCSTM8 compiler? I have ported, using above-mentioned compiler, a working little test program from STM8128-EVAL/A (STM8S208MB) to STM8S-Discovery (STM8S105C6) where unfortunately this stop to work. In particularly printf() function don't work anymore. In first occurrence of this function micro "freeze" completely. Under Cosmic compiler it works out-of-box but I just bought RCSTM8 and obviously I'm particularly interested to working with second one :-) Could anyone give me some suggestions? Thanks in advance! Ciao, |
All the compiler knows & cares about is the chip - the details of the external hardware connected to the chip are irrelevant to the compiler.
In other words, if the compiler supports your chip, then it makes no difference to the compiler whether that chip is on a Discover board or some other board.
It is up to you, the programmer, to ensure that your software is correct for use on your particular hardware.
If printf is "freezing", I suggest that you check your UART code carefully.
Also check whether Raisonance's implementation of the printf library function - and any other low-level support fucntions - is correctly configured for the target...
Hi Alessio and Andy,
Actually there IS a problem with the STM8S105 putchar function: It currently uses the STM8 UART1, whereas the UART2 should be used instead (as it is the only available UART on STM8S105).
We only got some sample boards one week ago, and discovered the problem only then.
We ported the putchar to the STM8S103, but it will not be available until next release of RKit-STM8.
As a workaround, you can add an "stm8s105_putchar.asm file to your project with the following contents:
This will ensure that your putchar works fine, hence printf will be ok.
Let us know if this fixes your problem,
Bruno
Indeed - although that's to do with the chip - not the board on which it's mounted.
And it's not really a compiler problem - the compiler generates good code for the chip - it's a configuration problem in the support library.
Whenever one ports code from one chip to another, one should should expect to have to pay close attention to such details as these:
- are the correct ports/peripherals used?
- are they correctly configured?