Shop OBEX P1 Docs P2 Docs Learn Events
TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++ - Page 65 — Parallax Forums

TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++

16263656768109

Comments

  • D.PD.P Posts: 790
    edited 2015-05-10 11:28
    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.

    Header for the { word
    [font=courier]
                 LEN {   ATR  CODE BYTES
    0000_6F9E:   01  7B  A2   C4 0B
    [/font]
    
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-13 18:45
    idbruce asked a question I can't answer :)

    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)
  • D.PD.P Posts: 790
    edited 2015-05-14 17:46
    idbruce asked a question I can't answer :)

    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
  • max72max72 Posts: 1,155
    edited 2015-05-15 02:57
    I have very little time to use the Propeller at the moment, and all my projects are on hold, but when I can I use Tachyon.

    Thanks!
    Massimo
  • TrapperBobTrapperBob Posts: 141
    edited 2015-05-15 03:45
    I am using Tachyon in a few robotics projects

    Thanks
  • Brian RileyBrian Riley Posts: 626
    edited 2015-05-15 13:14
    D.P wrote: »
    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.

    cheers ... BBR
  • mindrobotsmindrobots Posts: 6,506
    edited 2015-05-15 13:59
    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. :D
  • MJBMJB Posts: 1,235
    edited 2015-05-15 15:15
    mindrobots wrote: »
    I did complete a project for Peter's contest....the one that never had a winner. :D
    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
  • nglordinglordi Posts: 114
    edited 2015-05-15 17:27
    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
  • D.PD.P Posts: 790
    edited 2015-05-15 17:41
    MJB wrote: »
    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?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-16 05:57
    mindrobots wrote: »
    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. :D

    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
  • Brian RileyBrian Riley Posts: 626
    edited 2015-05-16 13:41
    .. 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 .

    cheers ... BBR
    '
  • MJBMJB Posts: 1,235
    edited 2015-05-16 15:26
    .. 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 .

    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
  • Brian RileyBrian Riley Posts: 626
    edited 2015-05-16 23:04
    MJB wrote: »
    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.
  • MJBMJB Posts: 1,235
    edited 2015-05-16 23:27
    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.
    this is my latest code running on the latest Tachyon 1W-MJB-2015-02-12.fth.txt

    And an explorer image with 1-wire auto discovery EXPLORER-1W.eeprom

    if you have any problems let me know - here it works fine
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-17 20:49
    nglordi wrote: »
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-17 21:21
    MJB wrote: »
    this is my latest code running on the latest Tachyon 1W-MJB-2015-02-12.fth.txt

    And an explorer image with 1-wire auto discovery EXPLORER-1W.eeprom

    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.
  • jmgjmg Posts: 15,171
    edited 2015-05-18 11:56
    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 ?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-18 19:13
    I've updated the Explorer binary with a modified version 1W.fth as I have made some enhancements to MJB's code.

    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-19 08:56
    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.
  • D.PD.P Posts: 790
    edited 2015-05-19 12:07
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-19 22:40
    D.P wrote: »
    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
  • MJBMJB Posts: 1,235
    edited 2015-05-20 11:50
    I've updated the Explorer binary with a modified version 1W.fth as I have made some enhancements to MJB's code.

    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 !!
  • Brian RileyBrian Riley Posts: 626
    edited 2015-05-20 16:24
    1WIRE.FTH 02:39 on the 20th,

    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
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-20 18:20
    1WIRE.FTH 02:39 on the 20th,

    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:
    IFDEF EXPLORER
    : lshw1w        lshw CR ls1w CR ;
    AUTORUN lshw1w
    }
    

    EDIT: Brian, you can just download the precompiled binary from the dropbox link in my sig, it includes 1-wire support.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-21 08:43
    D.P wrote: »
    Confused by MCP1308 pinouts in Extend.fth

    The code shows &01.02.03.04

    Can anyone confirm this is clk.miso.mosi.cs ?

    I'm just not getting expected results, thanks.

    update, I found cs so so far CS.MISO.MOSI.CLK?

    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.
  • Brian RileyBrian Riley Posts: 626
    edited 2015-05-21 15:55
    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
    VER:    Propeller .:.:--TACHYON--:.:. Forth V25150520.0100
    FREQ:   80MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $58C2...74F0 for 7,214 bytes (+523)
    CODE:   $0924...41D9 for 14,517 bytes (+1,515)
    CALLS:  337 vectors free
    RAM:    5,865 bytes free
    BUILD:  FIRMWARE BUILD DATE 000101:000000
    BOOTS:  9
    BOOT:   EXTEND.boot
    POLL:
    
    MODULES LOADED:
    3BEE: 1WIRE+.fth          1-wire interface + support & diagnostics 150520:0000 PBJ,MJB
    1A40: EXTEND.fth          Primary extensions to TACHYON kernel - 150309-2100
    
    ----------------------------------------------------------------
    ls1w
    Scanning for 1-Wire devices from P0 to P27
    P05-01:  DEVICE# 0000.034D.B262  = 18B20 THERMOMETER
    P05-02:  DEVICE# 0000.034D.A27A  = 18B20 THERMOMETER
    P05-03:  DEVICE# 0000.034D.DA39  = 18B20 THERMOMETER
    P05-04:  DEVICE# 0000.034D.EF5D  = 18B20 THERMOMETER
    P05-05:  DEVICE# 0000.034D.CE23  = 18B20 THERMOMETER
    P05-06:  DEVICE# 0000.034D.E21F  = 18B20 THERMOMETER
    P05-07:  DEVICE# 0000.034D.ABBF  = 18B20 THERMOMETER
    P05-08:  DEVICE# 0000.1677.3177  = 2401 SERIAL ID
    P08-01:  DEVICE# 0000.0000.0000  = #00
    P09-01:  DEVICE# 0000.0000.0000  = #00
    P22-01:  DEVICE# 0000.0000.0000  = #00
    P24-01:  DEVICE# 0000.0000.0000  = #00
    P25-01:  DEVICE# 0000.0000.0000  = #00 ok 
    


    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.
    IMG_1303.jpg
    IMG_1303.jpg
    800 x 972 - 113K
  • D.PD.P Posts: 790
    edited 2015-05-21 19:11
    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.


    Confirmed over here, works great.
    thanks
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-05-24 23:58
    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.


    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
  • MJBMJB Posts: 1,235
    edited 2015-05-25 05:14
    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.
Sign In or Register to comment.