Ah yeah. I don't want to have to buy a PICKit-3 to use it. Which probably ties me to Windows.
That is why I ordered a PICKit2 too... hoping that at least one of them will work with our favourite free OSes...
...and there are DIY PIC32 programmers like Nanu-Nanu which uses an Arduino-Nano clone as hardware... ;-)
I went the PICKit way because they might have been useful in the Duinomite and RetroBSD/LiteBSD context too someday (and I did not know Nanu-Nanu then)... but that plans got stuck because I didn't get LightBSD compiled... :-(
Ah yeah. I don't want to have to buy a PICKit-3 to use it. Which probably ties me to Windows. I have enough of such useless dongles around the place.
I managed to get it to work under OS X, but haven't tried Linux. But before I did that I did buy some preprogrammed chips. If I remember correctly I was able to plug the programmed chips up to a chromebook and use a terminal webapp to program in basic. I upgraded two Sumobots to use the Micromite but then subsequently changed to ESP8266 boards for Wifi control via Roboremo.
I recently discovered the FastLED library and there's a working ESP8266 port. Don't know if anyone has done anything equivalent on the Propeller - I've only seen low-level LED drivers but not FastLED's on-the-fly brightness adjustment/dithering/correction etcetera. I wonder if anyone has incorporated FastLED with a basic? That would be a way to get the attention of some kids who aren't otherwise interested in programming. My daughter isn't interested in programming, but did show interest in a programmable lighting system for her bedroom. I wonder if Parallax could sell educational kits in this vein - these guys want to sell strips for $100, it's "programmable" - https://hohmbody.com/flickerstrip/ Maybe there could be a sort of demoscene community around such a kit. Think Pico-8 and built-in limitations.
FastLED on the Propeller? How about we do just that in an interactive language on the Prop, but let's just first give it the same name:
ALIAS LED FastLED
Then let's pass an rrggbb long value to a single LED on pin 4
$00FFFF 4 FastLED
The instant we hit that enter key the LED lights up a brilliant cyan color. But off course you can make cyan a constant too
$00FFFF == cyan
and just type
cyan 4 FastLED
Or you can just as easily pass the address of an array to light up a whole string of LEDS, the basic parameters are "array leds pin", so let's use an array called "matrix"
matrix 100 4 LEDS
There are easy ways to address LEDs in an array too.
So it is as easy as that, super fast, and interactive, plus there is no "library" to load. How "BASIC" is that
FastLED on the Propeller? How about we do just that in an interactive language on the Prop, but let's just first give it the same name:
ALIAS LED FastLED
Then let's pass an rrggbb long value to a single LED on pin 4
$00FFFF 4 FastLED
The instant we hit that enter key the LED lights up a brilliant cyan color. But off course you can make cyan a constant too
$00FFFF == cyan
and just type
cyan 4 FastLED
Or you can just as easily pass the address of an array to light up a whole string of LEDS, the basic parameters are "array leds pin", so let's use an array called "matrix"
matrix 100 4 LEDS
There are easy ways to address LEDs in an array too.
So it is as easy as that, super fast, and interactive, plus there is no "library" to load. How "BASIC" is that
It's not so trivial as you might think. For instance let's say that you've stored your RGB values in an array. While it's shifting them out to the LEDs it will do on-the-fly brightness adjustment/dithering/correction etcetera. That saves memory and hair pulling. It also addresses HSV to RGB conversion if you want to be able to work in HSV colorspace - e.g. makes it trivial to create a rainbow, or go from pastels to fully saturated colors. They don't yet support RGBW but it's being worked on. It also supports multiple serial protocols. I'm sure that the propeller could do it all, and maybe someone has already done this type of thing on the propeller. I just couldn't find it.
FastLED on the Propeller? How about we do just that in an interactive language on the Prop, but let's just first give it the same name:
ALIAS LED FastLED
Then let's pass an rrggbb long value to a single LED on pin 4
$00FFFF 4 FastLED
The instant we hit that enter key the LED lights up a brilliant cyan color. But off course you can make cyan a constant too
$00FFFF == cyan
and just type
cyan 4 FastLED
Or you can just as easily pass the address of an array to light up a whole string of LEDS, the basic parameters are "array leds pin", so let's use an array called "matrix"
matrix 100 4 LEDS
There are easy ways to address LEDs in an array too.
So it is as easy as that, super fast, and interactive, plus there is no "library" to load. How "BASIC" is that
Agreed - very nice interface I do have to disagree with the "no library to load" part though. Tachyon is nothing but a kernl and a (giant and well-written) library. So what's this look like in C++? Well.... it's not interactive unfortunately but here it goes
#include <PropWare/hmi/output/ws2812.h>
using PropWare::WS2812;
using PropWare::Pin;
int main() {
WS2812 led(Pin::P4, WS2812::RGB);
led.send(WS2812::CYAN);
unsigned int colors[100];
// Fill colors...
led.send_array(colors, 100);
return 0;
}
That looks simple enough in PropWare and also having another function for specifying the pin is normally what I do to. However I suspect that supplying the pin number as part of the parameters might make it a bit easier to use for "Basic" people, seeing this interactive language is "Tachyon Basic" with built-in "libraries"
As for handling different LED types I think that if I had to do that I would have the functions for each type but allow the generic LED/LEDS to be used by simply setting the mode say with "WS2812", "TM1809" (same thing x3), etc. Since these WS2812 type LEDs have 24-bit color I can't see a need for dithering although a global brightness variable might be nice. Trying to be a do-all library like FastLED will always end up in "why can't I do this?". So, meh,
As for fast, I guess it is as fast as it is possible to communicate to a WS2812 seeing it requires ~1.1us or so timing per bit so for 24 bits that's over 24us per LED.
Here is a terminal grab where one Prop talks to another Prop over half-duplex RS485 lines in full interactive "full-duplex" mode. First a do a quick scan of the buses for devices. After 21 CHAT (notice the $2A86 code pointer) the console is interacting with unit 21 on bus #1 and I then time how long it takes for 100 LEDs, then I release the pin so that by using MYLEDS another cog can just continually refresh in the background and all we have to do is read/write hub RAM which is even faster. A silent control ^ brings us back to the gateway Prop which is device #0
Howzat Arduino!
( 0001 $3076 ok )
( 0002 $3076 ok ) DEVICES
BUS 1 1 2 21
BUS 2
BUS 3
BUS 4
( 0003 $3076 ok ) 1 BUS 21 CHAT �
( 0003 $2A86 ok ) 300 bytes matrix
( 0004 $2A86 ok ) LAP matrix 100 22 LEDS LAP .LAP 243072 cycles at 96000000Hz or 2.532ms
( 0005 $2A86 ok ) 22 LOW
( 0006 $2A86 ok ) pub MYLEDS BEGIN matrix 100 22 LEDS AGAIN ;
( 0007 $2A92 ok ) ' MYLEDS 3 RUN
( 0008 $2A92 ok ) matrix 300 ERASE
( 0009 $2A92 ok ) 0 matrix 300 CMOVE
( 0010 $2A92 ok ) .PPCFG #21 @230,769 TR/TE=14/15
( 0011 $2A92 ok )
( 0004 $3076 ok ) .PPCFG #0 @1,000,000 TR/TE=-1/-1
( 0005 $3076 ok )
( 0004 $2A86 ok ) LAP matrix 100 22 LEDS LAP .LAP 243072 cycles at 96000000Hz or 2.532ms
I can read the code up until the ".LAP" part of this line. Is the rest just a comment?
Edit: Never mind. I see it is just the output of the ".LAP" word.
( 0010 $2A92 ok ) .PPCFG #21 @230,769 TR/TE=14/15
( 0011 $2A92 ok )
( 0004 $3076 ok ) .PPCFG #0 @1,000,000 TR/TE=-1/-1
( 0005 $3076 ok )
I don't understand these lines at all. What do they do?
Edit: I'm now seeing a pattern. Words that begin with "." print something. Therefore, I assume that ".PPCFG" prints some sort of configuration and the text that follows on each line is its output. I guess you're showing the configuration on both sides of the Propeller-to-Propeller communications link? So, I guess the lines that contain "$2A92" are printed by one Propeller and the ones that contain "$3076" are printed by the other Propeller? So I think my main problem is that I couldn't find ".PPCFG" in your Tachyon glossary.
The ping-pong networking has been a more recent addition and there are a lot of words that haven't been added to the glossary yet, including those words. It's a pity that the forum code tag doesn't allow for other embedded tag attributes in which case it would be easy to highlight the user input vs machine output. V4 does away with the "ok" prompt after a line entry and instead maintains a status prompt enclosed in brackets as line number, code pointer, prompt. The brackets are to allow terminal copy and paste as they appear as a passive comment when pasted back.
I need to expand the status prompt so I can tell which unit I'm actually talking to so I may include unit number in there as well if it has been set. PPCFG is the ping-pong config control word and .PPCFG simply prints this config as you have guessed.
When I get around to it I will demonstrate communicating over Telnet to a Prop running EASYNET acting as the gateway to 40 Props and be able to interact with anyone of them as if they were connected directly to a local USB serial port. Debugging and developing remotely on a cluster of Props is a breeze. Global and group addresses also allows software to be uploaded to multiple Props in parallel or simply to execute the same script at the same time etc.
V4 "Tachyon Basic" still has some more polishing to do but I aim to include a lot of the PBASIC functions and build on that part of it too.
The ping-pong networking has been a more recent addition and there are a lot of words that haven't been added to the glossary yet, including those words. It's a pity that the forum code tag doesn't allow for other embedded tag attributes in which case it would be easy to highlight the user input vs machine output. V4 does away with the "ok" prompt after a line entry and instead maintains a status prompt enclosed in brackets as line number, code pointer, prompt. The brackets are to allow terminal copy and paste as they appear as a passive comment when pasted back.
I need to expand the status prompt so I can tell which unit I'm actually talking to so I may include unit number in there as well if it has been set. PPCFG is the ping-pong config control word and .PPCFG simply prints this config as you have guessed.
When I get around to it I will demonstrate communicating over Telnet to a Prop running EASYNET acting as the gateway to 40 Props and be able to interact with anyone of them as if they were connected directly to a local USB serial port. Debugging and developing remotely on a cluster of Props is a breeze. Global and group addresses also allows software to be uploaded to multiple Props in parallel or simply to execute the same script at the same time etc.
V4 "Tachyon Basic" still has some more polishing to do but I aim to include a lot of the PBASIC functions and build on that part of it too.
Thanks for the explanation. One of these days I'll dust off my TetraProp module designed by jazzed and try running Tachyon on all four Propellers!
Since these WS2812 type LEDs have 24-bit color I can't see a need for dithering although a global brightness variable might be nice. Trying to be a do-all library like FastLED will always end up in "why can't I do this?". So, meh,
I couldn't find a nice direct reference to their gamma correction.
As far as sRGB versus a particular strip, you would have to look at the data sheet for your LEDs.
But anyways thinking about Basic and this type of thing makes me wonder if there's a potential educational product related to it. There are a lot of robot kits with detailed instruction but I haven't seen much for lighting. Imagine this product but driven by demo scene style programs - https://hohmbody.com/flickerstrip/ (or the kickstarter https://www.kickstarter.com/projects/hohmbody/flickerstrip-create-your-own-personal-light-show/posts/1636858 - didn't get a ton of funding, would an educational element have helped?) I guess you could program it indirectly by generating an image, then importing it. Maybe it's a bad idea in general? My sister is about to sponsor a Girls Who Code club, so I'll see what she thinks.
WOW! (disregard the previous wow I have no idea how it got sent)
I am awed and humbled by the responses I have gotten.
Some of the stuff I had already looked at but a lot has popped up that I was not aware of.
I see that my lack of clarity about what I am doing is still giving some cause to point to my multiple BS2s and proclaim that one Prop could do it all. Cutting a Prop into 4 pieces and putting a piece in each of the distinct units that are connected via RF only is something I doubt would work.
I may have over reacted a bit about the BS2 OEM modules being discontinued. It is true that all good things(specially the ones I like) do come to and end. Since the BS2 chip is still available I will just have to build everything else that made the OEM modules so perfect for my situation. The big plus for building my own modules is that I do not have to learn another version of BASIC.
The circuits and programming for a 4 unit system are now complete. All that is needed now is for my partner the mechanical half of this project to complete 2 more units and refine the packaging a bit. All that will be needed then is finding a suitable venue for our world premier.
WOW! (disregard the previous wow I have no idea how it got sent)
I am awed and humbled by the responses I have gotten.
Some of the stuff I had already looked at but a lot has popped up that I was not aware of.
I see that my lack of clarity about what I am doing is still giving some cause to point to my multiple BS2s and proclaim that one Prop could do it all. Cutting a Prop into 4 pieces and putting a piece in each of the distinct units that are connected via RF only is something I doubt would work.
I may have over reacted a bit about the BS2 OEM modules being discontinued. It is true that all good things(specially the ones I like) do come to and end. Since the BS2 chip is still available I will just have to build everything else that made the OEM modules so perfect for my situation. The big plus for building my own modules is that I do not have to learn another version of BASIC.
The circuits and programming for a 4 unit system are now complete. All that is needed now is for my partner the mechanical half of this project to complete 2 more units and refine the packaging a bit. All that will be needed then is finding a suitable venue for our world premier.
A very big Thank You to all,
trooks
Okay, I think I understand now. You might still find that putting a Propeller on each of your four modules would give you more flexibility than using a BS2. It's really too bad that Parallax never came up with a pbasic+ for the Propeller that was backward compatible with the BS2. Of course, you'd still have to contend with 3.3v vs 5v.
What does it take to kill this scourge called BASIC?
Which I was first exposed to in 1973!
Something better....which is proving to be quite elusive ;-)
I'm terribly late coming to this conversation. Reluctantly I've got to agree with Mickster.
Just today I had to call up DOSBOX and run GWBASIC inside it. Sure, I'd rather be using C syntax and operators. But how do I call up a window, write a modest iterative numerical analysis routine, and get results, all in under a minute?
The odd thing is, the only other ways I know to do this is by performing the actual math on a Propeller, Arduino, or ARM Cortex board. In such instances, the PC is functioning as only as a cross compiler and serial terminal device. And only one of these three options (PropTerm) has a small footprint.
It all seems quite ironic.
If I didn't need iterative capabilities and user interaction, perhaps Octave would do the job.
Maybe it is nothing like C syntax but not only is Tachyon fast and compact, it is also interactive and so allows iterative development and testing. Take a simple Fibonacci routine, here is a one line definition that adds a new function to the language dictionary and then another one line script to run some tests on it.
( 0033 $3144 ok ) pub fibo ( n -- f ) 0 1 ROT FOR BOUNDS NEXT DROP ;
( 0034 $3154 ok )
( 0035 $3154 ok )
( 0036 $3154 ok ) 47 6 DO CR ." fibo(" I . ." ) = " I LAP fibo LAP ." result =" . 3 SPACES .LAP 10 +LOOP
fibo(6) = result =8 1136 cycles at 80000000Hz or 14.200us
fibo(16) = result =987 1936 cycles at 80000000Hz or 24.200us
fibo(26) = result =121393 2736 cycles at 80000000Hz or 34.200us
fibo(36) = result =14930352 3536 cycles at 80000000Hz or 44.200us
fibo(46) = result =1836311903 4336 cycles at 80000000Hz or 54.200us
( 0037 $3154 ok )
The script may look complex but of course we can just get a result by passing a parameter to fibo and printing out the result:
( 0039 $3154 ok ) 46 fibo PRINT 1836311903
But besides integer operators I even have F32 floating-point as a "ROM" ready to be loaded into a cog, I just haven't interfaced this one fully yet but when I do it will probably be ready to go on startup, although I just really don't have a use for it myself.
BTW, I am just using a simple terminal to communicate to a Prop.
EDIT: That was terrible formatting on that script, here's a better one:
( 1485 $2BD0 ok ) 47 6 DO CR ." fibo(" I . ." ) " 12 XTAB ." = " I LAP fibo LAP PRINT 30 XTAB .LAP 10 +LOOP
fibo(6) = 8 1136 cycles at 96000000Hz or 11.833us
fibo(16) = 987 1936 cycles at 96000000Hz or 20.166us
fibo(26) = 121393 2736 cycles at 96000000Hz or 28.500us
fibo(36) = 14930352 3536 cycles at 96000000Hz or 36.833us
fibo(46) = 1836311903 4336 cycles at 96000000Hz or 45.166us
In some respects Forth would be perfect: The interactivity, the self-hosting, the instant on, the quick turn-around.
Biggest concern is no floating point. I'm using bisection to find approximate values to the roots of non-linear equations as part of my circuit design efforts (calculating coefficients, component values, etc).
Given time, most coding can be done with fixed point. But these are just quick-and-dirty design aids I'm creating ad hoc. Hence the dependency on floating point.
There are lonesock's FP routines, but how does one integrate them with the TF language? Maybe there is an answer. I'm not a Forth expert, just a sometimes Forth practitioner.
As mentioned in my last post I have a suite of ROMS sitting in upper EEPROM which are in fact binary images that can be loaded into cogs, one of them being F32 floating point. When I get around to it I will interface this fully and the interface will blend in with Tachyon since I simply extend the language to recognize floating point numbers such as 3.06796153E-04 and anything in that format etc.
ROMS are loaded by name (fixed 8 character) so F32 for instance is loaded this way:
f32cmd 3 " F32 " LOADCOG
But once F32 is fully interfaced this cog would be automatically loaded at boot time anyway and all the functions are suitably named.
This is some test code I was playing with at the time:
1 longs f32cmd ( f32 parameter block - force alignment using longs )
long result
long fnumA
long fnumB
f32cmd 3 " F32 " LOADCOG ( start up F32 )
: FCMD ( n1 n2 cmd -- result ) result ! fnumB ! fnumA ! result f32cmd ! BEGIN f32cmd @ 0= UNTIL result @ ;
: >F ( n1 -- result ) 0 $5CFC8E42 FCMD ;
: F> ( n1 -- result ) 1 $5CFCBE48 FCMD ;
: F+ ( n1 n2 -- result ) $5CFC3C0D FCMD ;
: F- ( n1 n2 -- result ) $5CFC3C0C FCMD ;
: F* ( n1 n2 -- result ) $5CFC641F FCMD ;
: F/ ( n1 n2 -- result ) $5CFC6233 FCMD ;
: FSIN ( n1 -- result ) 0 $5CFD72A2 FCMD ;
: FSQRT ( n1 -- result ) 0 $5CFD006C FCMD ;
Checking this quickly:
( 0018 $327C ok ) 2 >F FSQRT 1000000 >F F* F> .
1414214
( 0019 $327C ok )
The "( linenum codeptr stat )" prompts are user input and V4 always displays the result on the next line.
I need to spend a day or two finishing off the interface and testing though.
@KeithE: Python on the Pi is a great idea. I just have to figure out how to keep the Pi instantly available without taking up a lot of desk space. The RPi may be small, but the cables, keyboard, monitor, and hub are always in the way of other work.
@Peter: What you're working on is captivating. I'm persuaded to investigate it further. It would be great to have full mastery of a versatile platform like that.
@Peter: What you're working on is captivating. I'm persuaded to investigate it further. It would be great to have full mastery of a versatile platform like that.
I can make a binary available once I'm done with some current upgrades. I'm busy extending the ping-pong RS485 networking to handle background firmware loading and saving that will allow the master in the network to upload firmware at boot time individually or globally or by group. These extra commands also handle cog stop and inits etc.
Even if I don't get the F32 interface completed I may include what I have for F32 as well as make it load automatically at boot and roll all of that into the binary. Thinking about it the ROMS are in upper EEPROM so that won't be much good if you try to use the Prop bootloader as it only handles 32k. Probably better to F11 the kernel and setup your terminal and copy and paste EXTEND.fth as I will include the F32 interface into that. The pasted file takes a few seconds to compile and backup after which you are ready to go. I will do a short video of this build procedure using a desktop recorder.
EDIT: added what I had for F32 into EXTEND and made it load F32 at boot time. My quick test of this is at line #1 ( 0001 ..... )
@KeithE: Python on the Pi is a great idea. I just have to figure out how to keep the Pi instantly available without taking up a lot of desk space. The RPi may be small, but the cables, keyboard, monitor, and hub are always in the way of other work.......
I am having the same space problem and may have found a solution. I picked up a small flat screen TV recently and decided to see if I could use it as a propeller/electronics development station using a Pi3.
Currently I am testing out the idea using an old Odroid sbc until I get the Pi. Here is what I have so far:
Odroid, Propeller project board, and 5V ps mounted on the back of the TV.
Serial connection between the Odroid and Prop.
Odroid video (720P) to TV HDMI input1.
VGA out from Prop to VGA input on TV
Wireless keyboard/touchpad to Odroid via USB
That got rid of a lot of clutter. Started this a couple of weeks ago, and so far I have only had time to test the serial comms and video out from both units. Had the Odroid receiving data from the keyboard/touchpad and passing it on to the Propeller. Very encouraging so far. Once I pick up a Pi3 I should be able to download programs to the Propeller and then communicate with it over pins 30/31. That opens up a whole range of possibilities, including built in test equipment like an oscilloscope, logic analyzer, voltage current and frequency measurement, etc.
@KeithE: Python on the Pi is a great idea. I just have to figure out how to keep the Pi instantly available without taking up a lot of desk space. The RPi may be small, but the cables, keyboard, monitor, and hub are always in the way of other work.
You can ssh -Y into the Pi and use X, or use VNC. And there's scp or others for moving files around.
WOW! (disregard the previous wow I have no idea how it got sent)
.
.
Okay, I think I understand now. You might still find that putting a Propeller on each of your four modules would give you more flexibility than using a BS2. It's really too bad that Parallax never came up with a pbasic+ for the Propeller that was backward compatible with the BS2. Of course, you'd still have to contend with 3.3v vs 5v.
At present my only 3.3V to 5V consideration is for the XBee units and Parallax has an adapter that solves that for me.
I suppose that out in the rest of the world the closest thing to what I am would be CNC programming. I am programming machines that monitor specific things and do specific things at specific times. They are all stand-alone units with one of them acting as coordinator. They only communicate with one another and once they are packaged there is no way to modify what I programmed them to do. This has to be so that externally there is no way to take over the systems. Once assembled there are no external connections that can change anything internal to the units.
One thing I am considering for a future project is a fleet of patrol robots. I may have to go to a different micro controller for the base station but only as a way of having more memory available for my BASIC language programming. It will still be a closed system to anything external to the programming I give it.
Comments
...and there are DIY PIC32 programmers like Nanu-Nanu which uses an Arduino-Nano clone as hardware... ;-)
I went the PICKit way because they might have been useful in the Duinomite and RetroBSD/LiteBSD context too someday (and I did not know Nanu-Nanu then)... but that plans got stuck because I didn't get LightBSD compiled... :-(
;-)
This probably will be less trouble... >:-)
I managed to get it to work under OS X, but haven't tried Linux. But before I did that I did buy some preprogrammed chips. If I remember correctly I was able to plug the programmed chips up to a chromebook and use a terminal webapp to program in basic. I upgraded two Sumobots to use the Micromite but then subsequently changed to ESP8266 boards for Wifi control via Roboremo.
I recently discovered the FastLED library and there's a working ESP8266 port. Don't know if anyone has done anything equivalent on the Propeller - I've only seen low-level LED drivers but not FastLED's on-the-fly brightness adjustment/dithering/correction etcetera. I wonder if anyone has incorporated FastLED with a basic? That would be a way to get the attention of some kids who aren't otherwise interested in programming. My daughter isn't interested in programming, but did show interest in a programmable lighting system for her bedroom. I wonder if Parallax could sell educational kits in this vein - these guys want to sell strips for $100, it's "programmable" - https://hohmbody.com/flickerstrip/ Maybe there could be a sort of demoscene community around such a kit. Think Pico-8 and built-in limitations.
Sounds like something a Propeller could do with both hands behind it's back and it's feet encased in concrete.
Then let's pass an rrggbb long value to a single LED on pin 4 The instant we hit that enter key the LED lights up a brilliant cyan color. But off course you can make cyan a constant too and just type
Or you can just as easily pass the address of an array to light up a whole string of LEDS, the basic parameters are "array leds pin", so let's use an array called "matrix"
There are easy ways to address LEDs in an array too.
So it is as easy as that, super fast, and interactive, plus there is no "library" to load. How "BASIC" is that
It's not so trivial as you might think. For instance let's say that you've stored your RGB values in an array. While it's shifting them out to the LEDs it will do on-the-fly brightness adjustment/dithering/correction etcetera. That saves memory and hair pulling. It also addresses HSV to RGB conversion if you want to be able to work in HSV colorspace - e.g. makes it trivial to create a rainbow, or go from pastels to fully saturated colors. They don't yet support RGBW but it's being worked on. It also supports multiple serial protocols. I'm sure that the propeller could do it all, and maybe someone has already done this type of thing on the propeller. I just couldn't find it.
Agreed - very nice interface
#include <PropWare/hmi/output/ws2812.h> using PropWare::WS2812; using PropWare::Pin; int main() { WS2812 led(Pin::P4, WS2812::RGB); led.send(WS2812::CYAN); unsigned int colors[100]; // Fill colors... led.send_array(colors, 100); return 0; }As for handling different LED types I think that if I had to do that I would have the functions for each type but allow the generic LED/LEDS to be used by simply setting the mode say with "WS2812", "TM1809" (same thing x3), etc. Since these WS2812 type LEDs have 24-bit color I can't see a need for dithering although a global brightness variable might be nice. Trying to be a do-all library like FastLED will always end up in "why can't I do this?". So, meh,
As for fast, I guess it is as fast as it is possible to communicate to a WS2812 seeing it requires ~1.1us or so timing per bit so for 24 bits that's over 24us per LED.
Here is a terminal grab where one Prop talks to another Prop over half-duplex RS485 lines in full interactive "full-duplex" mode. First a do a quick scan of the buses for devices. After 21 CHAT (notice the $2A86 code pointer) the console is interacting with unit 21 on bus #1 and I then time how long it takes for 100 LEDs, then I release the pin so that by using MYLEDS another cog can just continually refresh in the background and all we have to do is read/write hub RAM which is even faster. A silent control ^ brings us back to the gateway Prop which is device #0
Howzat Arduino!
Edit: Never mind. I see it is just the output of the ".LAP" word. I don't understand these lines at all. What do they do?
Edit: I'm now seeing a pattern. Words that begin with "." print something. Therefore, I assume that ".PPCFG" prints some sort of configuration and the text that follows on each line is its output. I guess you're showing the configuration on both sides of the Propeller-to-Propeller communications link? So, I guess the lines that contain "$2A92" are printed by one Propeller and the ones that contain "$3076" are printed by the other Propeller? So I think my main problem is that I couldn't find ".PPCFG" in your Tachyon glossary.
I need to expand the status prompt so I can tell which unit I'm actually talking to so I may include unit number in there as well if it has been set. PPCFG is the ping-pong config control word and .PPCFG simply prints this config as you have guessed.
When I get around to it I will demonstrate communicating over Telnet to a Prop running EASYNET acting as the gateway to 40 Props and be able to interact with anyone of them as if they were connected directly to a local USB serial port. Debugging and developing remotely on a cluster of Props is a breeze. Global and group addresses also allows software to be uploaded to multiple Props in parallel or simply to execute the same script at the same time etc.
V4 "Tachyon Basic"
You can read about the intent here:
https://github.com/FastLED/FastLED/wiki/FastLED-Temporal-Dithering
https://github.com/FastLED/FastLED/wiki/FastLED-Color-Correction
I couldn't find a nice direct reference to their gamma correction.
As far as sRGB versus a particular strip, you would have to look at the data sheet for your LEDs.
But anyways thinking about Basic and this type of thing makes me wonder if there's a potential educational product related to it. There are a lot of robot kits with detailed instruction but I haven't seen much for lighting. Imagine this product but driven by demo scene style programs - https://hohmbody.com/flickerstrip/ (or the kickstarter https://www.kickstarter.com/projects/hohmbody/flickerstrip-create-your-own-personal-light-show/posts/1636858 - didn't get a ton of funding, would an educational element have helped?) I guess you could program it indirectly by generating an image, then importing it. Maybe it's a bad idea in general? My sister is about to sponsor a Girls Who Code club, so I'll see what she thinks.
I am awed and humbled by the responses I have gotten.
Some of the stuff I had already looked at but a lot has popped up that I was not aware of.
I see that my lack of clarity about what I am doing is still giving some cause to point to my multiple BS2s and proclaim that one Prop could do it all. Cutting a Prop into 4 pieces and putting a piece in each of the distinct units that are connected via RF only is something I doubt would work.
I may have over reacted a bit about the BS2 OEM modules being discontinued. It is true that all good things(specially the ones I like) do come to and end. Since the BS2 chip is still available I will just have to build everything else that made the OEM modules so perfect for my situation. The big plus for building my own modules is that I do not have to learn another version of BASIC.
The circuits and programming for a 4 unit system are now complete. All that is needed now is for my partner the mechanical half of this project to complete 2 more units and refine the packaging a bit. All that will be needed then is finding a suitable venue for our world premier.
A very big Thank You to all,
trooks
I'm terribly late coming to this conversation. Reluctantly I've got to agree with Mickster.
Just today I had to call up DOSBOX and run GWBASIC inside it. Sure, I'd rather be using C syntax and operators. But how do I call up a window, write a modest iterative numerical analysis routine, and get results, all in under a minute?
The odd thing is, the only other ways I know to do this is by performing the actual math on a Propeller, Arduino, or ARM Cortex board. In such instances, the PC is functioning as only as a cross compiler and serial terminal device. And only one of these three options (PropTerm) has a small footprint.
It all seems quite ironic.
If I didn't need iterative capabilities and user interaction, perhaps Octave would do the job.
( 0033 $3144 ok ) pub fibo ( n -- f ) 0 1 ROT FOR BOUNDS NEXT DROP ; ( 0034 $3154 ok ) ( 0035 $3154 ok ) ( 0036 $3154 ok ) 47 6 DO CR ." fibo(" I . ." ) = " I LAP fibo LAP ." result =" . 3 SPACES .LAP 10 +LOOP fibo(6) = result =8 1136 cycles at 80000000Hz or 14.200us fibo(16) = result =987 1936 cycles at 80000000Hz or 24.200us fibo(26) = result =121393 2736 cycles at 80000000Hz or 34.200us fibo(36) = result =14930352 3536 cycles at 80000000Hz or 44.200us fibo(46) = result =1836311903 4336 cycles at 80000000Hz or 54.200us ( 0037 $3154 ok )The script may look complex but of course we can just get a result by passing a parameter to fibo and printing out the result:
But besides integer operators I even have F32 floating-point as a "ROM" ready to be loaded into a cog, I just haven't interfaced this one fully yet but when I do it will probably be ready to go on startup, although I just really don't have a use for it myself.
BTW, I am just using a simple terminal to communicate to a Prop.
EDIT: That was terrible formatting on that script, here's a better one:
( 1485 $2BD0 ok ) 47 6 DO CR ." fibo(" I . ." ) " 12 XTAB ." = " I LAP fibo LAP PRINT 30 XTAB .LAP 10 +LOOP fibo(6) = 8 1136 cycles at 96000000Hz or 11.833us fibo(16) = 987 1936 cycles at 96000000Hz or 20.166us fibo(26) = 121393 2736 cycles at 96000000Hz or 28.500us fibo(36) = 14930352 3536 cycles at 96000000Hz or 36.833us fibo(46) = 1836311903 4336 cycles at 96000000Hz or 45.166usIn some respects Forth would be perfect: The interactivity, the self-hosting, the instant on, the quick turn-around.
Biggest concern is no floating point. I'm using bisection to find approximate values to the roots of non-linear equations as part of my circuit design efforts (calculating coefficients, component values, etc).
Given time, most coding can be done with fixed point. But these are just quick-and-dirty design aids I'm creating ad hoc. Hence the dependency on floating point.
There are lonesock's FP routines, but how does one integrate them with the TF language? Maybe there is an answer. I'm not a Forth expert, just a sometimes Forth practitioner.
Or perhaps R?
If you have a Raspberry Pi, then all of this is easy to setup there.
ROMS are loaded by name (fixed 8 character) so F32 for instance is loaded this way: But once F32 is fully interfaced this cog would be automatically loaded at boot time anyway and all the functions are suitably named.
This is some test code I was playing with at the time:
Checking this quickly: The "( linenum codeptr stat )" prompts are user input and V4 always displays the result on the next line.
I need to spend a day or two finishing off the interface and testing though.
@Peter: What you're working on is captivating. I'm persuaded to investigate it further. It would be great to have full mastery of a versatile platform like that.
I can make a binary available once I'm done with some current upgrades. I'm busy extending the ping-pong RS485 networking to handle background firmware loading and saving that will allow the master in the network to upload firmware at boot time individually or globally or by group. These extra commands also handle cog stop and inits etc.
Even if I don't get the F32 interface completed I may include what I have for F32 as well as make it load automatically at boot and roll all of that into the binary. Thinking about it the ROMS are in upper EEPROM so that won't be much good if you try to use the Prop bootloader as it only handles 32k. Probably better to F11 the kernel and setup your terminal and copy and paste EXTEND.fth as I will include the F32 interface into that. The pasted file takes a few seconds to compile and backup after which you are ready to go. I will do a short video of this build procedure using a desktop recorder.
EDIT: added what I had for F32 into EXTEND and made it load F32 at boot time. My quick test of this is at line #1 ( 0001 ..... )
I am having the same space problem and may have found a solution. I picked up a small flat screen TV recently and decided to see if I could use it as a propeller/electronics development station using a Pi3.
Currently I am testing out the idea using an old Odroid sbc until I get the Pi. Here is what I have so far:
Odroid, Propeller project board, and 5V ps mounted on the back of the TV.
Serial connection between the Odroid and Prop.
Odroid video (720P) to TV HDMI input1.
VGA out from Prop to VGA input on TV
Wireless keyboard/touchpad to Odroid via USB
That got rid of a lot of clutter. Started this a couple of weeks ago, and so far I have only had time to test the serial comms and video out from both units. Had the Odroid receiving data from the keyboard/touchpad and passing it on to the Propeller. Very encouraging so far. Once I pick up a Pi3 I should be able to download programs to the Propeller and then communicate with it over pins 30/31. That opens up a whole range of possibilities, including built in test equipment like an oscilloscope, logic analyzer, voltage current and frequency measurement, etc.
You can ssh -Y into the Pi and use X, or use VNC. And there's scp or others for moving files around.
These may be of interest:
https://www.raspberrypi.org/documentation/remote-access/vnc/
https://github.com/adafruit/Adafruit-Pi-Finder
You could of course use Python on your main machine, but sometimes it's nice to have it on a machine that you don't care about messing up.