Cluso99 .. Is the tri-state SDA between ! @ actions or when the bus is really waiting after I2CSTOP? I was using Tim Moore's model of bus activity.
My boards from Parallax have the pull ups on both.
There really should be a time-out trap on the stretching code...
I was referring to the ROM BOOT code in the P1 that makes CLK an output, rather than driving the CLK as an Open Drain. Neither matters unless there is no pull-up on the CLK line. Even so, quite often the CLK line will be driven while talking with an I2C device.
Provided SDA is not switching, most likely any pulses (spikes) on CLK will not cause problems. It is just bad practice.
I was referring to the ROM BOOT code in the P1 that makes CLK an output, rather than driving the CLK as an Open Drain. Neither matters unless there is no pull-up on the CLK line. Even so, quite often the CLK line will be driven while talking with an I2C device.
Provided SDA is not switching, most likely any pulses (spikes) on CLK will not cause problems. It is just bad practice.
Well a case in point to this I2C mash up is the DLVR-L30Dxxxx from All Sensors. I wrote a custom "write address" sequence to the chip because it requires certain SDA and SCL states to initialize. I had to move this thing to its own bus pins because it seemed to be clobbering the DS3232 on the bus. Then Peter showed me that I could use the normal Tachyon I2C read instructions for the rest. And he found a bug of course that I am still smarting about myself, "don't ack the last read".
@PaulR Also I'll repeat if there is arduino code to look at see if they are using wire.h to talk to the chip or if they have a custom library.
To put this into perspective, if the Prop2 ROM code thread goes on for much longer at this rate it will catch up soon! I woke up this morning and in the space of less than 7 hours there were 42 new posts! I know how to make the SD boot code fast and lean but with 16k of boot ROM an interactive Tachyon environment could be had, even without Flash or SD. Jupiter Ace here we come.
At almost 3,000 replies and 300,000 views and 100 pages I keep thinking whether to start up a new thread but there wouldn't be any real advantage to it plus any year soon a lot more emphasis would be placed on the P2 version. Now proplem mentioned a while back about celebrating with a drink but I couldn't put my glass down to respond
How are we going with editing the intro page? What changes and additions do we need to make?
BTW - I've left my P2 connected to the Internet with mainly FTP on port 21 but also with Telnet on port 10001 and basic web server on port 81 except that is unreachable at the moment until I change some settings.
I've been delinquent on the Intro page, trying to wrap up GardenControl.fth with a FONA GSM module. Something changed between 2.4 and 3.0 ( you don't say ) that my test code I wrote in 2015 compiles on 3.0 but just doesn't run. No worries gonna get the parsing of the AT style command syntax finished in 2.4, and work on the Intro
Then port to Juno.
Praying for P2 open firmware, also I've been grep'n the P2 folder for CONNECT, hmm. I've got a BE Micro if you care to point to the latest P2 Tachyon with CONNECT so I can work with rs485. And I see the beginnings of the P2 pin mode instructions laid out in one file. If they are as easy as the timers are to use in Tachyon then they we be accessible to mere mortals such as myself.
1+ for the ROM thread
@D.P. Use CHAT in P2's EXTEND to chat on the ping-pong network. The P1 basically needs a cog running a serial receive as there is no easy way to get the Prop to handle high-speed serial and still timeout if nothing arrives. I will look at this tomorrow perhaps.
Imagine that, we could have a bare P2 that boots into an interactive Forth shell....
@D.P. Use CHAT in P2's EXTEND to chat on the ping-pong network. The P1 basically needs a cog running a serial receive as there is no easy way to get the Prop to handle high-speed serial and still timeout if nothing arrives. I will look at this tomorrow perhaps.
Imagine that, we could have a bare P2 that boots into an interactive Forth shell....
Yes, I use a cog to RX cmds from the FONA (TE) right now as directed by you long ago in another project. Works great but I'm always stumped as the best way to handle parsing a protocol. For instance this arrives in the RS232 buffer:
+CMTI: "SM",7 --- +CMTI: "SM" = new sms message indicator ,7 = index of new message
One approach I've seen is Create words that provide logic and then process accordingly.
The darn space and comma are always a challenge for me to directly parse still in Tachyon, I keep stumbling in IF THEN hell it seems, onward.
@D.P. Have you tried setting the delimiter to a comma? See AVAR in EXTEND for an example of this. That way your message would come back as
+CMTI: "SM" 7
to which I would define "SM" perhaps as a constant and +CMTI: as a deferred execution word so that at the end of the line it will execute its deferred word with two parameters, the constant for "SM" and location 7.
+CMTI: pushes a vector onto a deferred execution stack and your ATCOMS word which is automatically executed before the next line with ' ATCOMS prompt W! can read that stack and call the vector, nice and simple.
EDIT: coming to think of it I have a substitution table for the control keys built into JUNO so I think if I extended it for all 128 codes it could simply substitute a space for a comma etc. Along with deferred execution this is another solution. Even the " codes could be replaced with a space.
@D.P. Have you tried setting the delimiter to a comma? See AVAR in EXTEND for an example of this. That way your message would come back as
+CMTI: "SM" 7
to which I would define "SM" perhaps as a constant and +CMTI: as a deferred execution word so that at the end of the line it will execute its deferred word with two parameters, the constant for "SM" and location 7.
+CMTI: pushes a vector onto a deferred execution stack and your ATCOMS word which is automatically executed before the next line with ' ATCOMS prompt W! can read that stack and call the vector, nice and simple.
EDIT: coming to think of it I have a substitution table for the control keys built into JUNO so I think if I extended it for all 128 codes it could simply substitute a space for a comma etc. Along with deferred execution this is another solution. Even the " codes could be replaced with a space.
In the current posted EXTEND.fth from 4 days ago needs this line moved to 2791, above the ".TIMERS" word.
I'm updating a copy of the Intro and found this little error generating new output.
LONG runtime --- this is define in RTC at 2845, needs to be here or above
IFDEF EXPLORER
\ List the timers and their status
pub .TIMERS
SPACE CLKFREQ ttint / ." ticks = 1/" 0 PRINTDEC
." runtime = " runtime @ 0 PRINTDEC
timers W@
BEGIN
DUP $FF >
WHILE
CR DUP .WORD ." : "
DUP 1- >NAME DUP PRINT$ LEN$ #20 SWAP - SPACES
DUP @ 6 PRINTDEC ." ms "
." =" DUP @ .LONG
." L" DUP 6 + W@ .WORD
SPACE DUP 4 + W@ IF ." ALARM=" DUP 4 + W@ >NAME PRINT$ THEN
6 + W@ --- fetch the link to the next timer
REPEAT
DROP
;
}
... mentioned a while back about celebrating with a drink but I couldn't put my glass down to respond
Hi Tachyonista - wow again you have been eager and reached 100 pages (i'm back from holidays). I will rise a cup of coffee on 'Tachyon P1 100 pages' at Sunday Sep. 11, 08:00 GMT this should be 17:00 in Brisbane. Meet you ...
If I do this from the console or within a routine, does it free the memory as well as remove the dictionary entry ?
10 WORDS inbuff
< use inbuff somehow >
FORGET inbuff
The memory for inbuff is allocated in code memory so when you forget inbuff it will restore code space and dictionary to what it was prior to inbuff being created.
.STATS
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
PCB: CE1372 WIDGET (1372)
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL8X )
NAMES: $71B0...74DC for 812 bytes (4,294,967,051)
CODE: $0930...4E4B for 17,691 bytes (4,294,966,635)
RAM: 9,061 bytes free
BUILD: FIRMWARE BUILD DATE 160830:024812 BOOTS: 94 runtime 118,456
BOOT: ok
10 WORDS inbuff ok
inbuff 10 ADO I I C! LOOP ok
inbuff 10 DUMP
0000_4E4C: 4C 4D 4E 4F 50 51 52 53 54 55 00 00 00 00 00 00 LMNOPQRSTU...... ok
.STATS
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
PCB: CE1372 WIDGET (1372)
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL8X )
NAMES: $71A6...74DC for 822 bytes (4,294,967,061)
CODE: $0930...4E60 for 17,712 bytes (4,294,966,656)
RAM: 9,030 bytes free
BUILD: FIRMWARE BUILD DATE 160830:024812 BOOTS: 94 runtime 170,490
BOOT: ok
FORGET inbuff ok
.STATS
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
PCB: CE1372 WIDGET (1372)
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL8X )
NAMES: $71B0...74DC for 812 bytes (4,294,967,051)
CODE: $0930...4E4B for 17,691 bytes (4,294,966,635)
RAM: 9,061 bytes free
BUILD: FIRMWARE BUILD DATE 160830:024812 BOOTS: 94 runtime 177,457
BOOT: ok
Do people routinely do this kind of allocation/deallocation in Forth code, or is it a cheat for those of us who haven't got it yet?
FORGET can be used dynamically too, have a look at the end of EXTEND and you will see the definitions SELRTC and SAVEROMS, both of which are executed as soon as they are defined after which they have served their purpose and are forgotten.
Are there descriptions available on how to use the ROMS available in v3? I am thinking about HSSERIAL ... Thanks!
The general form of loading a cog is straightforward enough, it is:
<parameter pointer> cog <ROM name (8 characters)> LOADCOG
So for F32 it is:
f32cmd 3 " F32 " LOADCOG
However I have been meaning to get around to writing some Forth code that interfaces to these ROMS although I had started to test F32. There isn't much required to get the serial to work though and I may have a look at it shortly.
Is it possible to launch a cog to run an independent interactive Tachyon front end, with its own serial in and out lines? I could launch a cog that keeps running SERIN and executing code based on keystrokes, but that is already built in ...
Is it possible to launch a cog to run an independent interactive Tachyon front end, with its own serial in and out lines? I could launch a cog that keeps running SERIN and executing code based on keystrokes, but that is already built in ...
The Tachyon kernel is loaded up into all the spare cogs and normally are just running an IDLE loop awaiting something to RUN. So you could assign some extra stack space for a cog and point it to CONSOLE but that really needs its own task registers for word and number buffers etc, up to about 164 bytes which you can assign via the TASKREGS word. But I've never had a need for it, it's not like it's the old days of multiuser minicomputers but now it is more like none or one user and multicores
Normally a RUN task is setup for for SERIN buffering although one of the serial ROM objects could probably be used, even the 4-port full-duplex one which is my intention, when I get a round tuit that is!
Jerry Pournelle's rule ... at least one processor per person
You've described my situation ... the prop is watching a 4x4-keypad, an RF button device, the normal console, and a GPS, plus an IMU. OK, time to write parsers ...
Configure a timer to scan the keypad and buffer it. Use a CONSOLE cog for the GPS and comma delimiters and deferred action via "prompt" to greatly simplify the task of parsing those strings. Then consider just using keypoll via a +POLL to check the RF button and perhaps the IMU.
Good ideas all, but the keypad is an asynch source mounted to a handset LCD. I like the RF in a poll, but will have to revise the code (now it sits and waits then times the duration, different key down time give different actions). I saw the GPS code you posted some time back, and will probably steal some of that.
Thanks!
I had a thought today about a technique that I sometimes use for handling infix operations as in parsing GPS strings and even inline assembly. Basically what I do now is when a word has conventional infix operations is that I execute the word first which then sets up a deferred function to be executed at the end of the line. So for instance take this GPS string:
the auxiliary delimiter is set to a comma so that commas effectively become spaces and any number encountered will simply be processed and pushed onto the stack but the problem is the control word or function here is GPGGA which executes before any of the numbers are stacked. What I typically do is get to change the end of line action by pointing to a new function to execute at the end of line via the "prompt" vector.
Now I was thinking that I could have this built in all the time simply by adding an execution stack where deferred functions are executed automatically at the end of the line but also add a new building word called DEFER that is used in a definition when there is code that will not be executed immediately. With comma delimiters the GPS string would reduce to:
GPGGA 123519 4807.038 N 01131.000 E 1 08 0.9 545.4 M 46.9 M *47
where GPGGA is executed immediately as:
pub GPGGA IMMEDIATE
DECIMAL ' ?GPS unum W!
DEFER &GPGGA horz ! sats ! fix ! utc !
;
where the code after DEFER is only executed at the end of the line. In fact the pointer to this code is pushed onto an execution stack which will automatically be called at the end of every line. Seeing though that defer is already a Forth word that is sometimes used in some Forths I will have to call it something different and then I might just implement that "DEFER" and "IS" definition while I'm at it.
So I'm testing this out in V3.1 and I might even manage to squeeze in CREATE DOES> as well while I am playing with these building words but if you can think of any features or ideas related to this then let me know as I may incorporate them at the same time.
btw, the GPS parsing is simply just letting Forth do it's thing with a little help. I've posted code similar to this ages ago and N S E W and M for instance grab values immediately while the remainder of the string is finally processed by the deferred GPGGA code.
Comments
My boards from Parallax have the pull ups on both.
There really should be a time-out trap on the stretching code...
Provided SDA is not switching, most likely any pulses (spikes) on CLK will not cause problems. It is just bad practice.
Well a case in point to this I2C mash up is the DLVR-L30Dxxxx from All Sensors. I wrote a custom "write address" sequence to the chip because it requires certain SDA and SCL states to initialize. I had to move this thing to its own bus pins because it seemed to be clobbering the DS3232 on the bus. Then Peter showed me that I could use the normal Tachyon I2C read instructions for the rest. And he found a bug of course that I am still smarting about myself, "don't ack the last read".
@PaulR Also I'll repeat if there is arduino code to look at see if they are using wire.h to talk to the chip or if they have a custom library.
congrats Peter
To put this into perspective, if the Prop2 ROM code thread goes on for much longer at this rate it will catch up soon! I woke up this morning and in the space of less than 7 hours there were 42 new posts! I know how to make the SD boot code fast and lean but with 16k of boot ROM an interactive Tachyon environment could be had, even without Flash or SD. Jupiter Ace here we come.
At almost 3,000 replies and 300,000 views and 100 pages I keep thinking whether to start up a new thread but there wouldn't be any real advantage to it plus any year soon a lot more emphasis would be placed on the P2 version. Now proplem mentioned a while back about celebrating with a drink but I couldn't put my glass down to respond
How are we going with editing the intro page? What changes and additions do we need to make?
BTW - I've left my P2 connected to the Internet with mainly FTP on port 21 but also with Telnet on port 10001 and basic web server on port 81 except that is unreachable at the moment until I change some settings.
Then port to Juno.
Praying for P2 open firmware, also I've been grep'n the P2 folder for CONNECT, hmm. I've got a BE Micro if you care to point to the latest P2 Tachyon with CONNECT so I can work with rs485. And I see the beginnings of the P2 pin mode instructions laid out in one file. If they are as easy as the timers are to use in Tachyon then they we be accessible to mere mortals such as myself.
1+ for the ROM thread
And some FONA output for the curious
Propeller .:.:--TACHYON--:.:. Forth V24150105.2330 VER: Propeller .:.:--TACHYON--:.:. Forth V24150105.2330 FREQ: 96MHZ (PLLEN OSCEN XTAL1 PLL16X) NAMES: $5A14...74B6 for 6,818 bytes (+16) CODE: $0924...3D32 for 13,326 bytes (+60) CALLS: 370 vectors free RAM: 7,394 bytes free BOOTS: 5 BOOT: EXTEND.boot POLL: MODULES LOADED: 3A3B: fonatest.fth FONA Test V0.3 dp 20151229-2200 1A00: EXTEND.fth Primary extensions to TACHYON kernel - 150116-1700 BOOT: EXTEND.boot POLL: ---------------------------------------------------------------- gofona ok .TASKS 0000: CONSOLE 0000 00 00 00 00 00 00 0002: RS232.TASK 3B48 01 00 00 00 00 00 0003: IDLE 0000 01 00 00 00 00 00 0004: IDLE 0000 01 00 00 00 00 00 0005: IDLE 0000 01 00 00 00 00 00 0006: IDLE 0000 01 00 00 00 00 00 0007: TIMERTASK 34CE 01 00 00 00 00 00 ok crst ok OK cinf ok ATI SIM800 R13.08 OK cdev ok AT&V DEFAULT PROFILE S0: 0 S3: 13 S4:G: 0 +CGREG: 0 +CMEE: 0 +CSCLK: 0 +CIUAAS: 1 +CBUZZERRING: 0 +DDET: 0 +MORINSD2PCM: 1 +IPR: 0 +IFC: 0,0 E: 0: 3,3 Q: 0 X: 4 &C: 1 &D: 1 +CLTS: 0 +CSCS: "IRA" +VTD: 1 +CALS: 1 +CHF: 0000,300 +CSDT: 0 +CSMINS: 0 +EXUNSOL: 10: 15 +CBST: 7,0,1 +CRLP: 61,61,48,6 0,0,10 +STKPCIS: 0 +CMGF: 1 +CNMI: 2,1 +CSGS: 1 +CNETLIGHT: 1 +SLEDS: 64,64,64,800,3000,300 +CSDT: 0 +CSMINS: 0 +EXUNSOL: 0 +SD2PCM: 1 +IPR: 0 +IFC: 0,0 +ICF: 3,3 +CMNRP: 0 OK clal ok AT+CMGL=4 OK +CMGL: 1,1,"",150 07914150740250F54403CEDE9BD960B59A8D0693CD00F6F6DC55769F5DF456 +CMGL: 2,1,"",23 07914150740250F5040B913106535957F40001,"",28 07914150740250F5040B913106535957F4000051 +CMGL: 6,1,"",29 07914150740250F5040B913106535957F400006190402190938A0BC2F0780D0AD341F9771D OKImagine that, we could have a bare P2 that boots into an interactive Forth shell....
Yes, I use a cog to RX cmds from the FONA (TE) right now as directed by you long ago in another project. Works great but I'm always stumped as the best way to handle parsing a protocol. For instance this arrives in the RS232 buffer: One approach I've seen is Create words that provide logic and then process accordingly.
The darn space and comma are always a challenge for me to directly parse still in Tachyon, I keep stumbling in IF THEN hell it seems, onward.
+CMTI: "SM" 7
to which I would define "SM" perhaps as a constant and +CMTI: as a deferred execution word so that at the end of the line it will execute its deferred word with two parameters, the constant for "SM" and location 7.
+CMTI: pushes a vector onto a deferred execution stack and your ATCOMS word which is automatically executed before the next line with ' ATCOMS prompt W! can read that stack and call the vector, nice and simple.
EDIT: coming to think of it I have a substitution table for the control keys built into JUNO so I think if I extended it for all 128 codes it could simply substitute a space for a comma etc. Along with deferred execution this is another solution. Even the " codes could be replaced with a space.
EDIT: found the error 09/08 never mind
Congrats on reaching 100 pages.
Thankfully the forum software didn't croak
I'm updating a copy of the Intro and found this little error generating new output.
LONG runtime --- this is define in RTC at 2845, needs to be here or above IFDEF EXPLORER \ List the timers and their status pub .TIMERS SPACE CLKFREQ ttint / ." ticks = 1/" 0 PRINTDEC ." runtime = " runtime @ 0 PRINTDEC timers W@ BEGIN DUP $FF > WHILE CR DUP .WORD ." : " DUP 1- >NAME DUP PRINT$ LEN$ #20 SWAP - SPACES DUP @ 6 PRINTDEC ." ms " ." =" DUP @ .LONG ." L" DUP 6 + W@ .WORD SPACE DUP 4 + W@ IF ." ALARM=" DUP 4 + W@ >NAME PRINT$ THEN 6 + W@ --- fetch the link to the next timer REPEAT DROP ; }Hi Tachyonista - wow again you have been eager and reached 100 pages (i'm back from holidays). I will rise a cup of coffee on 'Tachyon P1 100 pages' at Sunday Sep. 11, 08:00 GMT this should be 17:00 in Brisbane. Meet you ...
The memory for inbuff is allocated in code memory so when you forget inbuff it will restore code space and dictionary to what it was prior to inbuff being created.
Do people routinely do this kind of allocation/deallocation in Forth code, or is it a cheat for those of us who haven't got it yet?
FORGET can be used dynamically too, have a look at the end of EXTEND and you will see the definitions SELRTC and SAVEROMS, both of which are executed as soon as they are defined after which they have served their purpose and are forgotten.
The general form of loading a cog is straightforward enough, it is:
<parameter pointer> cog <ROM name (8 characters)> LOADCOG
So for F32 it is:
f32cmd 3 " F32 " LOADCOG
However I have been meaning to get around to writing some Forth code that interfaces to these ROMS although I had started to test F32. There isn't much required to get the serial to work though and I may have a look at it shortly.
Cheers!
Is it possible to launch a cog to run an independent interactive Tachyon front end, with its own serial in and out lines? I could launch a cog that keeps running SERIN and executing code based on keystrokes, but that is already built in ...
The Tachyon kernel is loaded up into all the spare cogs and normally are just running an IDLE loop awaiting something to RUN. So you could assign some extra stack space for a cog and point it to CONSOLE but that really needs its own task registers for word and number buffers etc, up to about 164 bytes which you can assign via the TASKREGS word. But I've never had a need for it, it's not like it's the old days of multiuser minicomputers but now it is more like none or one user and multicores
Normally a RUN task is setup for for SERIN buffering although one of the serial ROM objects could probably be used, even the 4-port full-duplex one which is my intention, when I get a round tuit that is!
You've described my situation ... the prop is watching a 4x4-keypad, an RF button device, the normal console, and a GPS, plus an IMU. OK, time to write parsers ...
Thanks!
Now I was thinking that I could have this built in all the time simply by adding an execution stack where deferred functions are executed automatically at the end of the line but also add a new building word called DEFER that is used in a definition when there is code that will not be executed immediately. With comma delimiters the GPS string would reduce to: where GPGGA is executed immediately as: where the code after DEFER is only executed at the end of the line. In fact the pointer to this code is pushed onto an execution stack which will automatically be called at the end of every line. Seeing though that defer is already a Forth word that is sometimes used in some Forths I will have to call it something different and then I might just implement that "DEFER" and "IS" definition while I'm at it.
So I'm testing this out in V3.1 and I might even manage to squeeze in CREATE DOES> as well while I am playing with these building words but if you can think of any features or ideas related to this then let me know as I may incorporate them at the same time.
btw, the GPS parsing is simply just letting Forth do it's thing with a little help. I've posted code similar to this ages ago and N S E W and M for instance grab values immediately while the remainder of the string is finally processed by the deferred GPGGA code.