Develop STM8L on Discovery Board?

[johnjohn9107]

Posted on August 02, 2013 at 10:48

I've got an STM8L Discovery board, but I've decided to use the STM8L101 chip. Is this chip a subset of the 

STM8L152C6T6 used on the didcovery board? Does the swim use the same IO port/pins on both chips? 

Or do I need to spend another �100 on an STM8L 101 EVAL board???I'm trying to set up a new project so I'm trying to get my head round tons of stuff. I'm also an old bloke who just wants to get going rather than be circle jerked round enless web pages!Del(grumpy mode off) #stm*l101

[fggnrc2]

Posted on August 02, 2013 at 13:22

Hi Derek.

STM8L101 micros are low-density devices, while the STM8L152C6T6 which is soldered in a STM8L Discovery board is a medium density one. STM8L medium density devices are ''older'' than STM8L101s, whose internal peripherals are more advanced (for instance, their RTC has a subsecond field, they can be better synchronized, ...). If you don't need those advanced features from the start, you can begin developing your project with a STM8L Discovery board and use a STM8L101 micro in a later prototype, because they share almost any feature. You can also use the SWIM programming interface of the STM8L Discovery board, so there is no need of acquiring a STM8L 101 Eval board (in my opinion). EtaPhi

[johnjohn9107]

Posted on August 03, 2013 at 09:30

Thanks for that. I know once I get going it will be fine. I just hate crawling up the learning curve for a new micro. I also hate 'C' IMO assembler is so much simple for small scale applications as you'll prob need to write your own drivers for your own hardware... latching solenoids, motors etc.

Message could not post... expected ';' at the end of every lineMissing '{ ' just about everywhereDerek ;)

[fggnrc2]

Posted on August 04, 2013 at 09:24

I agree with you, Derek.

I develop my STM8 applications in assembler, thus I can share what I learned with you and this forum. STM8 assembler is stable, since there has been no change since 2008, i.e. the STM8 introduction. STM8 peripherals evolve with time. The learning curve therefore never stops but its end is flat because all changes are small. For instance, first STM8 devices (e.g. STM8S family) have got no DMA. If an application for these ''old'' devices uses ADC, it had to handle EOC (End Of Conversion) interrupts. The EOC interrupt handler has to read ADC data registers, change analog input channel, and start a new acquisition. The DMA takes care of this in ''new'' devices. You select which analog channel has to be acquired and DMA stores their sampled value in your data structure. Even if ADC didn't change, the DMA changes how it's used, so there is always a bit to learn. The steepest learning curve for a new micro isn't due to its core, but to its peripherals. The 'C' language and ST firmware library shorten the learning curve, but decrease your understanding and options. As it happens for Arduino, where a library frees users from knowing how a micro works, these tools make it easy to develop a new application but hide you some precious informations. For instance, there is a bit in CFG_GCR register which controls what happens when the STM8 core is executing a WFI instruction. When this bit is activated (i.e. when the core activation level is one), an interrupt can wake the core up, but when it will execute the next IRET instruction, the main will not resume. This allows a fast interrupt response, because no context has to be pushed onto the stack, but what happens when more interrupts are pending? The standard solution is a FIFO policy: the first arrived interrupt is executed. When its code ends with an IRET, the pending interrupt with the highest priority gets executed and so on until all pending ones are serviced. This is fine until no slow peripheral (e.g. RTC) blocks an interrupt handler and another interrupt handler (e.g. USART receive) gets so much delayed that an error happens. My assembler solution is simple: before enabling interrupts inside a slow handler with a RIM instruction, my code changes the activation level and resores it before executing an IRET instruction. The 'C' version of this solution is as simple as the assembler one (a function call and two assigment operations with a register), but if you don't know (or don't want to know) what happens inside a library, you can't fix some buffer overrun errors that seldom happen. There is a reward in learning how peripherals work. STM32 and STM8 micros share the same peripherals. TIM1 behaviour is therefore the same in both platforms. The middleware, for instance SD Cards FAT16/FAT32 support, or RTOS availability, makes a difference between assembler and 'C', since there is no assembler version. For this reason, I had to write my FAT16/FAT32 drivers to support microSD in my application. This takes time, because you can't reuse someone else work... While the STM8 core is ''assembler friendly'', the STM32 one isn't so much friendly because the 'C' compiler code optimization is so good that it's a time waste to develop some assembler code. You still have to learn ARM assembler to sometime understand compiler output, but there is no need to write any assembler line! Assembler use and knowledge is decreasing because the price difference between STM32F0xx and STM8xx micros is so small (some USD cents) that there is no point in wasting time and money to use an 8 bit device. Of course, the 'C' compiler and tools make a difference. STM8 assembler and tools are free, unlimited and pre-packaged, so their upgrade is very simple and cheap. STM32 compilers, debugger and tools must be purchased from a software vendor if you don't want to download, install and configure them every time you need a new version to fix a toolchain bug... Your experience may be different, but I still believe that assembler knowledge makes a difference! BR EtaPhi

[qqqq1961]

Posted on April 17, 2014 at 19:32

I've got an STM8S Discovery board, but I've also the STM8L101 chip.

I cannot find info how connect my chip to the board for programming. Please help me by link or words!