stm8s207k UART question
Closed this issue · 9 comments
Hello Thomas,
How to go about the stm8s207k chip regarding the uart and the serial console ? The 32-pin package does not seem to provide the uart1 access. PA4 and PA5 are not accessible and according to the wiki only uart1 is currently supported as the forth console. Thanks.
Hi - nice you're using the 32pin package - that one is still on my shopping list and this is a complication that I wasn't aware of!
Some patching will be required. Let me try to get something working with UART3 :-)
STM8S207 UART3 has the same address as STM8S105 UART2.
Using the following hacked target.inc works:
; STM8S207RB device and memory layout configuration
TARGET = STM8S105K4
RAMEND = 0x17FF ; system (return) stack, growing down
EEPROMEND = 0x47FF ; STM8S207RB: 2048 bytes EEPROM
FLASHEND = 0xFFFF ; 32 KiB devices (+96 KiB > 0xFFFF )
FORTHRAM = 0x0040 ; Start of RAM controlled by Forth
UPPLOC = 0x0060 ; UPP (user/system area) location for 6KiB RAM
CTOPLOC = 0x0080 ; CTOP (user dictionary) location for 6KiB RAM
SPPLOC = 0x1680 ; SPP (data stack top), TIB start
RPPLOC = RAMEND ; RPP (return stack top)
Using the STM8S105K4 binary should work, too, but I'll add a better way to select the console UART.
Here is a binary: STM8S207RB_UART3.zip
Thank you ! I didn't expect for your answer to be so super fast, Now I am ashamed it didn't occur to me to compare the uart addresses between the chip "families". The 32pin qfp package is just so easy to hand solder that I can't talk myself out of using it, but I can see using qfn packages has its advantages too, once you master soldering them onto the pcb. The thermal pad might be a challenge for some - if you put too much solder paste you may end up with unconnected tiny pads at the egdes. Thanks again. Will play with the binary this evening for sure.
There is no reason to feel bad about it - I spent some time over ST's marketing-inspired datasheets wishing they'd just publish a synopsis. Thanks to your question I found another bug that made using the serial interface simulation (using TIM4) unusable. I'll likely change most of the hardware configuration to defines like STM8S_LOW_DENSITY, this should make things easier.
You're right about soldering the LQFP32 0.8 package: hand-soldering is easier to do than 0.5 pitch but not by much: the spacing is 0.45mm instead of 0.28mm and excess solder is more difficult to remove when the pins are wider. I wrote a bit about using break-out boards here.
Success with STM8S207 hacking! I'm currently thinking about how to make best use of the upper 96K Flash memory. A block transfer and indexed byte read/write are on my list.
Success with STM8S207 hacking! I'm currently thinking about how to make best use of the upper 96K Flash memory.
- Store source code.
To me a major advantage of 4th is being able to work on it into the indefinite future, but without saving the source on the target this advantage often disappears.
I did some experiments compressing small 4th files with various naked compressor utilities. I found that 7zip was always as good as the best, except for the small overhead of ~50bytes. Since it can bundle multiple files i.e the whole project, that's a small drawback
- Data logging storage ring-buffer for data loggers.
Success with STM8S207 hacking! I'm currently thinking about how to make best use of the upper 96K Flash memory.
1. Store source code.
Interesting, that's what I had in mind :-) A compression algorithm could easily be implemented in Forth (e.g. one with a fixed dictionary) but is it really necessary? Most programs should fit in 96K without any compression.
How about a screen/line editor to go fully close the gap to self-contained embedded control programming?
2. Data logging storage ring-buffer for data loggers.
Sure, that's also an option. However, storing data in Flash memory without stalling execution requires running code from RAM. This means that the logging code must be written in machine code or else all necessary Forth words must use RAM. Also interrupts can't be used, which means that timers must be polled. The amount of RAM in the STM8S207 should still be sufficient for such a system.
Interesting, that's what I had in mind :
I'll spawn a new issue to discuss it.
- Yes you stall during writes. This is no problem for 90% of slow logging tasks that one would consider storing into program flash. The main issue being ensuring that your rt clock time runs correctly over the store. As a matter of interest, does running from ram use less current than flash on stm8l
(BTW, don't let me spin your wheels on these, I am more throwing ideas out I have been thinking about, than requesting you do actual work on stuff you aren't using)
No problem - I'm in a recreational tinkering mood ;-)
STM8L "Low Power Run mode" (STM8L051, STM8L15x/16x) requires shutting down Flash memory to achieve the specified < 6µA at 38 or 32 kHz clock. Everything else, except the LCD, needs to be shut down, too, so when shutting down GPIOs and ADC what you get is essentially a wall clock with data processing.