I’ve updated the library to include a TM1829 PIXEL_TYPE, and the a-rainbow.cpp example should work right out of the box with one change… line #10 needs to just be #include "neopixel.h". I’m reluctant to change it now temporarily because when I merge this branch into Master I will surely forget to put that back the way it works with Spark Libraries. As it stands I have to change the default TYPE back and update headers… bound to forget something… well see!
Hopefully this timing works for you! If the rainbow test works… try the different colorWipe() tests and let me know if the Red Green and Blue pixel data order is correct.
I did a fast test on the code this morning and it seems to work very smoothly!
I have to say that you are really genius. Providing this code without the hardware is a fantastic piece of work! The timing seems to be perfect.
I ran through all examples and this are the point I found out:
The folks in the other forums are right. The red channel isn’t allowed to use 255 as value as this will switch the strip into a uncontrollable mode. We should implement this in the code.
The current green channel is in this case the blue one and vice verse.
When I have time I will start adding the code to control the strip via the IPad.
I am not yet sure which one will be the best method. I was thinking to use TouchOSC or via the web app (thread) provided by you. But here I am not sure if it is possible to implement sliders as controls.
Thinking big, a third solution could be to just implement a small web server on the spark which listens for specific URL parameters and feeds back in xml the system status.
This could then be controlled by a little central web server with a nice fronted.
The advantage of this solution would be that it is nearly endless extendable by additional cores under one fronted. So you could think of adding more home automation functionality. Further ore it leaves the door open for other hardware.
Give this branch a try again, I just overhauled all of the optimization and timing for this library. Now when I make changes to each supported TYPE the timing should stay put… Also added a limit to the RED channel for TM1829 and the order should be fixed if you can verify that I would be grateful.
I like a lot now the idea of adding support to the lib for additional controllers. Also the possibility now to call the function with the controller name makes it much more readable.
Looking at the code this seems to be now easier than before. Although I still have no clue how the timings can be configured. I tried to give the assembler coding a try but wasn’t really able to get into it…
I have also tested the latest version you have posted.
The limit on the red channel seems to work smoothly now.
But the channels G & B are still swapped.
Ok try it now (just pushed to branch), should be the last thing. Let me know if anything else seems off.
It's just hard delays using NOP instructions which supposedly take up one cycle, even though the compiler seems to optimize things differently than you might expect. For the most part you can count on one NOP equaling about 27.7ns of delay (there abouts). You need a scope, and patience because you'll be compiling over and over again. Entering DFU mode is a PITA. I have spent a considerable amount of time making it better in different ways... but it's not like arduino where you just compile and download in one click. It CAN be though... I just haven't found the right way yet.
Heh, sorry about that. Seems the decision I made to optimize the code a couple pushes ago came back to bite me. I said, "If I optimize this, it will be harder to maintain if I have to change it"... Anyhoo, it should be fixed now. Fingers Crossed
now it works like a charm. Colors are correct and the limiter works fine as well.
I got the strips here at a local hard ware shop (Hagebau). They were on sale for 25€ (5m / 150LEDs / 3 per pixel).
So I had to get some boxes of them
But unfortunately it turned out that the controller which was delivered is absolute crap. It has “130 digital programs” which cause epilepsy when you run them and no option to set your own colors…
I don’t understand what manufacturers think. So I decided to build my own controler and enhance it with some functiones
Great price on those strips! Report back when you get your controller worked out. I think a web app or even the webserver idea could work fine, depending on what your exact requirements are for responsiveness and how many LEDs you are controlling.
I’m guessing it’s safe to say we’ve tested that branch as well as can be for now, I’ll merge it to master when I get a chance… thanks for testing
I think we can flag this as solved. Thanks again for this great help. Didn’t expect this level of involvement.
This mede me progress a lot now.
I have already put together some quick and dirty coding with the spark webserver lib and I am able to control the strip already via this. Still a little bumpy from a UI perspective but I think this is the easiest way forward.
To provide a little insight towards I am heading:
This is already the nearly complete HTML source for the web app, so I am device independent.
First test showed that there is indeed some time gaps from submitting the setting until the strip changes color. Also the webserver seems still not to be very stable. But I think I will come around this. As I said, this option might enable also a central server controlled lighting, because you can send URL parameters to the spark.
I have also some more ideas what still can be implemented, as of now I am just in control of the whole strip color. it would be great if there would be a possibility to load via the web interface “control files” to the spark to run a “light show”…
When I have a first stable release of the hardware and coding I will post a wrap up of everything. This might help others.
Thanks again to @BDub who supported a lot.
Going together with this I have a question on the Photon.
I understood that the Photon will use a different processor. @BDub: Will the NeoPixel Lib still work with the Photon or will it require adjustments?
That's a great question, and time will tell. Basically if the processor speed ends up bring the same as the Core, it should work out of the box. If not, it will need tweaks. I have an idea for making it work regardless of processor speed though that wouldn't be too hard to implement... something I could do on a weekend day.
