Shop OBEX P1 Docs P2 Docs Learn Events
TM1637 Driver (C) with Demo — Parallax Forums

TM1637 Driver (C) with Demo

JonnyMacJonnyMac Posts: 9,102
edited 2019-12-21 01:00 in Propeller 1
As an exercise I decided to convert my TM1637 driver from Spin to C. I still need to document the code, but it does seem to be working properly.

An interesting note... converting the Spin code to C caused me to think about the str() function differently. I went back to the Spin version and was able to improve the speed of str() by 2x, and give it better behavior vis-a-vis strings with decimal points. The two versions are identical now.

Any feedback you care to offer is appreciated.

Comments

  • Library code has been documented, and a few improvements made as well.
  • RaymanRayman Posts: 14,640
    Did you try spin2cpp?
  • JonnyMacJonnyMac Posts: 9,102
    edited 2019-12-21 06:08
    No, I did it manually to reinforce learning C on the Propeller. And... being as A/R as I am about my code, I wanted to have full control of anything I release to the public with my name on it.
  • Thanks Jon for taking the time and effort to provide some C code. I am glad that you did the conversion manually, now I can look at the Spin version and compare the coding style to the C version. Maybe I will get a better handle on doing manual Spin to C code conversions. Now with the availability of FlexGUI, lets see, basic, micropython, …

    Ray
  • JonnyMacJonnyMac Posts: 9,102
    edited 2019-12-21 22:01
    Thanks Jon for taking the time and effort to provide some C code. I

    You're welcome. The process requires more effort than I like, so I'm not sure I'm going to update my entire library of Spin objects. We'll see; I don't know if SimpleIDE is getting in my way, or my own ignorance of how to use it. It seems like the process of creating and editing the .h and .c files for a C library is more cumbersome than it should be.
  • I hate to say this but, don't waste any more of your time trying to make your C code work with SimpleIDE. I think that a lot of people have given up on SimpleIDE, and I am just about ready to say, I quit, also.

    I am not sure how much more improvement Eric has made with the FlexGUI C, but that just might be a better platform to deal with. At least with FlexGUI C, I think the use of libraries would work out better, less cumbersome for everybody.

    The big problem with SimpleIDE is, all the C drivers that are in the Simple Library, is a real pain to extract. And if you add something to the Simple library, on your computer, it is not universally available for everyone. I do not think that anybody will be wasting their time to extract the C drivers from the Simple Libraries.

    Ray
  • The last I read, the C component of the FlexGUI ecosystem is not completely implemented. I am going back and forth between my TM1637 and TM1638 drivers for both Spin and C -- will try to post updates tomorrow. Am trying to be as consistent as I can across both languages, though I have a string formatting object that I use in Spin that I don't have in the C version.
  • JonnyMac wrote: »
    The last I read, the C component of the FlexGUI ecosystem is not completely implemented. I am going back and forth between my TM1637 and TM1638 drivers for both Spin and C -- will try to post updates tomorrow. Am trying to be as consistent as I can across both languages, though I have a string formatting object that I use in Spin that I don't have in the C version.

    There are still a few features missing in FlexGUI's C, but it's mostly complete. The main missing piece is that structure passing and return isn't implemented properly (some cases work but some don't). Most programs in practice pass pointers to structures rather than the whole structure, and that works fine.

    There are a few C samples in the flexgui samples folder. I think your demo should be able to compile with FlexGUI, unless it depends on simpletools (which at present hasn't been ported... As far as I can see it's awkward to use simpletools.h outside of the SimpleIDE environment, which does some magic things behind the scenes to hide a lot from the compiler).
  • I'll give it a try.
  • I was able to get your demo to compile with FlexGUI, but it took a few changes (some of which revealed bugs in fastspin which I will fix):

    (1) I moved all the "static" declarations from tm1637.h to tm1637.c. Stylistically a .h file should not have any "static" definitions; those declare private variables which are not accessible anywhere else. That means that every .c file which #includes the .h will get its own copy of those variables, which causes data bloat. I believe what you really wanted with those variables was to declare them in tm1637.c.

    (There was also a bug in fastspin which caused a complaint about a static being initialized twice in different files. That should actually be legal, since those are different variables, but that's what clued me in to the fact that multiple copies of e.g. the hexTable[] array were being created.)

    (2) I changed "const static" to "static const" to work around another bug in fastspin (which will be fixed Real Soon Now, thanks for the example which reveals it).

    (3) In TM1637_Demo.c I replaced the "#include "simpletools.h" with:
    #ifdef __FLEXC__
    #define pause(x) pausems(x)
    #else
    #include "simpletools.h"
    #endif
    

    pause() seems to be the only function used from simpletools, and fastspin has a built-in that does the same thing. For porting to Catalina and other C compilers you might want to provide your own pause() function using waitcnt, but that's a minor issue.
  • RaymanRayman Posts: 14,640
    With Flexgui, you should be able to use the Spin object driver from C code.
    At least, I think that is so...
  • Rayman wrote: »
    With Flexgui, you should be able to use the Spin object driver from C code.
    At least, I think that is so...

    Sure. Or you could use the C driver from Spin code, whatever way you prefer is fine. Some people will prefer to read/write C rather than Spin. I think in this particular case Jon was exploring the use of C on the Propeller, and FlexGUI is a usable option for that. There are other reasons to port the code from Spin to C (e.g. having a portable driver that will work in PropGCC, Catalina, and FlexGUI is sometimes nice).
  • JonnyMacJonnyMac Posts: 9,102
    edited 2019-12-22 18:08
    Rayman wrote: »
    With Flexgui, you should be able to use the Spin object driver from C code.
    At least, I think that is so...
    I've done that. Again, I am doing this as an exercise to improve my C programming skills in the event a client asks for code in C (so far, none has, but I'm not taking that chance).

    ersmith wrote: »
    Sure. Or you could use the C driver from Spin code, whatever way you prefer is fine. Some people will prefer to read/write C rather than Spin. I think in this particular case Jon was exploring the use of C on the Propeller, and FlexGUI is a usable option for that. There are other reasons to port the code from Spin to C (e.g. having a portable driver that will work in PropGCC, Catalina, and FlexGUI is sometimes nice).
    It's not likely that I will ever mix languages in a client project, but it's interesting that FlexGUI allows it. A couple weeks ago I wrote a C program that used a bunch of my Spin drivers. What I like about FlexGUI is that it doesn't hide anything when it comes to the command line. What I don't like is the super minimalist editor. I understand that this is about a cross-platform test-bed for fastspin, not about creating a new editor. I am asking Jeff Martin of Parallax to look at your approach in FlexGUI: allow an easy selection of target and user customization of command line by advanced users. I know that Jeff is updating Propeller Tool to support the P2, and I hope he takes the approach you used in FlexGUI.

Sign In or Register to comment.