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?
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.
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
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.
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
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....
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.
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.
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?
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.
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.
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:
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:
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.
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.
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?
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.
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 ;-)
@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"
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
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
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.
Comments
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
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.
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.
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.
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....
This video should be ready in about another hour.
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.
Thanks,
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
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:
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
SETPLL byte _WORD,(@_setpll+s)>>8,@_setpll+s ' autoset crystal operation byte XCALL,xLOADMOD,XOP,pRUNMODAlso 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.
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 ;-)
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.
here just do a parallel write instead of the SPIWR
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"
seems the S6B0108 driver chip is compatible to the standard KS0108
https://lamestation.atlassian.net/wiki/display/LAME/Section+7%3A+Display
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
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.
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:
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.