The memory immediately following myruntime has not been allocated and is where user input is compiled either temporarily or as part of a definition yet you are trying to write directly into this area with 1 var1 !. This would have the effect that as the code for "1 var1 !" is temporarily compiled at the end of code memory and in the process of executing you are then corrupting the code with the !. The zeros that are written are interpreted as RESET opcodes.
Either use an area away from code memory or just preallocate by using "4 LONGS myruntime" assuming that myruntime is the start address of var1 etc.
Have a look at EASYFILE for an example of how ORG and DS is used. Here's a snippet:
#176 BYTES sdinfo
sdinfo ORG --- Use Tachyon reserved buffer space for SD card (normally at $7400)
#64 DS cid --- Card ID
#64 DS csd --- Card Specific Data
#4 DS ocr --- Operating conditions register
Hi there,
AFAIU ORG and DS are used to make contiguous memory accessible with different names. I think of it as a kind of a struct but that seems not the right view.
Could anyone clarify what's wrong with the following code?
0196 MONO16
1900 F32
----------------------------------------------------------------
LONG myruntime ok
myruntime 4 + ORG ok
4 DS var1 ok
4 DS var2 ok
4 DS var3 ok
4 DS var4 ok
1 var1 ! ok
Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
It is completely resetting tachyon. I also tried with U@ and U! but I didn't get it.
Thanks in advance,
proplem
5 LONGS myruntime ok
myruntime 4 + ORG ok
4 DS var1 ok
4 DS var2 ok
4 DS var3 ok
4 DS var4 ok
1 var1 ! ok
this is equivalent to your code above, giving you the LONG myruntime to use
plus 4 more longs to access with var1 .. var4
if you do not need the LONG myruntime itself, then just do this.
myruntime is now a synonym for var1 and also a 4 LONG buffer which gets allocated,
whereas ORG and DS do not allocate space themselves
4 LONGS myruntime ok
myruntime ORG ok
4 DS var1 ok
4 DS var2 ok
4 DS var3 ok
4 DS var4 ok
1 var1 ! ok
AND this is kind of a struct, but you can only have 1 instance of it.
If you need multiple instances you can use the base address of the buffer area for a
specific instance and use the DS defined constants as relative offsets into it - if you use 0 as the ORG base.
When I load EXTEND.fth it leaves two longs (both $0007.1E99 = 466585) on the stack; the stack was clear after the kernel loading. The header of the EXTEND file says 160828-1400, which appears to be the same as the current signature on DropBox files.
Is this normal?
BTW : I don't have an RTC, should I disable this module?
When I load EXTEND.fth it leaves two longs (both $0007.1E99 = 466585) on the stack; the stack was clear after the kernel loading. The header of the EXTEND file says 160828-1400, which appears to be the same as the current signature on DropBox files.
Is this normal?
BTW : I don't have an RTC, should I disable this module?
Cheers!
I have basically ignored the junk but I decided to go on a hunt as I have had some ??? warnings too. Turned out that there were a few things I fixed up although none of them serious.
As for the RTC module I would leave it in as it always provides a soft RTC as a default which is suitable for being synced from a network master for instance. If you plug in a real RTC later you can set it as the default without having to load any software which btw works with a wide variety of various I2C RTC chips.
Thanks Peter, I didn't know if I had broken my code ... my clock-stretching IMU has stopped making sense, but I guess this isn't the problem. Might be hardware.
Back to ROMS ... I don't use them now, but I thought that the splash screen was reporting some when I moved to v3. Now it reports "No ROMS". What would have changed to clobber the ROMS?
Thanks Peter, I didn't know if I had broken my code ... my clock-stretching IMU has stopped making sense, but I guess this isn't the problem. Might be hardware.
Back to ROMS ... I don't use them now, but I thought that the splash screen was reporting some when I moved to v3. Now it reports "No ROMS". What would have changed to clobber the ROMS?
Cheers!
Don't forget you can use a Prop loaded with SPLAT as a logic analyzer and if you can make your target run the IMU in another cog then you can run SPLAT on the target itself.
ROMS will only SAVEROMS if there is more than 32kB of EEPROM and normally it only ever SAVEROMS after a fresh kernel load followed by EXTEND. Performing a COLD when you have only loaded EXTEND and not much else then loading EXTEND again seems to clobber the ROMS too as it still detects remnants of them but this is easily fixed by erasing the hub area after the first SAVEROMS which is what I shall do.
SPLAT? Don't know anything about it. Will read.
I think the hardware is gone because I started to see intermittent readings that made no sense (always same value) and now that is all it returns. I'll check wiring under a scope today.
I am pouring over the code because the I2C acks are behaving oddly, and since I cobbled some of the clock-stretching bits, I am wondering if I screwed something up along the way. Grasping for straws perhaps, but hardware shouldn't fail like this.
SPLAT? Don't know anything about it. Will read.
I think the hardware is gone because I started to see intermittent readings that made no sense (always same value) and now that is all it returns. I'll check wiring under a scope today.
I am pouring over the code because the I2C acks are behaving oddly, and since I cobbled some of the clock-stretching bits, I am wondering if I screwed something up along the way. Grasping for straws perhaps, but hardware shouldn't fail like this.
Hi Peter,
The 32x32 LED matrix I have is using a MBI5024, which contains a 16-bit shift register and 16-bit LED driver. Each half of the matrix has three of these devices, so I imagine they are the 'work horses' of the matrix. The MBI5024 appears to be the same as the TLC59282 from Texas Instruments. Giving the TI data sheet a review.
I posted this in response to another thread but it really belongs here I guess as it is the latest 32k binary that includes the filesystem ready to fire up on any system. This post actually has the file attached which I missed in the other post.
Ok, here's the binary for the Tachyon kernel + EXTEND + EASYFILE which will work directly with any 5MHz or 10MHz Prop with a minimum of 32kB EEPROM. You can specify your own SD card pins by typing in your pin configuration, perhaps checking it with "ls" to list the files, and then BACKUP to lock it into EEPROM.
For instance my test board has this pin configuration:
P25 = CLK
P26 = MOSI (SD DATA IN)
P27 = MISO (SD DATA OUT)
P24 = CS (no pullup)
Enter in this format with an ampersand prefix with the pin numbers separated by a decimal point and don't forget that you need at least one space between Forth words, that is the number and SDPINS.
&24.27.26.25 SDPINS
Check that it works for your board with "ls" and then BACKUP.
ls
Mounted 7948.06B0-06F3.624B MSDOS5.0 NO NAME FAT32 3,955MB (4,096/cluster)
NO NAME
LOGON LOGON .TXT HTTP404 .HTM HOME1 .HTM CE1372 .FTH
HOME3 .HTM HOME .HTM W5200 .FTH NETWORK .FTH SDCARD .FTH
MULTIFAT.FTH ROM .BIN EXTEND .FTH POPCORN .WAV ACCESS .TXT
LOG .TXT LOG0003 .TXT LOG0004 .TXT LOG0005 .TXT LOG0006 .TXT
LOG0007 .TXT LOG0008 .TXT TACHYON .LST SYSLOG .TXT ok
The binary only has about 1k free which doesn't seem much but a lot gets done in that space although if you have a 64kB EEPROM or more you should run COMPACT, wait for that to finish, then BACKUP which gives you around 9k free (stacks of room for Tachyon!).
If you only have a 32k EEPROM then you could run RECLAIM to reclaim private headers that are no longer required which frees up about another 1k or more.
Default Tachyon session is 115200/8N1 and I prefer minicom for Linux or TeraTerm for WIndows.
I'm getting forward with my pc/tachyon connection.
What was the intention to limit telnet, ftp and http by a timeout of 5 mins?
Of course I could disable it in source but should I do so? I don't want to change within EASYFILE.FTH to avoid drifting away from the main trunk.
afaik Peter had/has set up a propeller on tachyonforth.com for others to play with
and this was to release the ports for other players after a while
you can extend the timeout without touching the source
\ original code
\ pri KEEPALIVE #300,000 contd TIMEOUT ; --- ms 300 seconds = 5 MINS
pri KEEPALIVE2 #300,000,000 contd TIMEOUT ; --- ms 300*1000 seconds = 5*1000 MINS
REVECTOR KEEPALIVE KEEPALIVE2
or this should disable it completely
\ original code
\ pri DISCREQ disreq C~~ ;
pri DISCREQ2 disreq C~ ;
REVECTOR DISCREQ DISCREQ2
I'm getting forward with my pc/tachyon connection.
What was the intention to limit telnet, ftp and http by a timeout of 5 mins?
Of course I could disable it in source but should I do so? I don't want to change within EASYFILE.FTH to avoid drifting away from the main trunk.
regards, proplem
If Peter used Git, it would be easy for you to just change EASYFILE.FTH and have it automatically merge your changes with his changes whenever he changed anything.
Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230--
Cold start - no user code - setting defaults
I do
CREATE EXPLORER
paste EXTEND.FTH
and this throws
3154 INCLUDING #14 EXAMINE SPECIAL PURPOSE REGISTERS
3321 INCLUDING #15 Memory Map Reporting
4081 INCLUDING #23 COUNTERS
4388 error in .TIMERS at RUNTIME @ 0 PRINTDEC *error*
It's not urgent but I'd like to use REVECTOR .TIMERS and so on which are IFDEF EXPLORER ed.
edit:
without CREATE EXPLORER pasting EXTEND.FTH is successful and copy and pasting .TIMERS manually works also. Hmm.
In V3 the vector table was reduced to make way for direct calls in self compiled code whereas the vectors were necessary at the Prop tool compile level. At one point in Tachyon's development we eventually ran out of vectors since 1,024 were allocated. Once this happened then Tachyon was updated to then switch to calling using an opcode plus another 2 bytes to specify the absolute address.
So you can only revector if you have a vector but many high level functions in V3, even half-way through EXTEND were already direct calls that never used a vector. V4 does not have any vector table at all but it is possible to do something similar with any high level word by replacing the first word code with a jump code.
I will take a look at the EXPLORER include flags to make sure they are including the timers properly and update that.
As you can probably guess, once I have V4 up and running then that will be the mainstream version that will run faster and use less memory overall so that I can add even more functionality to Tachyon.
you are right I came into trouble with REVECTORing although I was happy about MJB's answer. Though you have seen this trouble I'm happy I know a solution will come.
I was impressed to see your V4 activity and I would like to encourage you to do some additional changes
- please remove whitespace in file and folder names
- there are some files with utf-16 characters which lead to problems diffing them with older versions ("binary files differ")
To explain this:
I'm using gnu make to build a kernel which I'm quite successful with but I always have issues with filenames with whitespace inside which cost a lot of time, time which is lost for tachyoning.
If you consider to do this I could create a list of file names and files to be changed. I'm currently online.
you are right I came into trouble with REVECTORing although I was happy about MJB's answer.
sorry abbout my outdated example
Tachyon is moving so fast that you can not take for granted, that things that worked a while ago are still working ...
V4 does not have any vector table at all but it is possible to do something similar with any high level word by replacing the first word code with a jump code.
hmm ...
having a kind of REVECTOR to be able ro redefine words which are already in use is a good thing ...
sorting the dictionary for binary search would lose the sequence information,
which is used in rewinding with FORGET ??
FORGET is used during development but even now in V3 once the dictionary is moved to EEPROM then the sequence information and the ability to FORGET is lost. If I am developing an application on top of the networking and filesystem layer which are locked into EEPROM that does not mean that my application dictionary is restricted as it still operates normally in RAM just as it does currently.
Sure, you can play and create new words with the same names as old ones, forget them, etc, no problems. Once you have tested all that out and no longer need that "sequence" or the ability to forget then you have the option of moving them to EEPROM to free up some more code memory.
So in practical terms, once again there are no restrictions. Remember, just like the EEPROM dictionary now, it is a hybrid dictionary with new entries always building down in hub RAM as normal.
FORGET is used during development but even now in V3 once the dictionary is moved to EEPROM then the sequence information and the ability to FORGET is lost. If I am developing an application on top of the networking and filesystem layer which are locked into EEPROM that does not mean that my application dictionary is restricted as it still operates normally in RAM just as it does currently.
Sure, you can play and create new words with the same names as old ones, forget them, etc, no problems. Once you have tested all that out and no longer need that "sequence" or the ability to forget then you have the option of moving them to EEPROM to free up some more code memory.
So in practical terms, once again there are no restrictions.
you are right I came into trouble with REVECTORing although I was happy about MJB's answer.
sorry abbout my outdated example
Tachyon is moving so fast that you can not take for granted, that things that worked a while ago are still working ...
Hi MJB, you are beschäming me :-) I wanted exactly that kind of elegant FORTHish answer you gave. I regard the non usability of REVECTOR as a temporary inconvenience and look forward to the coming solution.
I'm not sure if SPLAT questions work here, but ... I am trying to see if my I2C device is working. This device is odd in that it uses clock stretching.
When I run a cog with some Tachyon v3 code to read a register, it seems to work, but the results are garbage (why I'm testing it). It can run for as long as I want with no freezes.
I have SPLAT set up, and it seems to be working. But when I try to run SPLAT with my I2C cog running, the cog freezes within 10 seconds, presumably in the clock stretching portion of the code where it waits for the external device to release SCL.
Does SPLAT interfere with the operation of any of the pin states?
Do I have to identify pins that the prop are using as inputs & as outputs?
LONG BNO_loop
LONG BNO_result
LONG BNO_count
24 LONGS BNO_STACK
pub COG_Bid ( -- )
BNO055_START
0 BNO_loop !
0 BNO_count !
BEGIN
BNO_loop @ 0=
IF
B_id ********************* this is the I2C read register routine
BNO_result !
BNO_count ++
100 ms
THEN
AGAIN
;
pub START_BidCOG ( -- )
0 BNO_loop !
' COG_Bid TASK? RUN
;
pub TOGGLE_BidCOG ( -- )
BNO_loop @ 0= IF 1 ELSE 0 THEN BNO_loop ! ;
I'm not sure if SPLAT questions work here, but ... I am trying to see if my I2C device is working. This device is odd in that it uses clock stretching.
When I run a cog with some Tachyon v3 code to read a register, it seems to work, but the results are garbage (why I'm testing it). It can run for as long as I want with no freezes.
I have SPLAT set up, and it seems to be working. But when I try to run SPLAT with my I2C cog running, the cog freezes within 10 seconds, presumably in the clock stretching portion of the code where it waits for the external device to release SCL.
Does SPLAT interfere with the operation of any of the pin states?
Do I have to identify pins that the prop are using as inputs & as outputs?
LONG BNO_loop
LONG BNO_result
LONG BNO_count
24 LONGS BNO_STACK
pub COG_Bid ( -- )
BNO055_START
0 BNO_loop !
0 BNO_count !
BEGIN
BNO_loop @ 0=
IF
B_id ********************* this is the I2C read register routine
BNO_result !
BNO_count ++
100 ms
THEN
AGAIN
;
pub START_BidCOG ( -- )
0 BNO_loop !
' COG_Bid TASK? RUN
;
pub TOGGLE_BidCOG ( -- )
BNO_loop @ 0= IF 1 ELSE 0 THEN BNO_loop ! ;
AFAIR SPLAT only reads pins so should never interfere with your program.
EDIT: just checked - I think the culprit might be PINLOAD which checks for pullup/-down and
pulses the pins - this is called at every refresh ;-)
and without REVECTOR I see no simple way except going into the source and replacing PINLOAD with a dummy word.
I was wondering about your:
pub TOGGLE_BidCOG ( -- )
BNO_loop @ 0= IF 1 ELSE 0 THEN BNO_loop ! ;
while you want to toggle it could have been changed already ...
at least I would:
pub TOGGLE_BidCOG ( -- )
BNO_loop @ 0= IF 1 BNO_loop ! THEN ;
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. Unlike full-duplex which is limited in baud rate which also increases jitter and possible errors, the high-speed serial driver operates in automatic half-duplex mode. Most communications with a PC is essentially half-duplex anyway, the PC sends a command then waits for a response, that's half-duplex. I do a lot of RS-485 at megabaud speeds, that's half-duplex. (Tested to 5M baud so far).
This driver can accept any receive buffer size and it doesn't have to be a binary multiple either. The transmitter though uses a single word buffer that blocks until the driver has read the character, then clears it while it is still transmitting, this is the way a basic hardware UART works. The reason for the blocking buffer is simply that big transmit buffers are usually not needed nor desired in embedded work. You transmit a command and you still have to wait for a response, so you have to wait for it to be transmitted. The other thing is that Tachyon's console is unbuffered bit-banged but because it is capable of running at megabaud rates you end up with a big saving in that bit-banging a character at high-speeds is faster than trying to buffer which if the buffer was full it would block anyway.
BTW, these are called "ROMS" because they don't take up any hub space but are copied into higher EEPROM as ROM images that can be loaded into cogs as required. One of these ROMs is F32 and there are others of course.
Here's an example of how to use the "HSUART" ROM. There are two parameter tables show, one for RS485 and one for "RS232".
{ HIGH SPEED UART ROM DEMONSTRATION }
--- set size of rx buffer
64 == rxsz
rxsz 4+ BYTES rxrd
rxrd 2+ == rxwr
rxwr 2+ == rxbuf
WORD txbuf
14 == TR
15 == TE
TABLE 485pars
TR MASK , --- receive pin mask
TR MASK , --- transmit pin mask (shared)
TE MASK , --- transmit enable (if RS485)
0 , --- options
CLKFREQ ppbaud / , --- baud clock count
rxbuf , --- pointer to rx buffer
64 , --- rx buffer size (any arbitrary number)
txbuf , --- single word transmit buffer
0 == RXD
1 == TXD
TABLE 232pars
RXD MASK ,
TXD MASK ,
0 , 0 ,
CLKFREQ 921600 / , --- 921600 baud operation
rxbuf , 64 , txbuf ,
--- startup HSUART in cog 4
485pars 4 " HSUART " LOADCOG
--- to send a character
pub TRANSMIT ( dat -- ) BEGIN txbuf W@ 0= UNTIL $100 OR txbuf W! ;
--- to read a character (non-blocking, returns with 0 if empty)
pub RECEIVE ( -- dat )
rxrd W@ rxwr W@ <>
IF rxrd W@ DUP rxbuf + C@ ( $100 OR ) SWAP 1+ rxsz MOD rxrd W!
ELSE 0
THEN
;
Comments
Either use an area away from code memory or just preallocate by using "4 LONGS myruntime" assuming that myruntime is the start address of var1 etc.
Have a look at EASYFILE for an example of how ORG and DS is used. Here's a snippet:
plus 4 more longs to access with var1 .. var4
if you do not need the LONG myruntime itself, then just do this.
myruntime is now a synonym for var1 and also a 4 LONG buffer which gets allocated,
whereas ORG and DS do not allocate space themselves
AND this is kind of a struct, but you can only have 1 instance of it.
If you need multiple instances you can use the base address of the buffer area for a
specific instance and use the DS defined constants as relative offsets into it - if you use 0 as the ORG base.
alignment can be critical !!! if you mix BYTE / WORD / LONG
Is this normal?
BTW : I don't have an RTC, should I disable this module?
Cheers!
I have basically ignored the junk but I decided to go on a hunt as I have had some ??? warnings too. Turned out that there were a few things I fixed up although none of them serious.
As for the RTC module I would leave it in as it always provides a soft RTC as a default which is suitable for being synced from a network master for instance. If you plug in a real RTC later you can set it as the default without having to load any software which btw works with a wide variety of various I2C RTC chips.
Back to ROMS ... I don't use them now, but I thought that the splash screen was reporting some when I moved to v3. Now it reports "No ROMS". What would have changed to clobber the ROMS?
Cheers!
Don't forget you can use a Prop loaded with SPLAT as a logic analyzer and if you can make your target run the IMU in another cog then you can run SPLAT on the target itself.
ROMS will only SAVEROMS if there is more than 32kB of EEPROM and normally it only ever SAVEROMS after a fresh kernel load followed by EXTEND. Performing a COLD when you have only loaded EXTEND and not much else then loading EXTEND again seems to clobber the ROMS too as it still detects remnants of them but this is easily fixed by erasing the hub area after the first SAVEROMS which is what I shall do.
I think the hardware is gone because I started to see intermittent readings that made no sense (always same value) and now that is all it returns. I'll check wiring under a scope today.
I am pouring over the code because the I2C acks are behaving oddly, and since I cobbled some of the clock-stretching bits, I am wondering if I screwed something up along the way. Grasping for straws perhaps, but hardware shouldn't fail like this.
Here's a link to the SPLAT document and you will find the code in the more\extras Dropbox folder.
The 32x32 LED matrix I have is using a MBI5024, which contains a 16-bit shift register and 16-bit LED driver. Each half of the matrix has three of these devices, so I imagine they are the 'work horses' of the matrix. The MBI5024 appears to be the same as the TLC59282 from Texas Instruments. Giving the TI data sheet a review.
Ok, here's the binary for the Tachyon kernel + EXTEND + EASYFILE which will work directly with any 5MHz or 10MHz Prop with a minimum of 32kB EEPROM. You can specify your own SD card pins by typing in your pin configuration, perhaps checking it with "ls" to list the files, and then BACKUP to lock it into EEPROM.
Dropbox
For instance my test board has this pin configuration:
P25 = CLK
P26 = MOSI (SD DATA IN)
P27 = MISO (SD DATA OUT)
P24 = CS (no pullup)
Enter in this format with an ampersand prefix with the pin numbers separated by a decimal point and don't forget that you need at least one space between Forth words, that is the number and SDPINS. Check that it works for your board with "ls" and then BACKUP.
The binary only has about 1k free which doesn't seem much but a lot gets done in that space although if you have a 64kB EEPROM or more you should run COMPACT, wait for that to finish, then BACKUP which gives you around 9k free (stacks of room for Tachyon!).
If you only have a 32k EEPROM then you could run RECLAIM to reclaim private headers that are no longer required which frees up about another 1k or more.
Default Tachyon session is 115200/8N1 and I prefer minicom for Linux or TeraTerm for WIndows.
I'm getting forward with my pc/tachyon connection.
What was the intention to limit telnet, ftp and http by a timeout of 5 mins?
Of course I could disable it in source but should I do so? I don't want to change within EASYFILE.FTH to avoid drifting away from the main trunk.
regards, proplem
and this was to release the ports for other players after a while
you can extend the timeout without touching the source or this should disable it completely
If Peter used Git, it would be easy for you to just change EASYFILE.FTH and have it automatically merge your changes with his changes whenever he changed anything.
Hi MJB, this is very elegant. Even your post about DS and ORG a few days ago was very helpful to me - thanks a lot.
@electrodude many would appreciate using git, but who has the time to drive this and provide an environment Peter feels comfortable with?
version info:
I do
and this throws
It's not urgent but I'd like to use REVECTOR .TIMERS and so on which are IFDEF EXPLORER ed.
edit:
without CREATE EXPLORER pasting EXTEND.FTH is successful and copy and pasting .TIMERS manually works also. Hmm.
So you can only revector if you have a vector but many high level functions in V3, even half-way through EXTEND were already direct calls that never used a vector. V4 does not have any vector table at all but it is possible to do something similar with any high level word by replacing the first word code with a jump code.
I will take a look at the EXPLORER include flags to make sure they are including the timers properly and update that.
As you can probably guess, once I have V4 up and running then that will be the mainstream version that will run faster and use less memory overall so that I can add even more functionality to Tachyon.
you are right I came into trouble with REVECTORing although I was happy about MJB's answer. Though you have seen this trouble I'm happy I know a solution will come.
I was impressed to see your V4 activity and I would like to encourage you to do some additional changes
- please remove whitespace in file and folder names
- there are some files with utf-16 characters which lead to problems diffing them with older versions ("binary files differ")
To explain this:
I'm using gnu make to build a kernel which I'm quite successful with but I always have issues with filenames with whitespace inside which cost a lot of time, time which is lost for tachyoning.
If you consider to do this I could create a list of file names and files to be changed. I'm currently online.
Tachyon is moving so fast that you can not take for granted, that things that worked a while ago are still working ...
having a kind of REVECTOR to be able ro redefine words which are already in use is a good thing ...
sorting the dictionary for binary search would lose the sequence information,
which is used in rewinding with FORGET ??
and would create unpredictable results for ??
Sure, you can play and create new words with the same names as old ones, forget them, etc, no problems. Once you have tested all that out and no longer need that "sequence" or the ability to forget then you have the option of moving them to EEPROM to free up some more code memory.
So in practical terms, once again there are no restrictions. Remember, just like the EEPROM dictionary now, it is a hybrid dictionary with new entries always building down in hub RAM as normal.
ok ok - I will 'buy' V4 ;-)
thanks
Hi MJB, you are beschäming me :-) I wanted exactly that kind of elegant FORTHish answer you gave. I regard the non usability of REVECTOR as a temporary inconvenience and look forward to the coming solution.
Bye Bye, proplem
When I run a cog with some Tachyon v3 code to read a register, it seems to work, but the results are garbage (why I'm testing it). It can run for as long as I want with no freezes.
I have SPLAT set up, and it seems to be working. But when I try to run SPLAT with my I2C cog running, the cog freezes within 10 seconds, presumably in the clock stretching portion of the code where it waits for the external device to release SCL.
Does SPLAT interfere with the operation of any of the pin states?
Do I have to identify pins that the prop are using as inputs & as outputs?
AFAIR SPLAT only reads pins so should never interfere with your program.
EDIT: just checked - I think the culprit might be PINLOAD which checks for pullup/-down and
pulses the pins - this is called at every refresh ;-)
and without REVECTOR I see no simple way except going into the source and replacing PINLOAD with a dummy word.
I was wondering about your: while you want to toggle it could have been changed already ...
at least I would:
My toggle routine lets me turn the I2C activity on and off, so it has to be able to switch it from 0->1 and 1->0. I'm sure there are better ways ...
Cheers!
It's simply some useful I/O pin information that is presented so we know whether that pin is an input or output and whether it has pull-up/down.
This driver can accept any receive buffer size and it doesn't have to be a binary multiple either. The transmitter though uses a single word buffer that blocks until the driver has read the character, then clears it while it is still transmitting, this is the way a basic hardware UART works. The reason for the blocking buffer is simply that big transmit buffers are usually not needed nor desired in embedded work. You transmit a command and you still have to wait for a response, so you have to wait for it to be transmitted. The other thing is that Tachyon's console is unbuffered bit-banged but because it is capable of running at megabaud rates you end up with a big saving in that bit-banging a character at high-speeds is faster than trying to buffer which if the buffer was full it would block anyway.
BTW, these are called "ROMS" because they don't take up any hub space but are copied into higher EEPROM as ROM images that can be loaded into cogs as required. One of these ROMs is F32 and there are others of course.
Here's an example of how to use the "HSUART" ROM. There are two parameter tables show, one for RS485 and one for "RS232".
{ HIGH SPEED UART ROM DEMONSTRATION } --- set size of rx buffer 64 == rxsz rxsz 4+ BYTES rxrd rxrd 2+ == rxwr rxwr 2+ == rxbuf WORD txbuf 14 == TR 15 == TE TABLE 485pars TR MASK , --- receive pin mask TR MASK , --- transmit pin mask (shared) TE MASK , --- transmit enable (if RS485) 0 , --- options CLKFREQ ppbaud / , --- baud clock count rxbuf , --- pointer to rx buffer 64 , --- rx buffer size (any arbitrary number) txbuf , --- single word transmit buffer 0 == RXD 1 == TXD TABLE 232pars RXD MASK , TXD MASK , 0 , 0 , CLKFREQ 921600 / , --- 921600 baud operation rxbuf , 64 , txbuf , --- startup HSUART in cog 4 485pars 4 " HSUART " LOADCOG --- to send a character pub TRANSMIT ( dat -- ) BEGIN txbuf W@ 0= UNTIL $100 OR txbuf W! ; --- to read a character (non-blocking, returns with 0 if empty) pub RECEIVE ( -- dat ) rxrd W@ rxwr W@ <> IF rxrd W@ DUP rxbuf + C@ ( $100 OR ) SWAP 1+ rxsz MOD rxrd W! ELSE 0 THEN ;