( 0079 $3628 ok ) BLINKEM
( 0080 $3628 ok ) STOPEM <-- some LEDs still on although blinling stop
( 0081 $3628 ok ) BLINKEM
( 0082 $3628 ok ) STOPEM <-- some LEDs still on although blinling stop
( 0083 $3628 ok ) BLINKEM
( 0084 $3628 ok ) ' STOPEM TIMERJOB <-- some LEDs still on although blinling stop
( 0085 $3628 ok ) BLINKEM
( 0086 $3628 ok ) ' STOPEM TIMERJOB <-- some LEDs still on although blinling stop
( 0087 $3628 ok )
@frida - I've read and reread your request a few times but I'm still not sure what you are asking. There are multiple ways of setting pins high and low all of which automatically set the dir register. In fact there is never any need to directly access the dir register. Do you have a code example of how you intend to use the instructions?
These are a list of the direct I/O instructions.
OUTSET ( mask -- ) Set the pins to high (also sets dir)
OUTCLR ( mask -- ) Clear the pins to low (also sets dir)
LOW ( pin -- ) Output a low on pin (also sets dir)
HIGH ( pin -- ) Output a high on pin (also sets dir)
FLOAT ( pin -- ) Float the pin back to an input (clears dir)
H ( pin -- pin ) Output a high on pin (sets dir, fast i/o, stack intact)
L ( pin -- pin ) Output a low on pin (sets dir, fast i/o, stack intact)
F ( pin -- pin ) Float the pin to an input (clears dir, fast i/o, stack intact)
P ( pin -- pin ) Pulse the pin (sets dir, fast i/o, stack intact)
PIN@ ( pin -- flg ) Read the state of the pin and return with a boolean flag
IN ( mask -- flg ) Read the state of the pins and return with a boolean flag
These operations are available but not normally used
OUTPUTS ( mask -- ) Set pins to outputs (does not write to OUTA)
INPUTS ( mask -- ) Set pins to inputs
Just paste this file and run the commands
BLINKEM
STOPEM
Read the source to see the changes, don't directly run ' STOPEM TIMERJOB
See the new STOPEM word which calls ' STOP-all TIMERJOB
I just now recompiled this and tested again.
IFDEF timer.fth
@rest org
FORGET timer.fth
}
pub ." timer 2017/06/17 11:49:45 " ;
@org W@ == @rest --- remember
\ * SIMPLE ROUTINE TO EXERCISE ALL 8 LEDS WITH TACHYON TIMERS
\ * AND ALARMS ON THE PROP QUICKSTART BOARD
\ *
\ * USE THE WORD "BLINKEM" TO START THE LIGHTS
\ * AND "STOPEM" TO STOP THE LIGHTS
TIMER mt0
TIMER mt1
TIMER mt2
TIMER mt3
TIMER mt4
TIMER mt5
TIMER mt6
TIMER mt7
: blink0 #16 PIN@ IF #16 LOW #500 ELSE #16 HIGH #50 THEN mt0 TIMEOUT ; --- timer alarm rountine and reset
: B0 ' blink0 mt0 ALARM ; --- assign blink0 as mt0 alarm vector
: blink1 #17 PIN@ IF #17 LOW #300 ELSE #17 HIGH #50 THEN mt1 TIMEOUT ;
: B1 ' blink1 mt1 ALARM ;
: blink2 #18 PIN@ IF #18 LOW #150 ELSE #18 HIGH #50 THEN mt2 TIMEOUT ;
: B2 ' blink2 mt2 ALARM ;
: blink3 #19 PIN@ IF #19 LOW #285 ELSE #19 HIGH #50 THEN mt3 TIMEOUT ;
: B3 ' blink3 mt3 ALARM ;
: blink4 #20 PIN@ IF #20 LOW #175 ELSE #20 HIGH #50 THEN mt4 TIMEOUT ;
: B4 ' blink4 mt4 ALARM ;
: blink5 #21 PIN@ IF #21 LOW #335 ELSE #21 HIGH #50 THEN mt5 TIMEOUT ;
: B5 ' blink5 mt5 ALARM ;
: blink6 #22 PIN@ IF #22 LOW #100 ELSE #22 HIGH #50 THEN mt6 TIMEOUT ;
: B6 ' blink6 mt6 ALARM ;
: blink7 #23 PIN@ IF #23 LOW #195 ELSE #23 HIGH #50 THEN mt7 TIMEOUT ;
: B7 ' blink7 mt7 ALARM ;
: clrpin $FF0000 OUTCLR ;
: BLINKEM
B0 B1 B2 B3 B4 B5 B6 B7 --- assign the alarm vector to timers
#10 mt0 TIMEOUT --- start all the timers
#20 mt1 TIMEOUT
#30 mt2 TIMEOUT
#40 mt3 TIMEOUT
#50 mt4 TIMEOUT
#60 mt5 TIMEOUT
#70 mt6 TIMEOUT
#80 mt7 TIMEOUT
;
: STOP-all
0 mt0 ALARM --- assign the alarm vectors to null, they will stop after the last timeout.
0 mt1 ALARM
0 mt2 ALARM
0 mt3 ALARM
0 mt4 ALARM
0 mt5 ALARM
0 mt6 ALARM
0 mt7 ALARM
$FF0000 OUTCLR --- clear all pins
;
: STOPEM ' STOP-all TIMERJOB ;
END
\ ?BACKUP
V4.5 status
I'm still fixing a few things and the main problem with getting EASYNET to work properly turned out to be a matter of case sensitivity. After a COMPACT operation the TACHYON and END words are redefined and they didn't reenable case sensitivity. However I renamed all those conflicting duplicates anyway.
If you are checking I/O states I used to have an "lsio" command but there is a lean and mean in V4.5 that pretty much tells me everything I need to know in one line.
Here's a Telnet session and a dictionary list etc over that session. It still amazes me how much code and dictionary we can squeeze into a standard Prop system without running out of memory or lacking in speed.
I usually code MYTASK as an infinite loop. A simple way is to control the loop (MYTASK) behavior is to check the status of a word in the loop and continue or stop. You could also use the word to either do work in the loop or just NOP. The word can be changed from the console cog or another cog. I have only used two cogs in Tachyon ever so far, one to run an async serial receive buffer and the main console cog. In the main console cog I would just use timers and KEYPOLL to run everything else.
I'm doing i2c with clockstreching in Tachyon.
And need to keep sda and scl low while i change DIRA.
Your SHROUT toggles OUTA, so I can not use it.
CLOCK also uses OUTA, where I need to CLOCK DIRA.
I'm doing i2c with clockstreching in Tachyon.
And need to keep sda and scl low while i change DIRA.
Your SHROUT toggles OUTA, so I can not use it.
CLOCK also uses OUTA, where I need to CLOCK DIRA.
Oh, the rare clock stretch. I suppose that could be handled ok. I will have a look at it shortly.
@org W@ == @rest --- remember
\ * SIMPLE ROUTINE TO EXERCISE A TASK
\ * AND LEDS ON THE PROP QUICKSTART BOARD
\ *
\ * USE THE WORD "STASK" TO START THE TASK
\ * AND "TASKS" TO STOP THE TASK
LONG RFLAG --- is the task to run
LONG CNTR1 --- something to hold a count
OFF RFLAG ! --- task not running
: MYTASK
16 longs mystk --- give task some stack space, not needed here but for more complex tasks
mystk LP!
BEGIN
RFLAG @ IF --- check the flag
CNTR1 ++ --- increment the CNTR1
--- do more sutf
ELSE
NOP --- don't do anything
THEN
AGAIN
;
: STOPT OFF RFLAG ! ; --- stop the tasks
: STARTT --- start the task, don't start twice so STOPT first
ON RFLAG !
;
: RCNTR1 CR CNTR1 @ . ; --- read the counter
STOPT --- start task in stopped state
' MYTASK TASK? RUN --- load the task when this module loads
END
I would like to get an integration "channel" with a tachyon cog to support the ESP8266 asynchronous webserver/wifi.
Currently I'm submitted Tachyon words via the CONsole RX cog and having the Tachyon words return JSON results.
Looking for a better integration methodology, sanity check.
what are you running on the ESP8266?
When you run Lua, then you have a Read-Eval-Print loop like in Tachyon.
So depending if you want to set up a very generig interface or something more specific
the approach might differ.
I used it a year ago to send ping - water level measurements from Prop via ESP to ThingSpeak.
I just defined the sending function on the ESP and send the function call with parameters from the Tachyon/Prop.
@MJB I'm running a standard C++ build that has an asynchronous web server and tcp stack, not Lua. I have JS webpages served from this resource. AJAX calls in the webpages get serviced on the ESP and the handler sends TACHYON words via the CONsole RX port. Tachyon responds with JSON via the CONsole TX to the ESP handler which then propagates the JSON back to the originating AJAX call from the web page.
I am able to handle gauge data..., update stuff such as time date, configurations .... this way. Works pretty good right now. The build even has a HTML TERMinal built in that connects to the Tachyon CONsole while at the same time the AJAX calls are being handled. This was created by me with much "tech debt" and is not ideal. It would be grand to have a Tachyon COG dedicated to the AJAX channel.
The build also has a complete 4 Mb file system with file browser (CRUD too) and ACE Editor instance that is HTML, CSS, JS and FORTH aware, it's all actually very cool and what it does on that little $5 chip is amazing, much like Tachyon on the P1. Together they are really nice so far.
To get TACHYON to load on my Propeller with 32K I have
Changed the following in EXTEND.FTH:
All "1 I2C@" to "-1 I2C@" because CLKOUT makes a shift to the left so that
there shall many shift to until we get one 1 so the DIRA can be added to input, so
sda will be 1 at the last reading.
'I2C support
'CLKOUT (iomask dat - iomask dat2) REG6 = iomask) Shift msb bit out, clock high, clock low
CLKOUT andn OUTA, tos + 1 'ensure output will be active low
Breath OUTA, clockpins
Shl tos, # 1 wc
Muxnc DIRA, tos + 1 'make it an output if it is a low else float
'CLOCK (REG6 = iomask) Toggle multiple bits on the output)
CLOCK xor OUTA, clockpins
Tjz clkdly, unext
Mov x, clkdly
Djnz x, $
Jmp unext
There are also changes in "@EEWAIT" and "@EE"
In "BOOT" I have changed so 32K does not spend time on anything that does not fit.
pub BOOT
' TIMER.TASK 2 RUN
!POLLS
PLAIN .MODULES CR .AUTO .FREQ lsini CR
ep 128 = IF
f32cmd 3 " F32 " LOADCOG ( start up F32 )
THEN
The last thing I've moved and changed is for 64K
I have made so my 64k RTC is activated at startup.
pri ~I
SWITCH
$DE CASE " MCP79410" BREAK
$AE CASE " RTC EEPROM" BREAK
SWITCH@ 4 >> SWITCH
$4 CASE " I/O EXPANDER" BREAK
$7 CASE " DISPLAY I/O" BREAK
$A CASE " EEPROM" BREAK
$D CASE " RTC" I =rtc BREAK
" unknown"
;
pub lsi2c CR PRINT" *** I2C ***" 2 BY 128 FOR <I2C I 1+ I2C!? 0= IF CR I .BYTE SPACE I ~I PRINT$ THEN I2C> NEXT ;
Hope there is some of what you can use!
Now I'm going to play with my RTC.
Attached a zip file with my changes and the original as well as a diff file
@frida - The 1 I2C@ is not data, it is simply a flag, true or false, so the actual true doesn't matter.
What is "Breath"? This is the only change I see in this section, normally this is an "andn".
Breath OUTA, clockpins
Skipping F32 during BOOT on a 32k system doesn't really make a big difference to the boot time anyway, however I recommend upgrading any 32k EEPROMs you have to 64k to gain many benefits with Tachyon. My interactive shell I'm testing uses upper EEPROM for the interactive line history and editing which is really useful during testing. Of course the upper 32k can store the dictionary after COMPACT and also the ROMs and other configuration parameters that can persist after a Prop tool load which wipes the first 32k.
That's a good idea to add that "I =rtc" to the lsi2c to automatically enable any RTC device it finds. However I just realized that this will also override other types of RTC at other addresses, so perhaps I will make it skip the setting if it is already set.
@rtc NOT IF I =rtc THEN
I try to make these extensions general rather than tied to specific hardware.
I will try to look at adding the I2C clock stretching which btw only occurs during the ack clock as per the I2C specs.
' I2C support
' CLKOUT ( iomask dat -- iomask dat2 ) REG6=iomask ) Shift msb bit out, clock high, clock low
CLKOUT andn OUTA,tos+1 ' ensure output will be active low
andn OUTA,clockpins
shl tos,#1 wc
muxnc DIRA,tos+1 ' make it an output if it is a low else float
' CLOCK ( REG6=iomask ) Toggle multiple bits on the output)
CLOCK xor OUTA,clockpins
tjz clkdly,unext
mov X,clkdly
djnz X,$
jmp unext
Sorry I didn'n see what
google translate was doing.
pub ackI2C@ 0
--- 25.5us @96MHz
pub I2C@ ( ack -- data \ Fetch a byte from the I2C bus - mirror ack signal 0 in = 0 out ) \ 36.6us
*SDA DUP FLOAT MASK 0 ( ack iomask dat )
8 FOR CLKIN CLOCK NEXT
OVER OUTSET --- make SDA an output
-ROT SWAP CLKOUT DROP CLOCK INPUTS
;
You can call ackI2C@ which is
0 I2C@
and
1 I2C@
when it sent its flag 0 or 1
As I understand it:
if sending a 0 or a 1 to CLKOUT
-ROT SWAP CLKOUT DROP CLOCK INPUTS
it is shifting 1 left
so bit 31 is in carry which is 0 and write a 1 to DIRA which set SDA low.
but if I use
-1 I2C@
it sent -1 bit 31 is 1, shiftet 1 left, then carry is 1,
which sent a 0 to DIRA which set SDA high.
' I2C support
' CLKOUT ( iomask dat -- iomask dat2 ) REG6=iomask ) Shift msb bit out, clock high, clock low
CLKOUT andn OUTA,tos+1 ' ensure output will be active low
andn OUTA,clockpins
shl tos,#1 wc
muxnc DIRA,tos+1 ' make it an output if it is a low else float
' CLOCK ( REG6=iomask ) Toggle multiple bits on the output)
CLOCK xor OUTA,clockpins
tjz clkdly,unext
mov X,clkdly
djnz X,$
jmp unext
As I understand the last read from I2C shall set SDA high = nack.
I've just had an idea for implementing a help file. If I assign a file for every word and place them inside a help folder it becomes easier to maintain and easy for a HELP function to find and display.
Now here's the thing, I have to create all these little files but it would be helpful if I had some help. If I create a Dropbox folder we could all edit then this would be helpful.
Sorry, I can't help myself. Oh, there I go again....
BTW - since I stick to 8.3 names for files I would have a lookup file that had the real name and the 8.3 name. The HELP command could lookup this file first and then know which file to open.
Frida - I think I see what you mean, so the change that you made was to use a -1 TRUE flag instead of 1 since CLKOUT shifts the MSB. That looks like that small bug was introduced when I added those CLKIN and CLKOUT instructions in V4 although I haven't noticed any side effects yet
I see that I have 1 I2C@ in quite a number of places so I may as well define a nakI2C@ etc. When I have some time I will test it out properly and implement the clock stretch at the same time.
As always, a good way to formulate a specification is to try various approaches. Well I found that what I really needed was an index file that had a list of all the words and which file to use. A lot of these words have a common help file, so all I do is find the word in the index and open up its help file while highlighting the word in bold with the simple rule that the first word on a new line that matches is close enough
Index file entries are simple enough, the first word on a line is the help file name and then after tabs or spaces are a list of words on that same line. There is no real size limit for a line but the help system works well enough too to have lines split up so that they are easier to maintain.
An index file is just a normal text file and looks a bit like this:
LOOPS.TXT FOR NEXT FROM BY FOR! FOR@ BY! LP! I J ADO LOOP+ LEAVE
PINIO.TXT LOW HIGH FLOAT OUTCLR OUTSET OUTPUTS H L N P F PIN@ IN
MATHS.TXT 1+ 1- + - 2+ 4+ 2- MIN MAX * UM* U/ U/MOD / UM/MOD64 UM/MOD32 */ UM*/ ABS ?NEGATE NEGATE
I2C.TXT I2C400 I2C100 ~D I2CFAST FI2C@ nakI2C@ I2C@ ackI2C@ I2C! I2C!? I2CSTOP I2CSTART I2C> <I2C> <I2C ?I2C i2cflg
SERIAL.TXT SHROUT SHRINP SPIWRB SPIWR16 SPIWR SPIRD SPICE
MEMORY.TXT IC! IC@ C@ W@ @ C+! C! C@++ W+! W! +! ! C~ W~ ~ BIT? SET? SET CLR BIT! CMOVE ERASE FILL <CMOVE
If you type HELP SHROUT it will search the index file for that keyword and when found it will use the file name found at the start of the line to open up the file and display that with the highlighted keyword. ANSI terminals respond to color and character attributes so it would be fairly easy to at least place the keyword in BOLD or some color.
Now, back to the original question, can anyone help with the help? If so I will look to upgrade my Dropbox account so I can add permissions if that will work but what I want is like a Tachyon folder that automatically synchs across users. Ideas?
I would contribute to HELP just so I can HELP myself with all the words I need HELP with.
Also the Intro needs HELP since 4x5 is the kernel we should be all developing upon.
Hey, less grumble, more go bro!
If you yourself incur some Tachyon "tech debt" doing what you can rather than balking at what you can't and then we have that multiplied by X contributors doing the same then we all reap the benefits collectively. I can fill in all the bits that can't be done by anyone else and of course provide inside information into how best to use it and why or have myself shown a better way.
On another thread there was a discussion about teaching and learning which shows that if handled properly by the teacher that student teaching student is the best way of learning - "Qui docet discit"
BTW, I am adding HINT to HELP just for one-liner extractions which may also be useful for embedding into EEPROM.
BTW, I will change the title of the intro to indicate V3 and save that as a copy so that the original link will point to the latest version.
I try to rite code for SHT31.
This is first i2c-device with ClockStreching although I have 50pcs for i2c-device.
But I cannot detect SCL-low at ClockStreching enable mode.
Do you have any idea?
As always, a good way to formulate a specification is to try various approaches. Well I found that what I really needed was an index file that had a list of all the words and which file to use. A lot of these words have a common help file, so all I do is find the word in the index and open up its help file while highlighting the word in bold with the simple rule that the first word on a new line that matches is close enough
Index file entries are simple enough, the first word on a line is the help file name and then after tabs or spaces are a list of words on that same line. There is no real size limit for a line but the help system works well enough too to have lines split up so that they are easier to maintain.
An index file is just a normal text file and looks a bit like this:
LOOPS.TXT FOR NEXT FROM BY FOR! FOR@ BY! LP! I J ADO LOOP+ LEAVE
PINIO.TXT LOW HIGH FLOAT OUTCLR OUTSET OUTPUTS H L N P F PIN@ IN
MATHS.TXT 1+ 1- + - 2+ 4+ 2- MIN MAX * UM* U/ U/MOD / UM/MOD64 UM/MOD32 */ UM*/ ABS ?NEGATE NEGATE
I2C.TXT I2C400 I2C100 ~D I2CFAST FI2C@ nakI2C@ I2C@ ackI2C@ I2C! I2C!? I2CSTOP I2CSTART I2C> <I2C> <I2C ?I2C i2cflg
SERIAL.TXT SHROUT SHRINP SPIWRB SPIWR16 SPIWR SPIRD SPICE
MEMORY.TXT IC! IC@ C@ W@ @ C+! C! C@++ W+! W! +! ! C~ W~ ~ BIT? SET? SET CLR BIT! CMOVE ERASE FILL <CMOVE
If you type HELP SHROUT it will search the index file for that keyword and when found it will use the file name found at the start of the line to open up the file and display that with the highlighted keyword. ANSI terminals respond to color and character attributes so it would be fairly easy to at least place the keyword in BOLD or some color.
Now, back to the original question, can anyone help with the help? If so I will look to upgrade my Dropbox account so I can add permissions if that will work but what I want is like a Tachyon folder that automatically synchs across users. Ideas?
Hi Peter,
just took some time to have a look at the proposed help system.
And I was wondering. Quite some time ago we started some help system
for EXTEND, which was to take the help documentation (onliner, help, examples) directly from the source code and maybe create the files via a little script (or even Tachyon itself during load ??, and writing the SD files ??)
Usually this way source & doc do stay in sync better.
Also I like having the descriptions close by when studying your source ;-).
Otoh I see that big doc/and especially examples blow up the source size.
So I am not exactly sure which approach really is the better.
Definitely ANY documentation will beat NO documentation ;-)
I haven't looked into using Dropbox for collaboration since it does not run on my old XP-Box
any more. But I might be able to use the Win7 Laptop after I find out how to set up 2 different drop box accounts on one single PC.
Notes: GETWORD is being deprecated in V4.5 in favor of deferred words causing unknown words to be converted to strings.
This preserves the flow of the input stream rather than diverting to GETWORD.
Example: FOPEN myfile --- FOPEN is deferred to execute at the end of the line so myfile is converted to a string which
the deferred FOPEN can then use without interrupt the input stream.
will this imply I can only have one of those on one line?
Or can I have multiple deferred actions?
GETWORD wsa quite handy some times, so I will need to study how to acomplish those tasks the new way ...
@mjb - what we need is something that is in one place and easy to maintain and just works as is. Having help information embedded in the source is handy but awkward too. There is no reason though that I can't also place the source files in the help folder so that the source code can be shown along with the help. So we have HELP and HINT and maybe SOURCE to access these files etc.
As to this new deferred action it is something I wanted to implement for quite a while as it is also useful for parsing non-Forth style text. Besides GETWORD really needs all the editing functions in it to work properly and although that could be tied in with other common functions it was not the way I wanted to go as I was reducing it down to single character processing. You may have noticed that if you typed something in interactively that it didn't really support and kind of editing and I would make mistakes all the time. The new interactive shell which is optional allows line by line processing even though the kernel processes characters plus it also feels more like a traditional Forth interaction:
.. 12 34 + . 46 ok
The .. is a handy but non intrusive line prompt and I may combine some of these elements into the kernel itself. My experiment with having the line number and code pointer etc as a prompt is fine I think, but as an option and as the default mode during a TACHYON END block load.
@caskaz - this clock-stretching thing is starting to get my attention although I have never ever had to use it myself but I can see that this is the approach that some sensor manufacturers have taken. Personally I would not want a device to stall, I'd prefer to read what it's got from the previous and still current reading without stalling. However, there are sometimes good reasons why a manufacturer would do it the way they do, and sometimes...
I will have a closer look at what you've done and try out a few things.
Comments
It's boot message.
These are a list of the direct I/O instructions.
Just paste this file and run the commands
BLINKEM
STOPEM
Read the source to see the changes, don't directly run ' STOPEM TIMERJOB
See the new STOPEM word which calls ' STOP-all TIMERJOB
I just now recompiled this and tested again.
How does MYTASK stop?
I'm still fixing a few things and the main problem with getting EASYNET to work properly turned out to be a matter of case sensitivity. After a COMPACT operation the TACHYON and END words are redefined and they didn't reenable case sensitivity. However I renamed all those conflicting duplicates anyway.
If you are checking I/O states I used to have an "lsio" command but there is a lean and mean in V4.5 that pretty much tells me everything I need to know in one line. U means pulled-up, D for down, F for float.
Here's a Telnet session and a dictionary list etc over that session. It still amazes me how much code and dictionary we can squeeze into a standard Prop system without running out of memory or lacking in speed.
btw - I had to snip some extra stuff off into the next post, the forum code complained that the body was way too big.
I usually code MYTASK as an infinite loop. A simple way is to control the loop (MYTASK) behavior is to check the status of a word in the loop and continue or stop. You could also use the word to either do work in the loop or just NOP. The word can be changed from the console cog or another cog. I have only used two cogs in Tachyon ever so far, one to run an async serial receive buffer and the main console cog. In the main console cog I would just use timers and KEYPOLL to run everything else.
I'm doing i2c with clockstreching in Tachyon.
And need to keep sda and scl low while i change DIRA.
Your SHROUT toggles OUTA, so I can not use it.
CLOCK also uses OUTA, where I need to CLOCK DIRA.
I would like to get an integration "channel" with a tachyon cog to support the ESP8266 asynchronous webserver/wifi.
Currently I'm submitted Tachyon words via the CONsole RX cog and having the Tachyon words return JSON results.
Looking for a better integration methodology, sanity check.
Here is simple code to exercise a task example
Sample run
what are you running on the ESP8266?
When you run Lua, then you have a Read-Eval-Print loop like in Tachyon.
So depending if you want to set up a very generig interface or something more specific
the approach might differ.
I used it a year ago to send ping - water level measurements from Prop via ESP to ThingSpeak.
I just defined the sending function on the ESP and send the function call with parameters from the Tachyon/Prop.
I am able to handle gauge data..., update stuff such as time date, configurations .... this way. Works pretty good right now. The build even has a HTML TERMinal built in that connects to the Tachyon CONsole while at the same time the AJAX calls are being handled. This was created by me with much "tech debt" and is not ideal. It would be grand to have a Tachyon COG dedicated to the AJAX channel.
The build also has a complete 4 Mb file system with file browser (CRUD too) and ACE Editor instance that is HTML, CSS, JS and FORTH aware, it's all actually very cool and what it does on that little $5 chip is amazing, much like Tachyon on the P1. Together they are really nice so far.
I have made a couple of changes.
To get TACHYON to load on my Propeller with 32K I have
Changed the following in EXTEND.FTH:
There are also changes in "@EEWAIT" and "@EE"
In "BOOT" I have changed so 32K does not spend time on anything that does not fit.
The last thing I've moved and changed is for 64K
I have made so my 64k RTC is activated at startup. Hope there is some of what you can use!
Now I'm going to play with my RTC.
Attached a zip file with my changes and the original as well as a diff file
What is "Breath"? This is the only change I see in this section, normally this is an "andn".
Skipping F32 during BOOT on a 32k system doesn't really make a big difference to the boot time anyway, however I recommend upgrading any 32k EEPROMs you have to 64k to gain many benefits with Tachyon. My interactive shell I'm testing uses upper EEPROM for the interactive line history and editing which is really useful during testing. Of course the upper 32k can store the dictionary after COMPACT and also the ROMs and other configuration parameters that can persist after a Prop tool load which wipes the first 32k.
That's a good idea to add that "I =rtc" to the lsi2c to automatically enable any RTC device it finds. However I just realized that this will also override other types of RTC at other addresses, so perhaps I will make it skip the setting if it is already set. I try to make these extensions general rather than tied to specific hardware.
I will try to look at adding the I2C clock stretching which btw only occurs during the ack clock as per the I2C specs.
Sorry I didn'n see what
google translate was doing.
0 I2C@
and
1 I2C@
when it sent its flag 0 or 1
As I understand it:
if sending a 0 or a 1 to CLKOUT it is shifting 1 left
so bit 31 is in carry which is 0 and write a 1 to DIRA which set SDA low.
but if I use
-1 I2C@
it sent -1 bit 31 is 1, shiftet 1 left, then carry is 1,
which sent a 0 to DIRA which set SDA high.
As I understand the last read from I2C shall set SDA high = nack.
Is my understanding correct?
I've just had an idea for implementing a help file. If I assign a file for every word and place them inside a help folder it becomes easier to maintain and easy for a HELP function to find and display.
Now here's the thing, I have to create all these little files but it would be helpful if I had some help. If I create a Dropbox folder we could all edit then this would be helpful.
Sorry, I can't help myself. Oh, there I go again....
BTW - since I stick to 8.3 names for files I would have a lookup file that had the real name and the 8.3 name. The HELP command could lookup this file first and then know which file to open.
I see that I have 1 I2C@ in quite a number of places so I may as well define a nakI2C@ etc. When I have some time I will test it out properly and implement the clock stretch at the same time.
As always, a good way to formulate a specification is to try various approaches. Well I found that what I really needed was an index file that had a list of all the words and which file to use. A lot of these words have a common help file, so all I do is find the word in the index and open up its help file while highlighting the word in bold with the simple rule that the first word on a new line that matches is close enough
Index file entries are simple enough, the first word on a line is the help file name and then after tabs or spaces are a list of words on that same line. There is no real size limit for a line but the help system works well enough too to have lines split up so that they are easier to maintain.
An index file is just a normal text file and looks a bit like this:
If you type HELP SHROUT it will search the index file for that keyword and when found it will use the file name found at the start of the line to open up the file and display that with the highlighted keyword. ANSI terminals respond to color and character attributes so it would be fairly easy to at least place the keyword in BOLD or some color.
Now, back to the original question, can anyone help with the help? If so I will look to upgrade my Dropbox account so I can add permissions if that will work but what I want is like a Tachyon folder that automatically synchs across users. Ideas?
Also the Intro needs HELP since 4x5 is the kernel we should be all developing upon.
Hey, less grumble, more go bro!
If you yourself incur some Tachyon "tech debt" doing what you can rather than balking at what you can't and then we have that multiplied by X contributors doing the same then we all reap the benefits collectively. I can fill in all the bits that can't be done by anyone else and of course provide inside information into how best to use it and why or have myself shown a better way.
On another thread there was a discussion about teaching and learning which shows that if handled properly by the teacher that student teaching student is the best way of learning - "Qui docet discit"
BTW, I am adding HINT to HELP just for one-liner extractions which may also be useful for embedding into EEPROM.
BTW, I will change the title of the intro to indicate V3 and save that as a copy so that the original link will point to the latest version.
I try to rite code for SHT31.
This is first i2c-device with ClockStreching although I have 50pcs for i2c-device.
But I cannot detect SCL-low at ClockStreching enable mode.
Do you have any idea?
Peter, I checked i2c word.
These use [*SCL HIGH *SDA HIGH].
Some i2c-device might not operate well.
I modified them because PropForth was same as.
https://github.com/caskaz/PropForth5.5/tree/master/HW_Extensions/i2c_device
Hi Peter,
just took some time to have a look at the proposed help system.
And I was wondering. Quite some time ago we started some help system
for EXTEND, which was to take the help documentation (onliner, help, examples) directly from the source code and maybe create the files via a little script (or even Tachyon itself during load ??, and writing the SD files ??)
Usually this way source & doc do stay in sync better.
Also I like having the descriptions close by when studying your source ;-).
Otoh I see that big doc/and especially examples blow up the source size.
So I am not exactly sure which approach really is the better.
Definitely ANY documentation will beat NO documentation ;-)
I haven't looked into using Dropbox for collaboration since it does not run on my old XP-Box
any more. But I might be able to use the Win7 Laptop after I find out how to set up 2 different drop box accounts on one single PC.
Or can I have multiple deferred actions?
GETWORD wsa quite handy some times, so I will need to study how to acomplish those tasks the new way ...
As to this new deferred action it is something I wanted to implement for quite a while as it is also useful for parsing non-Forth style text. Besides GETWORD really needs all the editing functions in it to work properly and although that could be tied in with other common functions it was not the way I wanted to go as I was reducing it down to single character processing. You may have noticed that if you typed something in interactively that it didn't really support and kind of editing and I would make mistakes all the time. The new interactive shell which is optional allows line by line processing even though the kernel processes characters plus it also feels more like a traditional Forth interaction: The .. is a handy but non intrusive line prompt and I may combine some of these elements into the kernel itself. My experiment with having the line number and code pointer etc as a prompt is fine I think, but as an option and as the default mode during a TACHYON END block load.
@caskaz - this clock-stretching thing is starting to get my attention although I have never ever had to use it myself but I can see that this is the approach that some sensor manufacturers have taken. Personally I would not want a device to stall, I'd prefer to read what it's got from the previous and still current reading without stalling. However, there are sometimes good reasons why a manufacturer would do it the way they do, and sometimes...
I will have a closer look at what you've done and try out a few things.