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 104 — Parallax Forums

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

1101102104106107109

Comments

  • I was looking for a datasheet as well, no joy
    V3.0 has been updated so that one of its "ROMs" handles serial a little bit better since I wanted to use it for some high speed RS485 communications....


    { HIGH SPEED UART ROM DEMONSTRATION }
    
    
    --- startup HSUART in cog 4
    
    	485pars 4 " HSUART  " LOADCOG
    
    	;
    

    Don't think I have seen this syntax used before? " HSUART " $" HSUART " no?

  • MJBMJB Posts: 1,235
    D.P wrote: »
    I was looking for a datasheet as well, no joy
    V3.0 has been updated so that one of its "ROMs" handles serial a little bit better since I wanted to use it for some high speed RS485 communications....


    { HIGH SPEED UART ROM DEMONSTRATION }
    
    
    --- startup HSUART in cog 4
    
    	485pars 4 " HSUART  " LOADCOG
    
    	;
    

    Don't think I have seen this syntax used before? " HSUART " $" HSUART " no?

    looks like just a simple string LITERAL - not a string variable.
    And it is fixed 8 chars long so 2 spaces after HSUART.

    if you check LOADCOG and FINDROM you'll see

  • The 8 character string is handled as a signature of 2 longs in EEPROM to simplify the search for the ROM.

    Remember too that the F32 ROM is sitting there and although I've tested the basics there is some interfacing to do if anyone would like to volunteer :)

    I will probably tie in floating point formats into V4 with the option of including it in V3 if it works out.
  • MJBMJB Posts: 1,235
    I will probably tie in floating point formats into V4 with the option of including it in V3 if it works out.

    why would anyone use V3 if V4 works better & faster?

    any hidden downsides in V4 ?
  • MJB wrote: »
    I will probably tie in floating point formats into V4 with the option of including it in V3 if it works out.

    why would anyone use V3 if V4 works better & faster?

    any hidden downsides in V4 ?

    V3 is tried and proven while V4 is still an experiment in progress and besides I still have changes to make to the file system which I ended up borrowing the version from P2 and so there is still some work to do when I find time to fit it in.

    As it is I am still using V3 and badly needed that serial communications as a master for five sets of RS-485 ping-pong buses, and it works very nicely too, being able to "chat" with any node as if it were attached locally plus normal runtime RS485 networking mode of course. I have one of my Pixie VGA boards hooked up to the monitor and connected back on a supervisory bus to display information from 40+ nodes just to keep an eye on things.

  • So are you saying Ping Pong is now master and client able on V3 without using a P2 as the master?

    Would love to see a demo setup on V3 if so
  • D.P wrote: »
    So are you saying Ping Pong is now master and client able on V3 without using a P2 as the master?

    Would love to see a demo setup on V3 if so

    Yes, I had to ditch the P2 as impractical at this stage and work with what just works so the P1 is now empowered in this regard. I have string of modules sitting on the bench so I will see if I can do a demonstration video.

  • MJBMJB Posts: 1,235
    D.P wrote: »
    So are you saying Ping Pong is now master and client able on V3 without using a P2 as the master?

    Would love to see a demo setup on V3 if so

    Yes, I had to ditch the P2 as impractical at this stage and work with what just works so the P1 is now empowered in this regard. I have string of modules sitting on the bench so I will see if I can do a demonstration video.
    sounds great for the networked automation of my solar, heating. venting

  • MJB wrote: »
    D.P wrote: »
    So are you saying Ping Pong is now master and client able on V3 without using a P2 as the master?

    Would love to see a demo setup on V3 if so

    Yes, I had to ditch the P2 as impractical at this stage and work with what just works so the P1 is now empowered in this regard. I have string of modules sitting on the bench so I will see if I can do a demonstration video.
    sounds great for the networked automation of my solar, heating. venting

    Yes a video please and a simple code snippet would thrill all Tachyon users. Got the new 500 gallon giant australian crayfish tank setup, it could use Ping Pong....

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-12-10 16:31
    After some effort in setting up for video recording a ping-pong network I have uploaded an introduction to the ping-pong networking on youtube. Since it is still uploading and well after 2AM I will leave it to finish but paste the link in the meantime. I'm tired so I have probably skipped a few details but it will give you an idea and perhaps if there is something you would like to see a bit more of then you could let me know while I still have it all setup. There's RS485.fth over in the extras folder if you want to see what I used.

    This video should be ready in about another hour.
    pp.png
  • What is the difference between v3.0 and v3.1 ?
  • 3.1 was only used for testing and of course I have skipped to V4 now which is still being tested although it has a functioning kernel and EXTEND section. I still use V3.0 as my stable kernel.
  • 3.1 was only used for testing and of course I have skipped to V4 now which is still being tested although it has a functioning kernel and EXTEND section. I still use V3.0 as my stable kernel.

    RE: the video. WOW, gonna get busy looking at the code after the chicken coop roof is built today. I have my wheels spinning after seeing this demo.

    Thanks for the effort Peter.



  • In V2.9 we had PPCFG to configure the Ping-Pong slave nodes, I'm struggling to find the slave configurations in V3.0. The RS485.fth file in extra is for the master only no?

    Thanks,

  • D.P wrote: »
    In V2.9 we had PPCFG to configure the Ping-Pong slave nodes, I'm struggling to find the slave configurations in V3.0. The RS485.fth file in extra is for the master only no?

    Thanks,
    The PPCFG and its components are located in EXTEND.fth (line 1603) while the RS485.fth is the example code for the MASTER which also includes some other bits and pieces.

  • MJBMJB Posts: 1,235
    Hi Peter,
    I am about to write a driver for the TM1638 LED/7-Segment driver with key scanner.
    https://aliexpress.com/wholesale?catId=0&initiative_id=&SearchText=TM1638
    It uses half-duplex SPI at ~ 1MHz.

    But the
    150522 Removed buggy SPIOD and replaced with MCP32 module for MCP3208 chips etc.
    SPIO with delay has been removed.
    MCP32 module runs at 2 MHz.

    Of course I can use SHROUT / SHRINP

    I could also patch SPIO after loading in with a few NOPs ... there is space for 21 - 15 = 6 NOPS = 2 * 3

    other options hidden somewhere?

    Also I didn't fully investigate the effect of using the same pin for IN and OUT regarding the driving collisions. OF course I could use 2 pins and connect them externally.

    happy Xmas

  • Hi Peter,

    christmas brought 3 lamestations for my boys. Now they are in bed and I'm trying to get Tachyon running. As I'm usually doing I compiled the kernel (bstc.linux) and downloaded to eeprom to get it running but something is going wrong. I only saw one time the kernel TERMINAL after a further reset it was away and i couldn't get it running again.

    I looked at the clock-settings selected the 5 Mhz crystal tried even with 6 Mhz but no success.

    Spin downloads are possible and working fine - could it be that the clock autodetection goes wrong?

    The lamestation example code does clock settings like this:
    _clkmode = xtal1 + pll16x
    _xinfreq = 5_000_000
    

    In Tachyon V3.0 JUNO.spin I did this
    '{
    _clkmode        = xtal1 + pll16x
    _xinfreq        = 5_000_000            ' lamestation
    sysfreq         = 80_000_000
    '}
    {
    _clkmode        = xtal1 + pll8x
    _xinfreq        = 10_000_000            ' <--- AUTOMATIC 5 or 10MHz operation change at boot
    sysfreq         = 80_000_000
    }
    { 6MHZ CRYSTAL
    _clkmode        = xtal1 + pll16x
    _xinfreq        = 6_000_000
    sysfreq         = 96_000_000
    }
    

    but I don't really know what could fail.

    Can you give an advice?

    Grrr it's terrible I know for sure it worked one time.

    Thanks in advance,
    proplem
  • ErNaErNa Posts: 1,738
    is 32k of eeprom sufficient?
  • The initial x8 setting works for both 5MHz and 10MHz crystals but when PhiPi's autodetection routine is called it changes the settings again anyway. So normally if you have a 5MHz or 10MHz crystal you don't need to change the settings. However if you get desperate you could comment these two lines at line 2513:
    SETPLL  byte    _WORD,(@_setpll+s)>>8,@_setpll+s                                ' autoset crystal operation
            byte    XCALL,xLOADMOD,XOP,pRUNMOD
    

    Also there isn't any problem with only having a 32kB EEPROM although it is very easy to replace that as the larger EEPROMs allows Tachyon to save precompiled ROM images when you load EXTEND the first time plus the upper EEPROM can be used to COMPACT the dictionary and free up hub RAM.

    The only thing I can think of is that the RS232 transistor circuit is fairly slow so you might even try dropping your baud rate down to 57600 or less to see if that makes a difference.
  • ErNa wrote: »
    is 32k of eeprom sufficient?
    Yes, Peter makes 64 KB of them :-)))

  • Hi all,

    I want to introduce my sons to tachyon via LameStation.

    This works so far: kernel ok, EXTEND ok, I ported the lamestation pinout,spin to FORTH but I'm not able to output anything on the LCD which is quite frustrating for the boys.

    The LameStation Software is hosted on github and so the driver for the LCD is (https://github.com/lamestation/lamestation-sdk/blob/master/library/LameLCD.spin). I thought it would be best to take that code and port it to Tachyon FORTH maybe making it usable with LOADROM (it includes assembler code).

    This is challenging for me - I didn't do Propeller assembler before and I've no experience with LOADROM.

    With this a priori knowledge porting the code will become a longterm project maybe never ending for me and frustrating for my boys. So there is one other possibility:

    Did anybody of you write a Tachyon driver for the LCD (signed with: www.buydisplay.com; ERM12864-2; EASTRISING TECHNOLOGY Pin descriptions: VSS,VDD,V0,RS,R/W, DB0-DB7,CS1,CS2,RST,VEE,BLA,BLK) and is willing to share it?

    Thanks to all,
    proplem
  • MJBMJB Posts: 1,235
    proplem wrote: »
    Hi all,

    I want to introduce my sons to tachyon via LameStation.

    This works so far: kernel ok, EXTEND ok, I ported the lamestation pinout,spin to FORTH but I'm not able to output anything on the LCD which is quite frustrating for the boys.

    The LameStation Software is hosted on github and so the driver for the LCD is (https://github.com/lamestation/lamestation-sdk/blob/master/library/LameLCD.spin). I thought it would be best to take that code and port it to Tachyon FORTH maybe making it usable with LOADROM (it includes assembler code).

    This is challenging for me - I didn't do Propeller assembler before and I've no experience with LOADROM.

    With this a priori knowledge porting the code will become a longterm project maybe never ending for me and frustrating for my boys. So there is one other possibility:

    Did anybody of you write a Tachyon driver for the LCD (signed with: www.buydisplay.com; ERM12864-2; EASTRISING TECHNOLOGY Pin descriptions: VSS,VDD,V0,RS,R/W, DB0-DB7,CS1,CS2,RST,VEE,BLA,BLK) and is willing to share it?

    Thanks to all,
    proplem

    1. I don't know LameStation - so I assume the display is connected in parallel - what a waste of Prop pins ...
    2. with Tachyon you will definitely need no PASM to control it
    3. I think Peter has a graphic LCD driver on DropBox (can check later) maybe it can adapted.
    4. if (3) will not help - don't go porting the existing driver ... take the datasheet and write your own.

    this will be a good excercise for your boys to see how easy to do complex things step by step watching you ;-)
  • MJBMJB Posts: 1,235
    @Proplem
    have a look at PEter's dropbox
    in \more\extras\ and \more\MISC MODULES\

    search for LCD ...
    most are SPI based, but the lowest layer can be replaced by a parallel driver.

    LCD9163.fth might be similar to your LCD.
    
    pub LCD! ( dat dc -- )	*DC PIN! SPIWRB DROP ;
    pub LCDDAT	1 LCD!	;
    pub LCDCMD	SPICE 0 LCD!	;
    pub LCDDAT16	*DC HIGH SPIWR16 DROP	;	\ W>B LCDDAT LCDDAT ;
    
    --- prep for data
    pub WRDATA	$2C LCDCMD *DC HIGH ;
    
    here just do a parallel write instead of the SPIWR

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-05 12:42
    @proplem - yes, as MJB said, you won't need PASM, but what a waste of pins. Then again, it is a game machine and doesn't need those pins for much else I guess.

    I had a look at the S6B0108 controller and it is just a modified form of a standard character LCD controller, except it writes pixels, not characters. Most LCDs are very easy to interface in Tachyon because you can try one little thing and build on it from there. Just write a basic routine that writes data or a command to the device, that shouldn't take more than a couple of lines of code. To give you a head start after you define the pin constants as pin numbers, try this:
    --- Output a byte of data to the LCD 
    pri LCDDAT ( ch --  )
        *rs HIGH
    pri WriteLCD ( data -- )
        $FF OUTCLR OUTSET				--- write data (set after clear)
        *lcdce HIGH *lcdce LOW			        --- pulse chip enable
        ;
    --- Output a byte to the LCD as an instruction
    pri LCDCMD ( cmd -- )
        *rs LOW WriteLCD
        ;
    

    Then after pulsing the reset just try write some data to it, perhaps like "$55 LCDDAT" etc or even a loop.
    BTW, that controller chip is a real kludge, like it has been hacked together from character controller parts. You of course need to ensure the enable lines are set correctly and you may need to issue a display on command "$3F LCDCMD"
  • MJBMJB Posts: 1,235
    edited 2017-02-05 13:36
    @Proplem
    seems the S6B0108 driver chip is compatible to the standard KS0108
    https://lamestation.atlassian.net/wiki/display/LAME/Section+7%3A+Display
    The LameStation is powered by a KS0108 LCD screen.
  • Thanks a lot. You both are so supportive that even such a hopeless challenge could be possible. I will do my very best in the spare time maybe it isnt as difficult as i think it is. Btw the datasheet is terrible.
    Good night, proplem
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-05 23:28
    proplem wrote: »
    Thanks a lot. You both are so supportive that even such a hopeless challenge could be possible. I will do my very best in the spare time maybe it isnt as difficult as i think it is. Btw the datasheet is terrible.
    Good night, proplem

    You're welcome, but if you think it is difficult when we think it is easy it is not because of any brilliance :) , it is simply our point of view, how we look at the problem which with Forth means we can interact with both the hardware and the software, reducing the problem down to tiny little chunks that also simplify things as we go. The starting point I mentioned is a good start, along with a basic reset routine that also sets up the I/O too.

    BTW, thinking about Tachyon running on the Lamestation, I think you will have a lot of interactive fun. For instance a particular part of writing a new game might be testing if a sprite has been "hit", and it is as easy as asking the routine while single-stepping at the game level. Have a look at BREAKOUT.FTH that was written to run on 32x15 text VGA or even the Game of Life which might be easier.
  • Thanks again brilly boys :-)) short in time, waf low, but not giving up. Will have a look asap. Regards, proplem
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-02-06 22:57
    proplem wrote: »
    Thanks again brilly boys :-)) short in time, waf low, but not giving up. Will have a look asap. Regards, proplem

    This is an opportunity to have same real fun. Just remember that the LCD is setup for write-only, so there are no status register reads which aren't required anyway. There are only a very small number of commands to interface with:
    • Display on/off - on of course
    • Set Y address
    • Set X page
    • Start line Z - normally leave this set to 0
    • Status read - not used - can't read anyway
    • Write data
    • Read data - not used - can't read anyway

    The Y address increments automatically but there are only 6 address bits so I guess that it writes 8 pixels for 64 lines (a narrow column).
    The X page is only 3 bits so that only gives you 8 lots of 8 pixels so I'm guessing this is a kludge and you need CS1 or CS2 to select the other half of the chip (yuck).

    Of course I could look at a driver that is already written but there is no fun in that but more seriously many times it just confuses you because there can be better ways of accessing peripherals plus some drivers seem to be a kludge of a kludge.
  • Got the RX side of this esp8266 client working, need to breadboard a module to remove the FTDI conflict from the TX side.
    2612 x 1370 - 336K
Sign In or Register to comment.