I’m trying to port this code into something that compiles/works on the Spark Core. I’m new to porting code from Arduino to Spark, so any pointers would be helpful!
In the header file, there are references to Arduino, AVR, ARMEL, and PIC32MX, but nothing regarding the STM-based chip. What definitions would be closest/appropriate for choosing when porting this?
@Catfang, I’ll take a closer look at the library tonight and give you some pointers. If you’re stuck, I can do the port for you 
Thank you! I don’t mind doing the port, but I’m going to need a little guidance to get started. For instance, should I add another set of #if-#endif for Spark Core and try to keep the original code? (So that the finished library could be updated as “Spark compatible”; otherwise I can clean out all the conditional code to make it a new Spark-only lib.)
Do I need to typedef uint8_t? Does the STM32 behave more like an AVR chip and need uint8_t defined members, or use the ARMEL/PIC _port_t instead? Or neither?
Is <stdint.h> needed? It seems to fix some of the uint8_t issues but the reference doesn’t exist in the original code.
…stuff like that, mostly. I’ll try the IRC channel for help as well later today.
@Catfang, that’s why I need to review the code so I can tell you where the (SPARK) flag need to go. The application.h file includes all the definitions needed for uint8_t, etc. What is really different is the GPIO and the code around that. There will need to be a SPARK specific section with Core compatible code there. Now that I look, I realize it may be more complicated than I thought. I’ll take a shot at the port and show you what I did.
@Catfang, oh, this library is a doozy to port if you want to keep the current code. I adapted the library so it retains the fundamental code with Core adaptations so it will compile on everything including the Core. I got it compiling now I will need to test the actual port writing to make sure everything works. Once that’s done, I’ll post the code for you.
@peekay, It’s not that imperative [to me] to keep the current code, so if it’s easier to strip out the non-Spark code, that’s fine with me. I have the hardware ready to test, so as soon as you can share the updated library, I’ll give it a whirl. Thanks again for all your help! I’m looking forward to seeing what you did, so that I might be able to accomplish this in the future.
In the meantime, I’ve been playing around with a 128x160 color LCD attached to the Spark. Thanks to your port of Adafruit_ST7735, this was pretty easy to get up and running. I just need to learn the ins and outs of the mfGFX library now so that I can change the size and orientation of the text!
@Catfang, after some testing I’ve decided to rewrite some of the code to be Core specific. Stay tuned!
I had to strip out the arduino/chipkit/arm code so it would not interfere. Here is the finished library with an example. Remember to change the GPIO pins in the example to the ones you want to use. Let me know how it goes
Awesome! Thank you! I’ll be giving this a try first thing in the morning!
Hmmmm, I’m not getting any lights. Changed this single line in your code:
// ht1632c(data, wr, clk, cs, geometry, number)
ht1632c dotmatrix = ht1632c(D0, D1, D2, D3, GEOM_32x8, 3);
…to match my setup (32x8 * 3). However, I have three CS lines from my original PS/2/YOU wiring and I’m not sure how that works with your code. I tried using both the first and last pins, but neither caused any LEDs to light up. My panels are also monochrome (green), so I’m also unclear on how the color aspect is supposed to be defined.
Sorry for all the questions! I’m just trying to get text on the matrices (both static and scrolling) so any example that would get me up and running in that direction would very helpful!
@Catfang, I now realize that this is the wrong library for your display. The driver I ported is for a single display unit while you have several strung together, explaining the multiple CS lines. Can you confirm that THIS is the library you need instead?
By the way–that is a beautiful wooden case you have those displays in!
@peekay123 - I’m really sorry, that’s all my fault. I thought that was the library I needed but looks like I messed up. The library you linked to looks like what I want. I’m going to try to take a crack at porting this version myself, since I now have a nice example of how you ported the other code, and this code doesn’t look nearly as complicated. I’ll give you an update in a few days with my progress. Again, my sincerest apologies for my screw-up!
@bko - Thanks! It’s walnut with (I think) alder splines. I wasn’t a fan of the pine version when building out that kit. 
@Catfang, the tricky part will be the bitBlast() function and fWriteB macro. With the Core, you can use single bit functions or with careful GPIO pin selection, you could use port I/O. Based on my RGBMatrixPanel experience, the single bit I/O will give plenty of performance. I’ll look at the library to see what needs to be done.
Sorry for the thread necromancy! Life got in the way, and I’m finally getting back to trying to make this work (now with a Photon, rather than a Core). I can make a new thread if that’s desired, just let me know. I made an attempt to get help on the IRC channel, but I’m not sure anyone is actually present in there!
Still trying to port this: HT1632 Driver
ht1632_cmd.h - no change needed
MatrixDisplay.h - removed arduino and hardwareSerial references
MatrixDisplay.cpp - replaced fWriteA/B macros with digitalWriteFast(). Need to do something with bitBlast() though, I think. Not sure how the PORTx variables work; Particle Build is giving me “undeclared” so maybe I’m missing another library?
This is as far as I’ve gotten. Anyways, I could use a few pointers if anyone has some spare minutes!
@Catfang, I looked at the library and there is a lot that can be removed and cleaned up if the Arduino code is removed. The bitBlast() function is really a digitalWriteFast() in disguise from what I see. It was written to handle different arduino variants. Trash it! The writeDataBE is essentially a software SPI. Not sure the _nop will do much on the Photon. The rest of the files need minor cleanup for the includes. Otherwise, you should be good to go. Let me know how it goes!
Thanks @peekay123! I managed to get most of the code rewritten this afternoon, but I still have some testing to do. I’ll let you know soon how it comes out!
Sooooooo…
Still trying to get a working setup. 
According to the HT1632C Datasheet: (http://sure-electronics.net/download/DE-DP13211_Ver1.0_EN.pdf), the chips use an “SPI-like” communication prptocol. Will the hardware (or software) SPI built into the Photon work with this?
I was about to code up a sketch and try this out, but also noticed that the Photon uses mostly 3.3v logic and the HT1632C uses 5v. It seems like maybe this could be ignored since all logic and data is being sent to the HT1632C and not from it, but I don’t know the SPI stuff well enough to make that call. Do I need a level shifter to make communications work?
Finally, would I be better off doing this with my Core or my Photon? I’ve been working on this off and on for a year, and still don’t feel like I’m any closer to lighting up some LEDs.
@peekay123, can you take a look at that data sheet and let me know if hardware/software SPI can be used (rather than bit-banging) and if I need to do something to protect the Photon/Core’s 3.3v logic pins?
@Catfang, have you ported the code? I did notice some “tricky” areas so if you want me to review your code, let me know. For sure, the existing code uses a software SPI type data output so there may be an opportunity to use hardware SPI as well.
As for the 3.3V logic, you may need to try this out before using a level shifter. I believe the first thing to do is get a bit-banged version of the code running. Then we can work on hardware SPI version. 