Well it's about knowledge.
For me it would be great if there were commands which directly work with WS2812, DHT22 and a huge list of other hardware, which is not supported right now....
Well it's about knowledge.
For me it would be great if there were commands which directly work with WS2812, DHT22 and a huge list of other hardware, which is not supported right now....
lol ok, let's remove LCDOUT, OWIN, ADCIN, SEROUT and others too?
Instead of adding something useful like NEOPIXEL $ADDR,$BRIGHTNESS,$R,$G,$B![]()
all of my posted examples can do that easily, except for brightness as its a function of r g b so would be a totally useless inputadding something useful like NEOPIXEL $ADDR,$BRIGHTNESS,$R,$G,$B
http://www.picbasic.co.uk/forum/showthread.php?t=23399
http://www.picbasic.co.uk/forum/showthread.php?t=20973
a neopixel usercommand could be added with a few more lines of code to make the process more explicit
but its trivially easy as is.
very few have shown any interest in this code , very few have even asked a question.
large arrays of neopixels can be resource hungry and will need a midrange chip. a general purpose version is and will
remain a fantasy, the hardware must match the job
Warning I'm not a teacher
But arduino does neopixel with ancient chip with ease?
and also supports brightness? (it is also supported with RGB, you know?)
The libraries and our own addons are of course great, but I'm speaking about centralized support - you just type in, it just works. No forum searching and guesswork.
As far as I know (correct me if I'm wrong) Arduinos support for NeoPixels is not part of the Arduino language itself. It's an add-in library that you have to download, install and include into your code in order to use it. It's not written or maintained by "Arduino the company" but by some third party (user, company, community) and I'm pretty sure there's more than ONE version of that library to choose from as well. Which can be confusing.
The same thing goes for a lot of other stuff that "Arduino has" - it's libraries written by users and rest assured that the quality of them varies. Pretty much the same thing as "our" stuff.
The big advantage is the encapsulation that proper function calls with parameter passing, local variables and return values provides. This provides the means to "hide away" even more stuff from the user than with PBP that doesn't support function calls and/or local variables. It's not magic though.
A month or so ago I posted code for driving SK6812 RGBW LEDs. Using that particular code your exampleWould look like:Code:NEOPIXEL $ADDR,$BRIGHTNESS,$R,$G,$BAnd if you wanted you could rename the UpdateDisplay subroutine to NEOPIXEL and it would beCode:Red[ADDR]=R : Green[ADDR]=G : Blue[ADDR]=B : GOSUB UpdateDisplayNot THAT much different now, is it? Granted, the "library" IS hardcoded to run at 64MHz so you won't run a 16x16pixel array on a 12F508 - for multiple reasons.Code:Red[ADDR]=R : Green[ADDR]=G : Blue[ADDR]=B : GOSUB NEOPIXEL
You still need to include the code and set up some variables and aliases, but you don't get away from that with Arduino either.
How does these chips compare to the many flavors of PIC's?
You can't have it all. Too many chips, too many specs, and all do the same thing. Not possible. You have to compromise and select a powerful chip, stick on this no matter how much it costs and do your light or heavy job. Close to what a powerful ATMEL chip does on Arduino. From flashing a LED to NEOPIXEL or more.
Ioannis
Bookmarks