discuss and test TLC5917 initial release

[RobTillaart]

@Devilscave

Created this issue to discuss the initial code of the library.

[RobTillaart]

Released 0.1.0 and registered at Arduino Library manager and PlatformIO.

[Devilscave]

I'm still waiting for the parts

[Devilscave]

Hey Rob, I've received the Chip's. When I have time I'll set up a setup.

[Devilscave]

Ready... Just a quick question, I'm testing your Night-Rider demo first, it seems to work for Arduino, but an STM8 complains when compiling with the following error: libraries/TLC5917/TLC5917.h:21: syntax error: token -> 'TLC5917' ; column 13 This points to the "class TLC5917" Can this be changed or is it only suitable for Arduino? That would be a pity because I wanted to use the 5917 on an STM8 that was previously used together with a ULN2003 but now want to switch to the TLC.

[RobTillaart]

@Devilscave

Will look into this later today, I'm in the middle of "refactoring my house"

[RobTillaart]

installed STM8 boards and get some pop-up

I'm not going to install the license.

[RobTillaart]

NUCLEO-32 (STM32) compiles.

Can this be changed or is it only suitable for Arduino?

It is written with Arduino eco system in mind, yes.

You should comment the line #include "Arduino.h" That will result in several other errors but by including and patching some core functions it will work.

A few test compiles with STM32 gave the following results. Should help you to get started,

// #include "Arduino.h"     <<<< disabled that one and the next includes solves the uint8_t , calloc and free.
#include <stdint.h>
#include <cstdlib>

//  these are the functions you need to have
#define pinMode(X, Y)        {}
#define digitalWrite(X, Y)   {}
#define digitalRead(X)       (1)

// and some constants
#define HIGH    1
#define LOW     0
#define OUTPUT  0

back to my "refactoring"

[Devilscave]

Yes, it seems to work for STM32, unfortunately not for STM8. Unfortunately you can't find anything about it, he keeps complaining about the class, libraries/TLC5917/TLC5917.h:33: syntax error: token -> 'TLC5917' ; column 13

LINE 33 is: class TLC5917

``// #include "Arduino.h" <<<< disabled that one and the next includes solves the uint8_t , calloc and free.

include

include

// these are the functions you need to have

define pinMode(X, Y) {}

define digitalWrite(X, Y) {}

define digitalRead(X) (1)``

I have now changed it because he also complained about the cstdlib. And he didn't want the definitions of HIGH & LOW either because they were duplicated.

[RobTillaart]

Those were the things I found for STM32, that is why I mentioned those. maybe including stdint.h is enough?

[RobTillaart]

We might ask on the Arduino forum if someone has hands on experience with the STM8.

[Devilscave]

It is probably because the STM8 does not cope with "class" as this does not exist in "C" but is a C++ code. The STM8 probably does not like this. I suspect I will have to slowly say goodbye to the STM8. However, an STM32 requires too much periphery to function, so I will probably switch to a LGT28 after all. It has more memory and is faster anyway.

[RobTillaart]

Found this one too: https://github.com/rumpeltux/stm8-arduino

[Devilscave]

NOTE: sdcc does not support C++ and there are some limitations, so the APIs do not match 100%.

[RobTillaart]

So to get it working for STM8 one should "declassify" the library into standalone functions and global variables. Doable as code and function names already exist..

[RobTillaart]

@Devilscave What are your plans?

If you want to use this library code to write a functional version for the STM8, feel free to do so. Please refer to this library in your code as stated in MIT license. (makes it also easy to track / follow updates)

[Devilscave]

I am currently working on two projects, one with the TLC5947 which is controlled by an LGT8F328P. And the second but older project already uses an STM8 in SSOP20 but since the project lacks dimming of the LEDs I wanted to use the TLC5917. However, the board, the circuit, the structure and the code have to be completely adapted. Since all of this is imminent and the STM8 is already far too well equipped anyway, I am not so familiar with C++ and the classes and the Bibilotek programming, it would be more logical to switch to an STM32 in SSOP20, which has more memory, more space and more resources available. And that's what the Bibilotek works for. But I'm currently waiting for suitable hardware again and am currently working on the TLC5947 project again. And if I could get it adapted to the STM8, I would send it to you here. I don't want to distribute it or make a fuss about it, especially not by copying someone else's program and distributing it as my own. I am not a software developer. That's your baby.

[RobTillaart]

@Devilscave

Created a new develop branch with a folder that implements a functional interface. Give it a try. (Experimental)

[Devilscave]

I Test it, but as errors come this: ...\libraries\TLC5917-develop\TLC5917_FUNC\TLC5917_FUNC.h:100: error 65: function 'TLC5917_setChannel' already has body ...\libraries\TLC5917-develop\TLC5917_FUNC\TLC5917_FUNC.ino:20: error 25: Structure/Union expected left of '.->' ...\libraries\TLC5917-develop\TLC5917_FUNC\TLC5917_FUNC.ino:21: error 25: Structure/Union expected left of '.->' ...\libraries\TLC5917-develop\TLC5917_FUNC\TLC5917_FUNC.ino:40: error 25: Structure/Union expected left of '.->' exit status 1

The three Error 25s are due to a spelling mistake, as the STM does not want "." but "_". Thus "Serial_begin".

After adjusting this, these errors were added.

...\Temp\arduino_modified_sketch_699070\TLC5917_FUNC.ino:25: error 101: too many parameters ...\Temp\arduino_modified_sketch_699070\TLC5917_FUNC.ino:52: error 101: too many parameters

[Devilscave]

I fixed the error by excluding the second "bool TLC5917_setChannel(uint8_t * array)" and the serial output as well. Now this comes up, and clearly shows how little memory the SMT8 has.

Globale Variablen verwenden 1112 Bytes (108%) des dynamischen Speichers, -88 Bytes für lokale Variablen verbleiben. Das Maximum sind 1024 Bytes.

[RobTillaart]

Thanks for testing, Good you solved the problems that popped up (as I have no STM8 environment I could not test it thoroughly)

Probably it is possible to squeeze the code a bit more, but I think it will not be worth the effort. So stepping up to the STM32 is imho the way to go.

So I propose we close this issue unless you have related questions. Better to open new issues for STM32 problems if/when they appear.

[RobTillaart]

I am going to delete the develop branch as I see no need to support two versions . If you will you can share your compiling code in this threat (just upload as zip or so) for future reference.

[RobTillaart]

@Devilscave As there will be no further development for STM8 I close this issue.