Using the example:
ALIAS { {HELP \ preferred form to be compatible with Kernel source compiled through Prop Spin compiler
[COMPILE] is an immediate word and forces the next word in the text stream to compile even if it's immediate
NFA' at runtime will read in the next word in the text stream and find the Name Field Address of that word "{" if it exists, leaving the address (or zero) on the stack
GRAB forces the temporary compiled code to execute so as to "grab" any compiled parameters and put them on the stack. Because TF always compiles.
C@++ + will fetch the first byte of the Name Field which is the string length and also increment the fetch address to point to the string then add the length to the string to point to the attribute byte. NFA' { 10 DUMP
0000_6F9E: 01 7B A2 C4 0B 01 7D A2 11 0F 06 49 46 4E 44 45 .{....}....IFNDE ok
CREATEWORD reads in the next word in the text stream at runtime (which is {HELP) and creates a header for that in the dictionary
@HATR (at Header Attribute) returns with the pointer to the latest header attribute (so the new entry for {HELP)
3 CMOVE then copies 3 bytes using the source address of the "{" attribute field and the destination address for the {HELP attribute field.
So this simply replaces the new header with the attribute and code field bytes from the old header which makes the new word behave exactly like the old word.
There are times that I wish that TF didn't compile everything but it's more of an advantage that it does than a disadvantage plus it means I don't need to dedicate a TIB text input buffer for the longest line I need to read plus it compiles each word as soon as it encounters it which is faster. So I have work arounds such as GRAB for want of a better name to make all the preceding words execute although most of the time this is to grab parameters and put them onto the stack for other immediate words to use.
Yes the magic of GRAB, thanks for the explanation.
He said " Do you have any idea how many people are actively using Tachyon at this point? "
Other than a handful I have no real idea. Wouldn't this be a good opportunity to raise your hands and tell us a bit about how you are using Tachyon? It's also a good opportunity to provide some feedback with a view to making improvements too.
G-code anyone? (In one Prop with networking and FAT32)
He said " Do you have any idea how many people are actively using Tachyon at this point? "
Other than a handful I have no real idea. Wouldn't this be a good opportunity to raise your hands and tell us a bit about how you are using Tachyon? It's also a good opportunity to provide some feedback with a view to making improvements too.
G-code anyone? (In one Prop with networking and FAT32)
I use TACHYON in my projects. The more I use TACHYON the easier each project becomes because of simple code (word) reuse. There are a few people who watch me construct TACHYON on the propeller and they seem very impressed with the flexibility and rapid turnaround.
Improvements:
I would like to see F32 single COG as a PASM plugin for TACHYON which means floating number support if possible. Which also means the "loadable modules".
I would like to see the techniques used to parse G-CODE and GPS string data as "in-deep" examples of TACHYON's compiler semantics.
I would like to see TACHYON continue in steady progression so when P2 comes to the scene TACHYON is ready and I don't have to change the new tool set I've spent serious effort to learn.
But there is so much that can be done with 1 P32 and TACHYON now that I'm in no need or hurry for P2.
But there is so much that can be done with 1 P32 and TACHYON now that I'm in no need or hurry for P2.
... Amen!
I have been using Tachyon as my 'go to' Swiss Army Knife since Fall of 2013. Prototyping in Tachyon, is fast, efficient and the final and documented code looks pretty much like the code you wrote to get started. I keep one of my Prop Platform boards with an SD and lots of EEPROM space with relatively recent stable code to use for the Quick/Dirty work. This afternoon I just finished up compiling 2.4 and then applying EXTEND.fth to a Prop ASC+ board (Arduino Shield Compatible) to use debugging some Arduino drivers. Now I have to build port config file for the ASC.
I was an adopter/supporter since day #1. I haven't had a chance to use it in the latest versions. I'll wander back to Tachyon some day (soon?) I want to put it on my Pimoroni Prop Hat.
I did complete a project for Peter's contest....the one that never had a winner.
I am using TACHYON to develop a common robot control language on different robot platforms. My current project is to use TACHYON to download binary or intel hex programs to an Elf Membership Card through its parallel port. I have also ported my Analog Computer Simulator (previously written in Propforth) to TACHYON running on a FPGA Prop with dram memory.
One thing I would like to see in TACHYON is */, 64-bit multiplication followed by 32 bit division.
me too - following Tachyon since Peter first shared it - and participating in this contest ;-)
AND we are all winners
because Peter shares his Tachyon with us
and let's us withness it's evolution
so wholeheartedly
thanks Peter
p.s.: I am using Tachyon for my home automation - currently mostly 1-wire with loads (~30) temp sensors.
and eventually dynamic webserver
RE: "the dynamic web server", as peter has stated there is a probable bug in the W5500 tachyon module / Tachyon-2.4 somewhere that is messing with your dynamic syntax replacement code. Let me know how/if I can help. Do you have a IO5500 module yet?
I was an adopter/supporter since day #1. I haven't had a chance to use it in the latest versions. I'll wander back to Tachyon some day (soon?) I want to put it on my Pimoroni Prop Hat.
I did complete a project for Peter's contest....the one that never had a winner.
Oh my, the 4th/4th contest, I am so embarrassed, I do remember. For some reason I got so overloaded at the time that everytime I went to sort out the entries I couldn't seem to get them organized properly, my brain just wasn't functioning, and then I got sidetracked lots after that. Big big apologies guys, I am going spend a day and dig through all those entries and get them organized online and make sure that everyone gets a prize as well as figure out a winner.
I've started sorting the entries into one big document (at the moment) so I can make sure I have all the relevant posts included. Looks like it will be a lot of fun. Don't know what the problem was with getting this sorted out at the time. Stress can be a funny thing.
@mindrobots: That was post #34, that is really way back now as the Tachyon thread is close to 2,000 posts and not far off from a quarter of a million views, yikes!!!
.. on to more mundane stuff ... 2.4 and 1-wire ... MJB will your 1 wire code load under 2.4 yet??? I started to do it and simply didn't have the time to spend on it once I found it would load under 2.3 ... I needed to get a multi-drop project for my neighbor and 2.3 served my needs .
.. on to more mundane stuff ... 2.4 and 1-wire ... MJB will your 1 wire code load under 2.4 yet??? I started to do it and simply didn't have the time to spend on it once I found it would load under 2.3 ... I needed to get a multi-drop project for my neighbor and 2.3 served my needs .
I am using TACHYON to develop a common robot control language on different robot platforms. My current project is to use TACHYON to download binary or intel hex programs to an Elf Membership Card through its parallel port. I have also ported my Analog Computer Simulator (previously written in Propforth) to TACHYON running on a FPGA Prop with dram memory.
One thing I would like to see in TACHYON is */, 64-bit multiplication followed by 32 bit division.
NickL
+1
UM* generates a 64-bit result, I just need to change my division routine from 32-bit to 64-bit as I can't fit both in the kernel. That way */ can multiply two numbers and divide it by the third number with a 32-bit result although it will probably generate a 64-bit result internally.
if you have any problems let me know - here it works fine
The latest Explorer binary has been updated with the 1W discovery routines added. The discovery routine has been renamed ls1w in keeping with a lot of the other "ls" commands
I ran into a head-scratching bug which was resetting the system endlessly but it turned out to be a "OUTA !" rather than a "OUTA COG!" in lsio !
The BACKUP routine now runs faster thanks to a fast compare and skip feature so that most 32k eeprom backups take less than 2 seconds, a redundant backup takes 1.6secs.
UM* generates a 64-bit result, I just need to change my division routine from 32-bit to 64-bit as I can't fit both in the kernel. That way */ can multiply two numbers and divide it by the third number with a 32-bit result although it will probably generate a 64-bit result internally.
I like Sw that does the u32*32u -> u64/u32 as a Div_mod, so both the results are available from the divide. Not sure how that works-in with Forth ?
ls1w
Scanning for 1-Wire devices from P0 to P27
P11-01: DEVICE# 0000.03C3.6AB8 = 18B20 THERMOMETER
P11-02: DEVICE# 0000.03B2.CB9D = 18B20 THERMOMETER ok
@MJB: BTW, I found numerous bugs and I'm not sure how you got it running, even the 1W.DISCOVER routine was doing a I DQ! but DQ! requires a mask, not an index. I grabbed the last text file that you posted.
I wanted to add the */ operator to 2.4 but that meant that U/ and U/MOD could no longer be kernel instructions as the new UM/MOD2 for want of a better name was added to the kernel. So UM/MOD2 takes a 64-bit dividend and 32-bit divisor and generates a 32-bit remainder and a 64-bit quotient. From this U/ and U/MOD have been adapted plus the new */ operation has been added which multiples two numbers and generates a 64-bit result which is divided by the 32-bit divisor.
To multiply the clock frequency by 1.333333 ->
CLKFREQ 1.333333 1,000,000 */ . 106666640 ok
This is the main change in V2.5 at the moment and these will be carried through into V3 which uses a runtime "OBEX" library including floating point engine and serial coms as well as multiple vocabularies amongst many other enhancements. 64-bit number input and printing will be supported also.
I wanted to add the */ operator to 2.4 but that meant that U/ and U/MOD could no longer be kernel instructions as the new UM/MOD2 for want of a better name was added to the kernel. So UM/MOD2 takes a 64-bit dividend and 32-bit divisor and generates a 32-bit remainder and a 64-bit quotient. From this U/ and U/MOD have been adapted plus the new */ operation has been added which multiples two numbers and generates a 64-bit result which is divided by the 32-bit divisor.
To multiply the clock frequency by 1.333333 ->
CLKFREQ 1.333333 1,000,000 */ . 106666640 ok
This is the main change in V2.5 at the moment and these will be carried through into V3 which uses a runtime "OBEX" library including floating point engine and serial coms as well as multiple vocabularies amongst many other enhancements. 64-bit number input and printing will be supported also.
V2.5 can be found in the Dropbox.
Vocablularies! FP Engine! 64bit support!
And for those FORTH curious vocabularies can be consider as namespace in other languages.
Thanks Peter looking forward to giving 2.5 some build time on projects.
And for those FORTH curious vocabularies can be consider as namespace in other languages.
Thanks Peter looking forward to giving 2.5 some build time on projects.
Other good news too, I have now just added double number print formatting to V2.5 without disrupting 32-bit number printing. Internally the # print words have been upgraded to work on 64-bits but input is still accepted as 32-bits. By adding a <D> word which stores the high long in a register the print formatter uses this otherwise if not set it is always left as zero after printing. 1234567890 DUP UM* <D> . 1524157875019052100 ok
(My REALCALC just says "1.52415787502^18" )
So therefore it is not necessary to have a special D. word etc as we can just use the <D>. I will work out signs and stuff later.
EDIT: after a slight patch to make the double print totally transparent I can now use the fancy formatter as well. 1234567890 dup UM* <D> $400A .NUM 1,524,157,875,019,052,100 ok
ls1w
Scanning for 1-Wire devices from P0 to P27
P11-01: DEVICE# 0000.03C3.6AB8 = 18B20 THERMOMETER
P11-02: DEVICE# 0000.03B2.CB9D = 18B20 THERMOMETER ok
@MJB: BTW, I found numerous bugs and I'm not sure how you got it running, even the 1W.DISCOVER routine was doing a I DQ! but DQ! requires a mask, not an index. I grabbed the last text file that you posted.
where can I find your code to see what you changed? ---- found it - thanks
I did rund the discovery here in my setup (which was not a full test - apparently)
found all my 30 sensors and was able to read the temperatures all fine.
So apparently my test coverage has been way to small ... sorry guys :-((
but when it seems to work you stop hunting for bugs ...
If it is a professional product obviously some more rigourous testing is required !!
: lshw1w lshw --> LSHW <-- not found ????????????????
I have been back and forth over the code ... I GIVE UP .. not then faintest idea what you wanted there!
: lshw1w lshw --> LSHW <-- not found ????????????????
I have been back and forth over the code ... I GIVE UP .. not then faintest idea what you wanted there!
cheers .. BBR
Sorry Brian, that 1-wire code was setup assuming that EXTEND.fth was compiled in the EXPLORER configuration. That lshw1w was only an autorun addition to the explorer's lshw which combined all the other ls words to report on the hardware. So you can totally ignore that line but I will edit the file to conditionally compile it if it finds EXPLORER but ls1w should still work regardless.
If you want to compile EXPLORER than just do a COLD start CREATE EXPLORER and then load EXTEND.fth.
I took a look at the code and it was messed up when changes were made ages ago to the use of the cogregs. Anyway I decided that SPIOD only served a purpose to talk to the MCP3208 so why not replace it with a more specific module, which I did. Now [MCP32] looks after the chip select and also if mosi and miso (Dout/Din) are the same pins then it will release the Prop output at the appropriate time to read the chip. If you do combine the Dout and Din pin you should use a current limit resistor (I tried 4k7) so that the Prop connects directly with Din and a resistor connects across to Dout which also takes care of the 5V interfacing problem.
As for pins the long is encoded as "decimal bytes"
My test setup is:
Chip select = 16
Clock = 17
Mosi (Din) = 18
Miso (Dout) = 18
So using the & style notation for grouping decimals into bytes much like IP notation we set the pins with:
&16.18.18.17 !ADC
So that is specifying in a single long &CE.DOUT.DIN.CLK
Use the latest dropbox files or Explorer binary to try this out.
I got it running .... I directly connected both 3.3v and 5.0v to the bus Vdd (at different times) without a series limiting resistor in the data line and it made no difference and o unexpected smoke was dumped into the ether
Here's a snapshot of my "One Wire BUS" - The TO-92 with a white top just in front of the Molex connector is a One Wire serial ID chip DS 2401. The 4.7K pull up is hidden behind that connector also.
I took a look at the code and it was messed up when changes were made ages ago to the use of the cogregs. Anyway I decided that SPIOD only served a purpose to talk to the MCP3208 so why not replace it with a more specific module, which I did. Now [MCP32] looks after the chip select and also if mosi and miso (Dout/Din) are the same pins then it will release the Prop output at the appropriate time to read the chip. If you do combine the Dout and Din pin you should use a current limit resistor (I tried 4k7) so that the Prop connects directly with Din and a resistor connects across to Dout which also takes care of the 5V interfacing problem.
As for pins the long is encoded as "decimal bytes"
My test setup is:
Chip select = 16
Clock = 17
Mosi (Din) = 18
Miso (Dout) = 18
So using the & style notation for grouping decimals into bytes much like IP notation we set the pins with:
&16.18.18.17 !ADC
So that is specifying in a single long &CE.DOUT.DIN.CLK
Use the latest dropbox files or Explorer binary to try this out.
Going through and cleaning up my hard-drives is a real headache but in the process I see I need to organise my drivers for Tachyon as I forget which ones have been interfaced. Here's a quick list that I may update as I come across more but if you know of any or ones that you may have done please let me know. This is also a good time to ask if you would like to see a chip interfaced or some particular driver. Variations of existing drivers are trivial.
Eventually I will tidy up the resource links page.
My ESP8266-12 modules arrived.
Gave myself an evening with it.
And DS18B20 temperature readings are online on thingspeak.com, giving simple graphs for free.
All done in LUA - very nice.
And all with the interactive nature similar to Tachyon.
So for simple things no need for a prop any more - not even a LAN-cable required ;-)
My attention will shift a bit for the near future.
But for more complex apps which require realtime / more IOs the
ESP8266 + Prop sure will have it's applications.
Especially combining the two interactive systems LUA + Tachyon will have it's benefits.
Comments
Yes the magic of GRAB, thanks for the explanation.
He said " Do you have any idea how many people are actively using Tachyon at this point? "
Other than a handful I have no real idea. Wouldn't this be a good opportunity to raise your hands and tell us a bit about how you are using Tachyon? It's also a good opportunity to provide some feedback with a view to making improvements too.
G-code anyone? (In one Prop with networking and FAT32)
I use TACHYON in my projects. The more I use TACHYON the easier each project becomes because of simple code (word) reuse. There are a few people who watch me construct TACHYON on the propeller and they seem very impressed with the flexibility and rapid turnaround.
Improvements:
I would like to see F32 single COG as a PASM plugin for TACHYON which means floating number support if possible. Which also means the "loadable modules".
I would like to see the techniques used to parse G-CODE and GPS string data as "in-deep" examples of TACHYON's compiler semantics.
I would like to see TACHYON continue in steady progression so when P2 comes to the scene TACHYON is ready and I don't have to change the new tool set I've spent serious effort to learn.
But there is so much that can be done with 1 P32 and TACHYON now that I'm in no need or hurry for P2.
Thanks once again for TACHYON
Thanks!
Massimo
Thanks
... Amen!
I have been using Tachyon as my 'go to' Swiss Army Knife since Fall of 2013. Prototyping in Tachyon, is fast, efficient and the final and documented code looks pretty much like the code you wrote to get started. I keep one of my Prop Platform boards with an SD and lots of EEPROM space with relatively recent stable code to use for the Quick/Dirty work. This afternoon I just finished up compiling 2.4 and then applying EXTEND.fth to a Prop ASC+ board (Arduino Shield Compatible) to use debugging some Arduino drivers. Now I have to build port config file for the ASC.
cheers ... BBR
I did complete a project for Peter's contest....the one that never had a winner.
AND we are all winners
because Peter shares his Tachyon with us
and let's us withness it's evolution
so wholeheartedly
thanks Peter
p.s.: I am using Tachyon for my home automation - currently mostly 1-wire with loads (~30) temp sensors.
and eventually dynamic webserver
One thing I would like to see in TACHYON is */, 64-bit multiplication followed by 32 bit division.
NickL
RE: "the dynamic web server", as peter has stated there is a probable bug in the W5500 tachyon module / Tachyon-2.4 somewhere that is messing with your dynamic syntax replacement code. Let me know how/if I can help. Do you have a IO5500 module yet?
Oh my, the 4th/4th contest, I am so embarrassed, I do remember. For some reason I got so overloaded at the time that everytime I went to sort out the entries I couldn't seem to get them organized properly, my brain just wasn't functioning, and then I got sidetracked lots after that. Big big apologies guys, I am going spend a day and dig through all those entries and get them organized online and make sure that everyone gets a prize as well as figure out a winner.
I've started sorting the entries into one big document (at the moment) so I can make sure I have all the relevant posts included. Looks like it will be a lot of fun. Don't know what the problem was with getting this sorted out at the time. Stress can be a funny thing.
@mindrobots: That was post #34, that is really way back now as the Tachyon thread is close to 2,000 posts and not far off from a quarter of a million views, yikes!!!
Cheers,
Peter
cheers ... BBR
'
Hi Brian,
yes runs on 2.4
and I posted the EXPLORER version as well, that does autodiscovery of 1-wire on all pins
which have a pull-up and so could be 1-wire.
I am not sure if Peter included it into the EXPLORER image on his site.
I think I posted an extended EXPLORER image a while ago.
http://forums.parallax.com/showthread.php/141061-TACHYON-O-S-Fast-Forthwrite-n-Furiously-Interactive-n-Compact-FAT32-Networking?p=1316539#post1316539
1-Wire code for Tachyon
http://forums.parallax.com/showthrea...=1#post1311827
Thanks MJB but the last URL pointing to 1-wire code gets a '404' ..... BBR
meanwhile back at the ranch, I got the 1-wire code from the resources page to load with one error and then fixed .... but its not working yet.
And an explorer image with 1-wire auto discovery EXPLORER-1W.eeprom
if you have any problems let me know - here it works fine
+1
UM* generates a 64-bit result, I just need to change my division routine from 32-bit to 64-bit as I can't fit both in the kernel. That way */ can multiply two numbers and divide it by the third number with a 32-bit result although it will probably generate a 64-bit result internally.
The latest Explorer binary has been updated with the 1W discovery routines added. The discovery routine has been renamed ls1w in keeping with a lot of the other "ls" commands
I ran into a head-scratching bug which was resetting the system endlessly but it turned out to be a "OUTA !" rather than a "OUTA COG!" in lsio !
The BACKUP routine now runs faster thanks to a fast compare and skip feature so that most 32k eeprom backups take less than 2 seconds, a redundant backup takes 1.6secs.
I like Sw that does the u32*32u -> u64/u32 as a Div_mod, so both the results are available from the divide. Not sure how that works-in with Forth ?
ls1w
Scanning for 1-Wire devices from P0 to P27
P11-01: DEVICE# 0000.03C3.6AB8 = 18B20 THERMOMETER
P11-02: DEVICE# 0000.03B2.CB9D = 18B20 THERMOMETER ok
@MJB: BTW, I found numerous bugs and I'm not sure how you got it running, even the 1W.DISCOVER routine was doing a I DQ! but DQ! requires a mask, not an index. I grabbed the last text file that you posted.
To multiply the clock frequency by 1.333333 ->
CLKFREQ 1.333333 1,000,000 */ . 106666640 ok
This is the main change in V2.5 at the moment and these will be carried through into V3 which uses a runtime "OBEX" library including floating point engine and serial coms as well as multiple vocabularies amongst many other enhancements. 64-bit number input and printing will be supported also.
V2.5 can be found in the Dropbox.
Vocablularies! FP Engine! 64bit support!
And for those FORTH curious vocabularies can be consider as namespace in other languages.
Thanks Peter looking forward to giving 2.5 some build time on projects.
Other good news too, I have now just added double number print formatting to V2.5 without disrupting 32-bit number printing. Internally the # print words have been upgraded to work on 64-bits but input is still accepted as 32-bits. By adding a <D> word which stores the high long in a register the print formatter uses this otherwise if not set it is always left as zero after printing.
1234567890 DUP UM* <D> . 1524157875019052100 ok
(My REALCALC just says "1.52415787502^18" )
So therefore it is not necessary to have a special D. word etc as we can just use the <D>. I will work out signs and stuff later.
EDIT: after a slight patch to make the double print totally transparent I can now use the fancy formatter as well.
1234567890 dup UM* <D> $400A .NUM 1,524,157,875,019,052,100 ok
I did rund the discovery here in my setup (which was not a full test - apparently)
found all my 30 sensors and was able to read the temperatures all fine.
So apparently my test coverage has been way to small ... sorry guys :-((
but when it seems to work you stop hunting for bugs ...
If it is a professional product obviously some more rigourous testing is required !!
line 461 of source line 312 in Tachyon processor
: lshw1w lshw --> LSHW <-- not found ????????????????
I have been back and forth over the code ... I GIVE UP .. not then faintest idea what you wanted there!
cheers .. BBR
Sorry Brian, that 1-wire code was setup assuming that EXTEND.fth was compiled in the EXPLORER configuration. That lshw1w was only an autorun addition to the explorer's lshw which combined all the other ls words to report on the hardware. So you can totally ignore that line but I will edit the file to conditionally compile it if it finds EXPLORER but ls1w should still work regardless.
If you want to compile EXPLORER than just do a COLD start CREATE EXPLORER and then load EXTEND.fth.
or just change it:
EDIT: Brian, you can just download the precompiled binary from the dropbox link in my sig, it includes 1-wire support.
I took a look at the code and it was messed up when changes were made ages ago to the use of the cogregs. Anyway I decided that SPIOD only served a purpose to talk to the MCP3208 so why not replace it with a more specific module, which I did. Now [MCP32] looks after the chip select and also if mosi and miso (Dout/Din) are the same pins then it will release the Prop output at the appropriate time to read the chip. If you do combine the Dout and Din pin you should use a current limit resistor (I tried 4k7) so that the Prop connects directly with Din and a resistor connects across to Dout which also takes care of the 5V interfacing problem.
As for pins the long is encoded as "decimal bytes"
My test setup is:
Chip select = 16
Clock = 17
Mosi (Din) = 18
Miso (Dout) = 18
So using the & style notation for grouping decimals into bytes much like IP notation we set the pins with:
&16.18.18.17 !ADC
So that is specifying in a single long &CE.DOUT.DIN.CLK
Use the latest dropbox files or Explorer binary to try this out.
Here's a snapshot of my "One Wire BUS" - The TO-92 with a white top just in front of the Molex connector is a One Wire serial ID chip DS 2401. The 4.7K pull up is hidden behind that connector also.
Confirmed over here, works great.
thanks
Eventually I will tidy up the resource links page.
RTC
- DS1302
- PCF8563
- DS3231
- MCP79410
- SIEKO S-35390A
ADC
- MCP3208
- MCP3221
I2C MISC
- PCF8574
- CAT9554
MOTOR
- L6470 Microstepper
SENSORS
- TMP75 - temperature
- DS18B20
- SE97 DDR Temperature & EEPROM
- DHT22 - Humidity & temperature
- MMA7660 - accelerometer
- PING
- MAX31865 RTD
- Force Sense Resistor
ETHERNET
- W5100
- W5200
- W5500
Servers - FTP, HTTP, Telnet
SDHC CARD
- Virtual memory
- FAT32
- Wave player
SPI FLASH
- 25FL127 128Mbit Flash
DISPLAY
- 20x4 Character LCD (including 16x2 etc)
- SSD2119 320x240 serial LCD with RAM
- ST9720 128x64 graphic LCD
- WS2812 RGB LED
- SAA1064 4-digit I2C LED
BUSES
- I2C
- 1-Wire
- Silabs C2
- RS-485 (MODBUS etc)
MISC
- Infra-red remote
- HP82240 IR Printer
- PS/2 keyboard
- 32-channel 7.6kHz PWM
Gave myself an evening with it.
And DS18B20 temperature readings are online on thingspeak.com, giving simple graphs for free.
All done in LUA - very nice.
And all with the interactive nature similar to Tachyon.
So for simple things no need for a prop any more - not even a LAN-cable required ;-)
My attention will shift a bit for the near future.
But for more complex apps which require realtime / more IOs the
ESP8266 + Prop sure will have it's applications.
Especially combining the two interactive systems LUA + Tachyon will have it's benefits.