3. Apparently it is only these 20Mbit 65HVD75 chips that have the glitch but the software works with these anyway so no problem. But I do recommend that you always use full fail-safe chips as RS485 lines can be troublesome otherwise. Just please don't use the ancient 75176 bipolar chips that some places still try to sell you along with the free layer of dust.
Have you done a CAN bus Transceiver compatible version of this ?
CAN has a larger fixed offset, so has higher noise immunity in a non-driven bus, and you can get regulators + CAN drivers in one package.
It would need 2 pins as TxD, RxD, with the RxD gated during Tx if you do not echo-verify.
TJF1051 claims 5MBd and is 39c/1k.
Microchip claims 8MBd for their MCP254x, +/- 58V CAN pins rated, with a pulsed wake up option for low energy systems.
After downloading the dropbox files I struggled with compiling and writing a new kernel on a device (eval board). I was searching for a (long) while and found:
Are you touching the file with an editor that is messing the the CR LF pairs somehow since you are working with two OS's ?
I had this problem with CR LF until I set both editors on different OSs to the same.
Are you touching the file with an editor that is messing the the CR LF pairs somehow since you are working with two OS's ?
I had this problem with CR LF until I set both editors on different OSs to the same.
Hello D.P., no that was not the point. There was a problem with my eval patch cable wiring. The RESn wire didn't work. Now I can write Tachyon V2.9.spin to the device and EXTEND.fth is also pasted.
Thanks for helping!
I'm studying this post in search for serial communication help. I found some code from D.P. here but I'm not yet happy with it and I assume it has changed a lot.
I have to write some AT commands with 9600 BAUD to a HC-06 Bluetooth Board and would like to use this as an entry to learn serial communication with Tachyon.
I found also code like this in the thread
9600 SERBAUD
14 SERIAL PRINT" AT+BAUD4" CR CON 115200 SERBAUD
This seems easy enough for me but when I do this on console Tachyon dies. Maybe I kill the baudrate with my minicom terminal but how can I select a RX and TX pin, change the Baudrate communicate with the device and visualize all this on the console?
Since you have changed the console port over to SERIAL you can no longer communicate with it so the idea is that when you try something like this interactively that you get into the habit of typing CON at the end of the line. However with some words they are output only like VGA for instance so they are still listening to the terminal keyboard so if you forget you can always ttry typing CON in the hope that it responds.
I cannot seem to set the minutes with this DS3231?
I will double check but make sure you select DS3231 and to lock it in sometime with backup. This option covers most RTCs and then there is the MCP79410 and NORTC which just maintains an internal RTC after updating (as in NTP etc).
Also had this issue with 2.8 and the "matching" EXTEND.fth I will keep checking some stuff here (looks like the minutes are being assumed to be in hex and the values overflow and won't update) and run a backup after selection but I have selected the proper RTC as shown above.
I cannot seem to set the minutes with this DS3231?
I will double check but make sure you select DS3231 and to lock it in sometime with backup. This option covers most RTCs and then there is the MCP79410 and NORTC which just maintains an internal RTC after updating (as in NTP etc).
I cannot seem to set the minutes with this DS3231?
I will double check but make sure you select DS3231 and to lock it in sometime with backup. This option covers most RTCs and then there is the MCP79410 and NORTC which just maintains an internal RTC after updating (as in NTP etc).
Alright Peter what the heck is this? I think you went "full C pointer de-reference" here
pub TIME! ( #hh.mm.ss -- ) \ write time in decimal format
@rtc
IF
DUP time !
RDRTC
#100 U/MOD SWAP DEC>BCD $80 OR rtcbuf C! --- don't see the need to set MSB either?
#100 U/MOD SWAP DEC>BCD * 1+ C! --- should be #100 U/MOD SWAP DEC>BCD rtcbuf 1+ C!
DEC>BCD rtcbuf 2+ C!
WRRTC
ELSE
100 U/MOD 100 U/MOD 60 * SWAP + 60 * + 1000 * time !
THEN
;
Alright Peter what the heck is this? I think you went "full C pointer de-reference" here
What do you mean??
If NORTC is selected than the RTC I2C address @rtc = 0 which means there is no device. Now if we try to set the time for NORTC I decided that time would be time in millseconds so that #160624 (YYMMDD) would be converted to milliseconds and the time variable updated by the background task every millisecond. At least that's what I think I remember doing ...
edit: now I remember, it was such a pain checking for minutes, hours etc that I just decided that the whole time format mess would be better off representing the time of the day in milliseconds. I also despair of RTC chips that continue to represent time in BCD format with other flags mixed in with those bits depending upon the chip. What a mess! I intend to program a little PIC with a 40kHz crystal as my new universal RTC with I2C and single I/O modes. That way it stores the time of the day in milliseconds and also takes care of the dates etc. With onboard temperature sensing I could even compensate for drift.
What I mean is the * operator? It doesn't belong as noted above, BUT it was positionally correct for a dereference of a C pointer var that contained the address to write the value to. Gosh C is a mess even talking about it. Ha
Okay, you are distracting me from P2 stuff you know. I see what you are talking about, I think that was the touchpad on the laptop messing me up, I have since made sure it was off. So that should be rtcbuf of course and the $80 OR has to do with some RTC devices (DS1307) as I mentioned that this settings works with most and setting this bit for the DS3231 itself does not upset it either.
Well laundry before Zen as the saying goes. I've patched what I need, I don't what my automated pressure cooker to go boom over a "broken" clock. I'll go harass you over on the P2 thread now
Yes, that's what it was but this method used the kernel's emit routine and needed to know the baud rate and pin otherwise you could just use SEROUT with your own I/O redirection like this. The SERIAL method I put in recently when I needed to be able to talk on the RS485 much higher data rates than SEROUT could handle.
Hello there, I'm interactively trying to get more familiar with looping in Tachyon. This works:
5 BEGIN CR ." Huhu" 1- DUP 0 = UNTIL
If I copy and pasting the following lines:
5
BEGIN
CR ." Huhu"
1-
DUP
0 =
UNTIL
gives this output.:
5 ok
BEGIN ok
CR ." Huhu"
Huhu ok
1- ok
DUP ok
0 = ok
UNTIL Structure mismatch! *error*
The second version should work, shouldn't it? Kernel and EXTEND are from 20160606.
There seems a gotcha with the line breaks or even a missing surrounding word definition or whitespace, indentation or ... Ahh - missing word definition - check:
: HUHULOOP
5
BEGIN
CR ." Huhu"
1-
DUP
0 =
UNTIL
;
This works like the first version.
@Peter: Just for a better understanding - can you give a short explanation?
Thanks for your time!
@proplem - Tachyon Forth is different from most Forths and one of the differences is that instead of assembling a whole line of text in a "terminal input buffer" then interpreting and executing word by word that instead it simply compiles each word as it is encountered from the "terminal" and normally only executes the lot on a CR. So this saves room on a terminal buffer, speeds up text handling, allows you use "compile time only" words, and runs the code the same way and speed as it would if it were compiled into a definition.
That is why we can use BEGIN UNTIL DO LOOP etc interactively and we don't need special words either just to print literal strings etc.
Now, I did use the word "normally" and there are certain words that are IMMEDIATE and unless overridden will execute immediately when they are found such as IF which needs to setup a branch but there may be other words too and they may need parameters at "compile time" but these parameters are not available because they have been compiled by default. This is where the GRAB word comes in as it basically executes all the stuff that has been temporarily compiled up to that point such as parameters and in effect grabs those parameters for the use of an upcoming IMMEDIATE word. This may sound confusing but when there are times you need to change the way words are compiled and this method starts to make sense.
Now "normally" the line of compiled text executes on a CR but you can also tell it to continue and I happen to use the | symbol to indicate line continuation without executing. Thinking about this symbol I know I'd like to use the nix \ instead but that is a Forth comment word, however I guess if it is the last character on a line then it could become the line continuation instead of |. Now putting that aside we are looking at your multi-line interactive compilation. You may have noticed at first that every time you entered the line that it would execute then say ok after which you realized you needed to put that in a definition. You don't have to create a definition to do this though rarely would we need an interactive input continued beyond one line but that doesn't mean we can't which is why we could use | until we are ready.
Things to help you understand Tachyon Forth.
1) Get to know Forth (Starting Forth etc)
2) Forget that you "know" Forth, ANSI or otherwise
3) Remember the KISS principle, that we need it to be practical and to perform
4) Remember that this is the quirky and powerful Propeller chip but that we only have 32k of memory.
Now the 4th point brings us to Tachyon, the version of Forth that was created to run on the Propeller in a limited amount of memory etc. Unlike many Forths or other languages that run on PCs with gigs of resources we are using the Propeller to talk to peripherals and signals in real-time and interactively to boot, hence the choice of Tachyon. BTW, we could have more standard interactive languages but unless they are practical and perform then what is the point of using the Propeller chip itself? So Tachyon is a tool to get things done efficiently, and the reason for the tool is to create working and commercial applications with the Propeller. That statement in itself highlights a big difference with other more "standard" approaches which may look nice but what is the point if you can't get the job done. It's no good being able to run a standard benchmark, or only have enough room to compile part of the whole system or have it run too slowly or need expanded memory kludges that still run slowly, which from a practical viewpoint you may as well not use the Propeller then.
If you get your job done and have fun at the same time then these are all pluses in my book. But Tachyon is not an exercise in writing a "language", it is a means to an end when no other solution worked or works. When you can run a compiler, a debugger, a run-time library, a file-system, network servers, VGA, communications ports, and many many other uses all together in an ordinary otherwise unexpanded 32k RAM Propeller chip then you know that this solution must be good and practical and useful and worthwhile considering if you are serious about deploying the Propeller chip in real 24/7 working projects in the field.
Hey Peter get back to P2 I'll try my best to help Proplem out with basic Tachyon questions. Also any excuse to bump this thread Slow but surely, they will be assimilated.
Hey Peter get back to P2 I'll try my best to help Proplem out with basic Tachyon questions. Also any excuse to bump this thread Slow but surely, they will be assimilated.
Hey hey hey, besides Sunday socials I sometimes even respond verbosely, even didactically, Now, back to the P2, I will put the server online shortly but it will between bootloader tests though.
Here's a shot of how the board looks currently, I've still got the Puppy modules to place and RS485 as well as the ESP8266. Notice the 8-pin smd Flash and EEPROM soldered directly to the 0.1" pads, just bend up pins that aren't used and position slightly to get the right pins on the right pads.
There is no direct connection to the card because of the 4050 buffer which IMO is totally unnecessary. However if you add a pullup to the CS input of the board then Tachyon will think that there is a card inserted or perhaps you can just write a card detect method using the CD pin (with one extra I/O) and patch that vector into the ucard variable.
So much of this hardware out there is cobbled together from bits of information here and there so that when I look at the design of that breakout board it looks like they don't really know what they are doing. But from a marketing point of view you would want something more on the board than a socket so it looks better having an "interface" chip that also only costs them 17 cents If that was truly for buffering over longer lines (cough cough) then they would have buffered the card's DO pin as well surely.
To think that there is a whole new generation that are learning to program microcontrollers, and that they are using slow 8-bit chips that run at 5V too when the rest of the world has been using 3.3V and less along with far more advanced CPUs that cost about the same anyway. Should have a Battle of Parallax and give 'em Props, boys!
Hey Peter get back to P2 I'll try my best to help Proplem out with basic Tachyon questions. Also any excuse to bump this thread Slow but surely, they will be assimilated.
"Basic" questions? I'm fuddling late in the night - no in the morning - with difficult things like loops and he names it "basic" #@!^$%& ... >:(
Thank you both for your patience and guidance. Peter's answer gave me some important hints (GRAB, IMMEDIATE I already wondered about in the source).
D.P., thank you for your offering - I don't want Peter to take you away (hopefully this is correctly written ). And you are right he should invest into P2, but maybe he can relax when answering "basic" questions. Now enough fun, have to continue working...
Just post your questions and we can get to them, MJB and others are great resources as well.
It gets easier and you become more productive. Just look at the pace that Peter is filling out all the nooks and crannies in P2. He will make smart pins accessible ( to himself) and us mere mortals with simple access and setup words very similar to how he exposed the guts of the timers in P1!
One of my first tasks I'm doing when I learned a new language like now Tachyon is programming a statemachine class/module which I'm used to use. It's a kind of programming philosophy - I do/think like this - I've got a nice idea how this could be done in an elegant way in Tachyon, but there is one thing missing. So the following code is not working but will give the idea. The first lines are the independent abstract part (which you should fly over at first reading):
WORD nextstate
WORD currstate
WORD laststate
ALIAS : State
: AST ( -- ) \ Apply State Transition
currstate w@ laststate W!
nextstate W@ currstate W!
currstate W@ CALL
;
: PNS ( nextstate -- ) \ Preparte Next State
W@ nextstate W!
;
: RUN ( -- ) \ run method
' sOne currstate W! \ initially preset currstate of statemachine
' sOne nextstate W! \ initially preset currstate of statemachine
' sOne laststate W! \ initially preset currstate of statemachine
10 TIMES AST NEXT \ normally infinite loop
;
The following lines show how I would use them in a concrete case:
State sOne
CR ." One"
' sTwo PNS \ PrepareNextState
;
State sTwo
CR ." Two"
' sThree PNS \ PrepareNextState
;
State sThree
CR ." Three"
' sOne PNS \PrepareNextState
;
RUN
It it would work like I want, the output should look like:
One
Two
Three
Three
Three
Three
Three
but I'm getting the following (understandable) error
WORD nextstate ok
WORD currstate ok
WORD laststate ok
ok
ALIAS : State ok
ok
State sOne
CR ." One"
' sTwo PNS error in sOne at PNS ; *error*
If I'm right the error comes from the at compile time not yet known word definitions.
1. Am I right that this isn't possible with the current compile paradigms in Tachyon?
2. Does anybody have a better idea how I could do exactly this or maybe a bit changed and as lean as this?
One of my first tasks I'm doing when I learned a new language like now Tachyon is programming a statemachine class/module which I'm used to use. It's a kind of programming philosophy - I do/think like this - I've got a nice idea how this could be done in an elegant way in Tachyon, but there is one thing missing. So the following code is not working but will give the idea. The first lines are the independent abstract part (which you should fly over at first reading):
WORD nextstate
WORD currstate
WORD laststate
ALIAS : State
: AST ( -- ) \ Apply State Transition
currstate w@ laststate W!
nextstate W@ currstate W!
currstate W@ CALL
;
: PNS ( nextstate -- ) \ Preparte Next State
W@ nextstate W!
;
: RUN ( -- ) \ run method
' sOne currstate W! \ initially preset currstate of statemachine
' sOne nextstate W! \ initially preset currstate of statemachine
' sOne laststate W! \ initially preset currstate of statemachine
10 TIMES AST NEXT \ normally infinite loop
;
The following lines show how I would use them in a concrete case:
State sOne
CR ." One"
' sTwo PNS \ PrepareNextState
;
State sTwo
CR ." Two"
' sThree PNS \ PrepareNextState
;
State sThree
CR ." Three"
' sOne PNS \PrepareNextState
;
RUN
It it would work like I want, the output should look like:
One
Two
Three
Three
Three
Three
Three
but I'm getting the following (understandable) error
WORD nextstate ok
WORD currstate ok
WORD laststate ok
ok
ALIAS : State ok
ok
State sOne
CR ." One"
' sTwo PNS error in sOne at PNS ; *error*
If I'm right the error comes from the at compile time not yet known word definitions.
1. Am I right that this isn't possible with the current compile paradigms in Tachyon?
2. Does anybody have a better idea how I could do exactly this or maybe a bit changed and as lean as this?
I prefer table driven state machines. (untested code !! - to give the idea)
WORD state --- 0 .. n
0 == SM \ current state machine
ALIAS : Action
Action aA CR ." A" ;
Action aB CR ." B" ;
Action aC CR ." C" ;
: AST ( -- ) \ Apply State Transition
state W@ 4 * SM + \ address of SM table entry
DUP W@ state W! \ next state
2 + W@ CALL
;
: RUN 0 state W! 10 TIMES AST NEXT ; \ normally infinite loop
TABLE mySM
\ S# next action
( 0 ) 1 || ' aA ||
( 1 ) 2 || ' aB ||
( 2 ) 0 || ' aC ||
mySM TO SM
RUN
A
B
C
A
B
C
A
B
C
A
ok
Actions can be reused for multple states, and the table extended to include INPUT + STATE to give NEXT & ACTION
e.g.
TABLE mySM
\ Input=0 Input=1 Input=2
\ state# next# Act# next# Act# next# Act#
( 0 ) 1 ' aA 2 ' aA 3 ' aB
... \ whatever you like
of course instead of a fixed table it could be implemented as linked lists ...
but KISS
Comments
Have you done a CAN bus Transceiver compatible version of this ?
CAN has a larger fixed offset, so has higher noise immunity in a non-driven bus, and you can get regulators + CAN drivers in one package.
It would need 2 pins as TxD, RxD, with the RxD gated during Tx if you do not echo-verify.
TJF1051 claims 5MBd and is 39c/1k.
Microchip claims 8MBd for their MCP254x, +/- 58V CAN pins rated, with a pulsed wake up option for low energy systems.
Are you touching the file with an editor that is messing the the CR LF pairs somehow since you are working with two OS's ?
I had this problem with CR LF until I set both editors on different OSs to the same.
Thanks for helping!
I have to write some AT commands with 9600 BAUD to a HC-06 Bluetooth Board and would like to use this as an entry to learn serial communication with Tachyon.
I found also code like this in the thread This seems easy enough for me but when I do this on console Tachyon dies. Maybe I kill the baudrate with my minicom terminal but how can I select a RX and TX pin, change the Baudrate communicate with the device and visualize all this on the console?
I tried this But no success because of trial and error. Tachyon stopps working. What do i do with this code?
I cannot seem to set the minutes with this DS3231?
I will double check but make sure you select DS3231 and to lock it in sometime with backup. This option covers most RTCs and then there is the MCP79410 and NORTC which just maintains an internal RTC after updating (as in NTP etc).
Alright Peter what the heck is this? I think you went "full C pointer de-reference" here
pub TIME! ( #hh.mm.ss -- ) \ write time in decimal format @rtc IF DUP time ! RDRTC #100 U/MOD SWAP DEC>BCD $80 OR rtcbuf C! --- don't see the need to set MSB either? #100 U/MOD SWAP DEC>BCD * 1+ C! --- should be #100 U/MOD SWAP DEC>BCD rtcbuf 1+ C! DEC>BCD rtcbuf 2+ C! WRRTC ELSE 100 U/MOD 100 U/MOD 60 * SWAP + 60 * + 1000 * time ! THEN ;What do you mean??
If NORTC is selected than the RTC I2C address @rtc = 0 which means there is no device. Now if we try to set the time for NORTC I decided that time would be time in millseconds so that #160624 (YYMMDD) would be converted to milliseconds and the time variable updated by the background task every millisecond. At least that's what I think I remember doing ...
edit: now I remember, it was such a pain checking for minutes, hours etc that I just decided that the whole time format mess would be better off representing the time of the day in milliseconds. I also despair of RTC chips that continue to represent time in BCD format with other flags mixed in with those bits depending upon the chip. What a mess! I intend to program a little PIC with a 40kHz crystal as my new universal RTC with I2C and single I/O modes. That way it stores the time of the day in milliseconds and also takes care of the dates etc. With onboard temperature sensing I could even compensate for drift.
1. reset Tachyon
VER .MODULES Propeller .:.:--TACHYON--:.:. Forth V29160613.0000 MODULES LOADED: 1B80: EXTEND.fth Primary extensions to TACHYON kernel - 160607-23002. After researching the thread I found that this could work: 3. Console won't come back. Why?There seems a gotcha with the line breaks or even a missing surrounding word definition or whitespace, indentation or ... Ahh - missing word definition - check: This works like the first version.
@Peter: Just for a better understanding - can you give a short explanation?
Thanks for your time!
That is why we can use BEGIN UNTIL DO LOOP etc interactively and we don't need special words either just to print literal strings etc.
Now, I did use the word "normally" and there are certain words that are IMMEDIATE and unless overridden will execute immediately when they are found such as IF which needs to setup a branch but there may be other words too and they may need parameters at "compile time" but these parameters are not available because they have been compiled by default. This is where the GRAB word comes in as it basically executes all the stuff that has been temporarily compiled up to that point such as parameters and in effect grabs those parameters for the use of an upcoming IMMEDIATE word. This may sound confusing but when there are times you need to change the way words are compiled and this method starts to make sense.
Now "normally" the line of compiled text executes on a CR but you can also tell it to continue and I happen to use the | symbol to indicate line continuation without executing. Thinking about this symbol I know I'd like to use the nix \ instead but that is a Forth comment word, however I guess if it is the last character on a line then it could become the line continuation instead of |. Now putting that aside we are looking at your multi-line interactive compilation. You may have noticed at first that every time you entered the line that it would execute then say ok after which you realized you needed to put that in a definition. You don't have to create a definition to do this though rarely would we need an interactive input continued beyond one line but that doesn't mean we can't which is why we could use | until we are ready.
Things to help you understand Tachyon Forth.
1) Get to know Forth (Starting Forth etc)
2) Forget that you "know" Forth, ANSI or otherwise
3) Remember the KISS principle, that we need it to be practical and to perform
4) Remember that this is the quirky and powerful Propeller chip but that we only have 32k of memory.
Now the 4th point brings us to Tachyon, the version of Forth that was created to run on the Propeller in a limited amount of memory etc. Unlike many Forths or other languages that run on PCs with gigs of resources we are using the Propeller to talk to peripherals and signals in real-time and interactively to boot, hence the choice of Tachyon. BTW, we could have more standard interactive languages but unless they are practical and perform then what is the point of using the Propeller chip itself? So Tachyon is a tool to get things done efficiently, and the reason for the tool is to create working and commercial applications with the Propeller. That statement in itself highlights a big difference with other more "standard" approaches which may look nice but what is the point if you can't get the job done. It's no good being able to run a standard benchmark, or only have enough room to compile part of the whole system or have it run too slowly or need expanded memory kludges that still run slowly, which from a practical viewpoint you may as well not use the Propeller then.
If you get your job done and have fun at the same time then these are all pluses in my book. But Tachyon is not an exercise in writing a "language", it is a means to an end when no other solution worked or works. When you can run a compiler, a debugger, a run-time library, a file-system, network servers, VGA, communications ports, and many many other uses all together in an ordinary otherwise unexpanded 32k RAM Propeller chip then you know that this solution must be good and practical and useful and worthwhile considering if you are serious about deploying the Propeller chip in real 24/7 working projects in the field.
Hey hey hey, besides Sunday socials I sometimes even respond verbosely, even didactically, Now, back to the P2, I will put the server online shortly but it will between bootloader tests though.
Here's a shot of how the board looks currently, I've still got the Puppy modules to place and RS485 as well as the ESP8266. Notice the 8-pin smd Flash and EEPROM soldered directly to the 0.1" pads, just bend up pins that aren't used and position slightly to get the right pins on the right pads.
I'm wondering about cutting the trace to the activity light so CS is "free"
The schematic is Here
The breakout is working and tested with Arduino and I have quadruple checked my pinouts and settings.
So much of this hardware out there is cobbled together from bits of information here and there so that when I look at the design of that breakout board it looks like they don't really know what they are doing. But from a marketing point of view you would want something more on the board than a socket so it looks better having an "interface" chip that also only costs them 17 cents
Thank you both for your patience and guidance. Peter's answer gave me some important hints (GRAB, IMMEDIATE I already wondered about in the source).
D.P., thank you for your offering - I don't want Peter to take you away (hopefully this is correctly written ). And you are right he should invest into P2, but maybe he can relax when answering "basic" questions. Now enough fun, have to continue working...
It gets easier and you become more productive. Just look at the pace that Peter is filling out all the nooks and crannies in P2. He will make smart pins accessible ( to himself) and us mere mortals with simple access and setup words very similar to how he exposed the guts of the timers in P1!
WORD nextstate ok WORD currstate ok WORD laststate ok ok ALIAS : State ok ok State sOne CR ." One" ' sTwo PNS error in sOne at PNS ; *error*If I'm right the error comes from the at compile time not yet known word definitions.1. Am I right that this isn't possible with the current compile paradigms in Tachyon?
2. Does anybody have a better idea how I could do exactly this or maybe a bit changed and as lean as this?
I prefer table driven state machines. (untested code !! - to give the idea)
Actions can be reused for multple states, and the table extended to include INPUT + STATE to give NEXT & ACTION
e.g. of course instead of a fixed table it could be implemented as linked lists ...
but KISS