search

tenbaht / sduino

An Arduino-like programming API for the STM8
http://tenbaht.github.io/sduino/
GNU Lesser General Public License v2.1
351 stars 213 forks source link

Porting of U8G2 possible/feasible? #34

Open uvwxy opened 6 years ago

uvwxy commented 6 years ago

I thought about porting U8G2 to sduino, but before I continue debugging compiler errors. Is this actually a good idea? (Given that we only have 6+1kb, will u8g2 actually fit on to an stm8s3f?)

tenbaht commented 6 years ago

Interesting idea. That lib looks very interesting as it is very flexible and supports many different displays.

Compiling the Hello World example for an Arduino Uno and a SSD1306 display using HW SPI results in 8060 bytes of flash and 1468 bytes RAM. Compiling for the STM8 typically results in higher flash usage, anywhere in the range between 10% and 50%, and a similar RAM usage.

So probably not usable for the 8kB STMs like the 103, but still interesting for the bigger devices like the STM8S105 used on the Discovery board.

In the beginning the hex files for the STM probably will be much, much bigger than the AVR versions due to a much simpler linking process. The sdcc linker does not leave out unused individual functions, only unused complete modules. To help the linker it might be useful to split bigger source files with many independent functions into smaller compilation units, similar the approach used to split up the SPL files.

It would be great if you could port this lib!

uvwxy commented 6 years ago

IMHO u8g2 would be an ideal candidate to have within sduino, especially as you can use it with page mode (less RAM), and I'm a little familiar with it on the esp8266 👍. As I am tinkering only with the 8kB STMs like the 103, I don't see myself porting this though 😅(also, I'm a noob regarding C/embedded).

But, because I still wanted to show some chars on the screen I hacked/pasted this together: micro-ssd1306 Maybe this is useful for someone sometime. ;)

Next step for me will be looking into reading I2C (BME280, Accel, Gyro, Magnet, ...), so: #28 it should actually be.. can't promise anything though..

(Viele Grüße aus Aachen ;))

tenbaht commented 6 years ago

But, because I still wanted to show some chars on the screen I hacked/pasted this together: micro-ssd1306

Very nice! At first glance it looks like you left the graphic mode (no RAM based display buffer, no drawPixel) and added simple font handling. Maybe it would be useful/possible to integrate the changes? By splitting the source into separate files for the graphic mode and the text mode it would be possible for the linker to leave out unused parts and the final binary would be the same (as long as only one mode is used)

This looks very interesting, but I am afraid I won't have enough time in the next few weeks to work on this.

Next step for me will be looking into reading I2C (BME280, Accel, Gyro, Magnet, ...), so: #28 it should actually be..

Any help on #28 is appreciated! I was planning on working on a DS1307 RTC and a MPU-6050 gyroscope to get the I2C fixed, but I didn't start yet.

uvwxy commented 6 years ago

This looks very interesting, but I am afraid I won't have enough time in the next few weeks to work on this.

Please take a look at my commits. Maybe this is going into the right direction. I had no clue how to manage it with several files, but I managed to exclude either the buffer or ascii mode via -DNO_MINI_SSD1306_BUFFER or -DNO_MINI_SSD1306_ASCII and added an example for ascii mode.

How can I load the 5x7font from flash (progmem?) instead of storing it in RAM (as it does at the moment?)