I asked Peter if he had any code for the ADC124S021 A2D on the Prop Activity Board. He looked over the specs and whipped me up a !ADC word and a ADC@ word. I took them and adapted the supporting display/scaling words.
Using a 9v battery with a pot as my variable supply and a good DMM I tested the whole 0-5 range and never had a discrepancy greater than 3 1/100ths. Most of the time the reading was 2 1/100ths lower than the DMM and zero was zero.
Here's the code. It replaces the ADC code in EXTEND.fth ... enjoy
I don't know how useful this might me to others but I wanted to detect ambient light levels on a board using just it's status indicator LED. On this board it just happens to be a tiny 0805 yellow amber LED tied to ground through a 1K resistor. An LED can generate a voltage at very minute current levels if you can shine a bright enough light into it. So therefore just by monitoring an LED as an input you will read a high on a grounded LED if there is a strong light shone into it. To make it more sensitive without any hardware modifications we simply pulse the LED briefly then float it. The capacitance of the circuit will mean that we can read back a high that will discharge quickly before reading a low but how fast it discharges depends upon the amount of ambient light. So by using the system counter and a WAITPNE instruction we can measure this interval and detect bright light and the level of it.
Here's the code in Tachyon Forth but it should be very easy to write in Spin or PASM etc.
[FONT=courier new][COLOR=#000000]\ Measure ambient light using LED (grounded).[/COLOR]
[/FONT]
[FONT=courier new][COLOR=#000000]\ Pulse the LED briefly to bias it, float it, then read back how long it takes to turn off[/COLOR][/FONT]
[FONT=courier new][COLOR=#000000]pub LED@ ( pin -- val )[/COLOR][/FONT]
[FONT=courier new][COLOR=#000000] MASK DUP OUTSET DUP INPUTS CNT@ SWAP WAITPNE CNT@ SWAP -[/COLOR][/FONT]
[FONT=courier new][COLOR=#000000] ;[/COLOR][/FONT]
[FONT=courier new]
[/FONT][FONT=courier new][COLOR=#000000]\ Poll the LED for ambient light and when detected then just flash the same LED [/COLOR][/FONT]
[FONT=courier new][COLOR=#000000]pub DEMO[/COLOR][/FONT]
[FONT=courier new][COLOR=#000000] $1000 \ init a black level (much higher than any normal reading)[/COLOR][/FONT]
[FONT=courier new][COLOR=#000000] BEGIN [/COLOR][/FONT]
[FONT=courier new][COLOR=#000000] #50 ms #P3 LED@ DUP 4 SHR CR FOR "*" EMIT NEXT \ Simple text graph of ambient light level[/COLOR][/FONT]
[FONT=courier new][COLOR=#000000] SWAP OVER MIN SWAP OVER $20 + > \ Update black level and look for anything above noise level[/COLOR][/FONT] ($20)
[FONT=courier new][COLOR=#000000] IF #P3 PINSET THEN \ Flash the LED back to indicate light detected [/COLOR][/FONT]
[FONT=courier new][COLOR=#000000] AGAIN[/COLOR][/FONT]
[FONT=courier new][COLOR=#000000] ; [/COLOR][/FONT]
[FONT=courier new]
[/FONT]
I have an application where my Prop is part of another board and only has 20ma allocated for it so I need to observe this. So I've added some clock mode instructions as well as COGSTOP and by stopping 6 cogs and still running the serial RX cog and the Tachyon console the current drops down to 28ma. If I execute a 2 CLK instruction (0=x1 1=x2 2=x4 3=x8 4=x16) to take my 10MHz crystal down to x4 XTAL mode the current drops to 15ma, well within the allocation. So I tried a couple of other modes too and these are the results:
CRYSTAL
MODE
FREQ COGS
CURRENT
TACHYON CODE
10MHz
XTAL8
80MHz
8
65ma
10MHz
XTAL8
80MHz
2
28ma
STANDBY
10MHz
XTAL4
40MHz
2
15ma
STANDBY 2 CLK
10MHz
XTAL2
20MHz
2
8.4ma
STANDBY 1 CLK
10MHz
XTAL1
10MHz
2
5.2ma
STANDBY 0 CLK
10MHz
XTAL1
10MHz
8
9.8ma
0 CLK
RCFAST
~!2MHz
8
9.2ma
RCFAST
RCFAST
~12MHz
2
2.2ma
STANDBY RCFAST
RCSLOW
~20kHz
8
215ua
RCSLOW
RCSLOW
~20kHz
2
205ua
STANDBY RCSLOW
RCSLOW
~20kHz
2
130ua*
1 1 TEMP! STANDBY RCSLOW
BTW, the hardware configuration is a AT30TS750 I2C temperature sensor, a 24LC512 EEPROM and a W25Q80 SPI Flash. The 3.3V regulator quiescent current accounts for around 50ua.
*EDIT: Added figure for putting temperature sensor into standby.
EDIT: Noting how WAITCNT (used by ms) saves power I have added a 32ms wait within the IDLE task loop - this reduces normal power down from 65ma to 23ma (CONSOLE,TIMING, and SERIAL cogs running)
I*wrote some sample code in ARDUINO for the Innovations ID series RFID reader several years ago and even after all this time I still get queries and it still attracts 40-60 downloads a month.
I figured it was time to do it in Tachyon. I played with it a bit a couple months back with poor results. I was using SERIN and trying to do some of the parsing on the fly. I was spinning my wheels ... so I put it aside. In the interim I pondered some advice that Peter had given me about the RTC. It went something like "... dump all the RTC registers to RAM ... THEN ... process the data." I scrapped 90% of what I had done and concentrated on getting 16 bytes from RFID chip to RFID reader to Prop Hub RAM ... accurately! I got that right on the first try so all that was left was support, display, etc words.
One thing that you need to understand is that a given family of RFID tags, in this case the EM4000 used by Innovations ID series and the Parallax 28140/28340/28440 from Joe Grand has a fixed format for its ID number, BUT the output of each reader, while containing the ID in recognizable form may vary in its START//STOP bytes, may or may not have a checksum, etc
16 BYTES TOTAL
STX (0x02) - Start Transmission
Data 10 ASCII-HEX characters "0"-"9"/"A"-"F"
CHECKSUM - break data to five 2 byte pairs each rep-
resenting a byte and XOR
CR (0x0D) - carriage return
LF (0x0A) - linefeed
ETX (0x03) - End Transmission
This is the Parallax readers
[START] [Data (10 ASCII)] [STOP]
12 BYTES TOTAL
START (0x0A) - linefeed
Data 10 ASCII-HEX characters "0"-"9"/"A"-"F"
STOP (0x0D) - carriage return
The code below is simple enough to adapt to any reader's output format. Then go and grab Peter's RFID.fth, which is setup for the Parallax reader, but has a more complete user application.
I seem to remember that some one had re-written SERIN to be non-blocking, that is you call SERIN with a time out parm. Can someone tell me where to look?
Peter, can you explain how the second parameter to ADO works when you have a "2 +LOOP" Look at my code word ID12cksum.
TACHYON
: RFID_ID12.fth ." RFID Innovations ID12 ToolKit - 20130908.1830" ;
BYTE IDbuf $20 ALLOT
#P9 CONSTANT IDpin
#9600 SERBAUD \ Innovations ID-12 runs at 9600,8,n,1
: IDpin! ( serpin -- ) ' IDpin 1+ ! ;
: decodehex ( ch -- val)
DUP "0" "9" WITHIN IF "0" - EXIT THEN
DUP "A" "F" WITHIN IF $37 - EXIT THEN
;
\ Read the RFID reader ... uses stock, unmodified SERIN. SERIN
\ will block anything while waiting for each of 16 bytes
\ received bytes directly placed in buffer
: ID@ ( bufadr -- ) #16 ADO IDpin SERIN I C! LOOP ;
\ EM4000 series RFID chips send 10 HEX digits which must be
\ paired to make 5 bytes which have to be XORed for the
\ checksum
: MAKEHEX ( addr -- hexlong )
DUP C@ decodehex $10 *
SWAP 1+ C@ decodehex +
;
\ 0 XOR number = number ... so we 'prime' the loop with 0
\ watch out for ADO in the "2 +LOOP" mode. 9 doesn't yield
\ 9 iterations, rather 5 .... I = 1, 3, 5, 7, 9
: ID12cksum ( bufadr -- chksum )
0 SWAP 1+ 9 ADO I MAKEHEX XOR 2 +LOOP ;
: .ID12 ( bufadr -- )
." - ID read [ " 1+ 9 ADO I MAKEHEX .BYTE SPACE 2 +LOOP "]" EMIT ;
: ID12cksumValid? ( bufadr -- flag )
DUP ID12cksum SWAP #11 + MAKEHEX = ;
\ Shortcuts and example uses
: IDB ( -- ) IDbuf $20 DUMP ; \ dump i/o buffer
: IDD ( -- ) IDbuf ID12cksum ; \ compute checksum of ID
: IDI ( -- ) IDbuf ID@ ; \ wait for 16 byte ID strong
: IDQ ( -- ) \ SIMPLISTIC APP - get ID, validate the checksum, display
CR CR #9600 SERBAUD
BEGIN
IDbuf DUP DUP ID@ CR .DATES SPACE .TIME SPACE .ID12 SPACE
ID12cksumValid? IF ." -< VALID >- " ELSE ." **Invalid** " THEN ." Checksum " CR
KEY? UNTIL
DROP
;
END
The DSRTC code I posted had several non stack-neutral words. Most of them got away without mucking things up, but the two most heavily used display words were fouling up anytime they were in a sequence of words where a DUP was being used to carry data or an address forward. The short version is, I goofed and I found and fixed the problem.
This code has been running on one of my Propeller Platform Through-Hole boards with the DS3231 backed up by a CR2032 lithium battery and also on a Prop Activity Board backed up by a .3F supercap charge from the 3.3 supply lines via a 1N4148 diode. Both boards are powered from about 0900 to 0100 and from 0100 to 0900 the DS3231s are maintaining via their respective backup sources. In the well over a week of this testing neither RTC differs from the NNTP set time on my iMac by more than a second. Since the discrepancy does not creep I am inclined to think its mostly due to my Parkinson impaired reflexes when I whacked the "Enter" key when I set it 10 days ago!
All in all the DS3231 looks to be an excellent all around choice for RTC
PROs
- operates on 1.8 to 5.5 volts
- pullups on SDA/SCL can be different voltage than Vcc
- built in TXCO resonator
- 5 ppm accuracy
CONs
- $8+ in small quantities
The code can still be used, altering a pair of CONSTANTs, either by the DS1307 or DS3231
I've just received a Propeller C3 and would like to know if there is any Forth code that specifically supports it's various features? Having been away from Forth for a couple of decades, I'm not too sure of myself as far as writing it from scratch!
I've just received a Propeller C3 and would like to know if there is any Forth code that specifically supports it's various features? Having been away from Forth for a couple of decades, I'm not too sure of myself as far as writing it from scratch!
It doesn't look like anything special in terms of I/O and at the most they would just require C3 pin definitions. What is missing at present is any sort of built-in VGA which although present in V1 was removed die to the memory requirements, but then again it was 512x384 bitmap and there is probably no reason why we can't build in a nice little text VGA object that can be activated easily. Me feeling is that the driver should be somewhat runtime configurable as to resolution, text or graphics mode etc. With Tachyon being fast enough to handle the high level requirements of a VGA driver then the PASM code footprint for the video display cog would be minimal.
I noticed that they for some reason some designers insist on using physical PS/2 connectors although real PS/2 keyboard and mice are hard to come by ($$) although PS/2 compatible USB HIDs are far more common, which is why I just use USB connectors and dispense with any bulky wiring adapters. Besides, it gives you an option to implement USB drivers if necessary.
Is there anything in particular that you would like to do with this board and Forth?
I noticed that they for some reason some designers insist on using physical PS/2 connectors although real PS/2 keyboard and mice are hard to come by ($$) although PS/2 compatible USB HIDs are far more common, which is why I just use USB connectors and dispense with any bulky wiring adapters. Besides, it gives you an option to implement USB drivers if necessary.
you mean that many/most modern mice/kbd support PS/2 protocol on their USB connector and detect automatically wheather they are connected to UB or PS/2 port.
So the option is - cheap new mouse/kbd at micro with convenient USB connector AND simple PS/2 protocol.
The connection is like this: http://pinouts.ru/InputCables/usb_ps2_mouse_pinout.shtml
Connecting USB-mouse to PS/2 connector of computer. It works only with device which supports both interfaces (USB & PS/2).
USB Pin
Name
USB Pin
Number
Direction
Usb Color
PS/2 mouse controller Pin
Number
PS/2 mouse controller Pin
Name
Description
PS/2 Color
VDC +5V
1
<--
Red
4
VDC +5V
Red
Data-
2
-?-
White
1
Data
White
Data+
3
-?-
Green
5
Clock
Brown
Ground
4
-?-
Black
3
Ground
Black
Very nice to have one more empty USB connector.
It's good practice to pull up data/clock lines with some resistors of 10k or so. Especially when connecting to newer motherboards. In some cases signal has levels between 1.5 and 2.5 volts, and mouse don't work. Pulling up helps in that situations and doesn't harm if unnecessary.
[/QUOTE]Is there anything in particular that you would like to do with this board and Forth?[/QUOTE]
Hi Peter,
I was thinking more of using the C3 as a small development platform. Another thing I was wondering about regarding Tachyon is the apparent absence of MARKER, FORGET, etc. Are the definitions for these words available? They're certainly an important part of the code-development cycle.
you mean that many/most modern mice/kbd support PS/2 protocol on their USB connector and detect automatically wheather they are connected to UB or PS/2 port.
So the option is - cheap new mouse/kbd at micro with convenient USB connector AND simple PS/2 protocol.
The connection is like this: http://pinouts.ru/InputCables/usb_ps2_mouse_pinout.shtml
Connecting USB-mouse to PS/2 connector of computer. It works only with device which supports both interfaces (USB & PS/2).
USB Pin
Name
USB Pin
Number
Direction
Usb Color
PS/2 mouse controller Pin
Number
PS/2 mouse controller Pin
Name
Description
PS/2 Color
VDC +5V
1
<--
Red
4
VDC +5V
Red
Data-
2
-?-
White
1
Data
White
Data+
3
-?-
Green
5
Clock
Brown
Ground
4
-?-
Black
3
Ground
Black
Very nice to have one more empty USB connector.
It's good practice to pull up data/clock lines with some resistors of 10k or so. Especially when connecting to newer motherboards. In some cases signal has levels between 1.5 and 2.5 volts, and mouse don't work. Pulling up helps in that situations and doesn't harm if unnecessary.
Yes, the devices that are compatible with either usually come with a USB to PS/2 adaptor so that you can plug your USB HID into a PS/2 socket. That's handy for an ancient motherboard but for new designs it makes more sense to plug the device directly into a USB socket without the unwieldy adaptor which is just a dumb gender-bender. For PS/2 mode you need pull-ups but if you want to implement USB drivers then you should pull the data lines down for slow-speed mode. I use tiny SPDT solder pads about the size of an 0805 so that I just blob on my selection with a warm iron although you could tie the pull-up common to an I/O to make it software selectable.
Is there anything in particular that you would like to do with this board and Forth?[/QUOTE]
Hi Peter,
I was thinking more of using the C3 as a small development platform. Another thing I was wondering about regarding Tachyon is the apparent absence of MARKER, FORGET, etc. Are the definitions for these words available? They're certainly an important part of the code-development cycle.
Regards,
Michael
K6MLE[/QUOTE]
Let's not forget that there are many standard Forth words that are really part of a PC standard yet the vast majority of Forth uses are embedded and non-standard and have totally different goals and resources. FORGET is easy enough to implement with a standard Forth and other Forths I have written but I haven't needed it for development at all as normally I just perform a COLD start and load the source back again. I do concede that this model is a bit of a pain sometimes when I have many modules to reload so for systems that have 64K of EEPROM I just hold a stable image in the top 32K ready to RESTORE.
That said I could still implement a FORGET but it might have to go through each word to deallocate the code, dictionary, and vector space individually to be on the safe side. The way I would use FORGET is not at an interactive testing level where it is just as easy to just write a new word but when it comes to reloading a module such as SDCARD.fth etc where I would include the word FORGET at the start of the file. Any failure to find the word would simply issue a warning and continue.
Many have been asking for a FORGET word which I just keep forgetting to implement but now I have remembered to forget! This is in EXTEND.fth and performs a decremental forget operation ensuring that the correct deallocation is performed on the code, dictionary, and vector space. So don't forget to use it as I include it in the header of my modules to automatically forget that module in case it is already loaded. There is one caveat with any forget operation and that is to ensure that any code that is running in another cog or under keypoll is stopped before forgetting. Perhaps I might just add this to FORGET just in case.
I will probably also release some updated drivers soon including the unreleased FAT32 and WIZnet W5200 drivers which also includes the network servers for TELNET, FTP, and HTTP. The FAT32 is aimed primarily at datalogging where I like to preset the card beforehand with fixed file sizes and even fixed line sizes (128 bytes/line). At startup I just find the last file and binary search through this until I find the last non-blank line and set a virtual memory pointer to this in RAM without changing anything on the card. Since these files are not dynamically allocated or grown then we have no need for writing to the cluster file or worrying about fragmentation. When I save data to the card I only have to write into a preset and known position so it is not possible to corrupt the card (even with removal during writes) nor does the card suffer from premature wear because of FAT32 file size updates etc.
My FTP can decide to strip trailing whitepsace when uploading a file but essentially the SD card is treated as flat memory for the first 4GB (more than enough) without regard to fragmentation (since it doesn't exist in this controlled environment). With the virtual memory access words the first 4GB is treated as virtual memory where file handles are actually sector addresses which translate in virtual memory address with a 9 SHL operation. There are of course a lot of words specifically designed for interactive CLI operation such as DIR, ls, cat, FOPEN <name>, etc and FLOAD <name> to load a source file. But don't expect a full FAT32 driver, at least not at present, since it's not my priority and besides FAT32 is horrible, compatible, but horrible especially for SD cards and embedded work. I will add functionality for having several files open though as I only need a minimum of one sector buffer and directory entry per file.
Tachyon is not a Forth for learning as some of you have found out , it's a Forth for getting things done with the Propeller, and I've been doing a lot of products in the past year with Forth embedded in them. I even did a little 1" module used in gripper arms of picker robots and boy was I glad I did it with the Prop and TF as it made it so easy to debug and fine tune this on the factory floor while the production line was running and people breathing down my neck. I think the engineers there thought I was running Linux or something on it because I could interact with it at a high level via a terminal and do all sorts of changes on the spot as well as provide realtime debug information as needed (within moments).
Here's a method from the FAT32 module for opening files.
[SIZE=3][FONT=courier new]'' Fetch the address of the currently open file
[/FONT][/SIZE]
[SIZE=3][FONT=courier new]pub [B]FILE@[/B] ( -- xadr ) file @ 9 SHL ;
[/FONT][/SIZE]
[SIZE=3][FONT=courier new]
[/FONT][/SIZE][SIZE=3][FONT=courier new]'' Open the file with the name and return with it's sector (0=fail)
[/FONT][/SIZE]
[SIZE=3][FONT=courier new]pub [B]FOPEN$[/B] ( namestr -- sector )[/FONT][/SIZE]
[SIZE=3][FONT=courier new] >F8.3 DIR? DUP \ Convert to 8.3 format and search directory[/FONT][/SIZE]
[SIZE=3][FONT=courier new] IF \ found an entry (virtual address)[/FONT][/SIZE]
[SIZE=3][FONT=courier new] DUP diradr ! \ save address of directory entry[/FONT][/SIZE]
[SIZE=3][FONT=courier new] XADR DUP dirbuf BL CMOVE \ map sector to hub RAM and copy directory entry to local buffer[/FONT][/SIZE]
[SIZE=3][FONT=courier new] CLUSTER@ CLUST>SECT \ fetch starting cluster of file and find file's start sector[/FONT][/SIZE]
[SIZE=3][FONT=courier new] DUP file ! \ save start sector of file [/FONT][/SIZE]
[SIZE=3][FONT=courier new] THEN[/FONT][/SIZE]
[SIZE=3][FONT=courier new] ;
[/FONT][/SIZE]
Interacting with it:
[FONT=courier new][B]FOPEN EXTEND.FTH[/B]...opened at 00024440 ok
[B]FILE@ 40 XDUMP[/B]
0488_8000: 54 41 43 48 59 4F 4E 0A 7B 20 45 58 54 45 4E 44 TACHYON.{ EXTEND
0488_8010: 2E 66 74 68 20 7D 0A 0A 70 72 69 20 45 58 54 45 .fth }..pri EXTE
0488_8020: 4E 44 2E 66 74 68 20 20 20 20 2E 22 20 50 72 69 ND.fth ." Pri
0488_8030: 6D 61 72 79 20 65 78 74 65 6E 73 69 6F 6E 73 20 mary extensions ok
[/FONT]
Many have been asking for a FORGET word which I just keep forgetting to implement but now I have remembered to forget! This is in EXTEND.fth and performs a decremental forget operation ensuring that the correct deallocation is performed on the code, dictionary, and vector space. So don't forget to use it as I include it in the header of my modules to automatically forget that module in case it is already loaded. There is one caveat with any forget operation and that is to ensure that any code that is running in another cog or under keypoll is stopped before forgetting. Perhaps I might just add this to FORGET just in case.
I will probably also release some updated drivers soon including the unreleased FAT32 and WIZnet W5200 drivers which also includes the network servers for TELNET, FTP, and HTTP. The FAT32 is aimed primarily at datalogging where I like to preset the card beforehand with fixed file sizes and even fixed line sizes (128 bytes/line). At startup I just find the last file and binary search through this until I find the last non-blank line and set a virtual memory pointer to this in RAM without changing anything on the card. Since these files are not dynamically allocated or grown then we have no need for writing to the cluster file or worrying about fragmentation. When I save data to the card I only have to write into a preset and known position so it is not possible to corrupt the card (even with removal during writes) nor does the card suffer from premature wear because of FAT32 file size updates etc.
.
.
.
.
[/FONT][/code]
This will make for a wonderful Xmas season, thanks in advance!
Tachyon is not a Forth for learning as some of you have found out , it's a Forth for getting things done with the Propeller, and I've been doing a lot of products in the past year with Forth embedded in them. I even did a little 1" module used in gripper arms of picker robots and boy was I glad I did it with the Prop and TF as it made it so easy to debug and fine tune this on the factory floor while the production line was running and people breathing down my neck. I think the engineers there thought I was running Linux or something on it because I could interact with it at a high level via a terminal and do all sorts of changes on the spot as well as provide realtime debug information as needed (within moments).
Cool! There is something to be said for being able to work that way.
I didn't have my Prop board with me and gave GEAR a try.
AND IT WORKED
yes, it took some time to boot up a standard Tachyon 2.1 image from Peters dropbox
but I think this can be made much faster by not running all COGs
AND by reducing the startup delay (to run the about 40 000 000 cycles it takes about half an hour -
so don't give up to early.
I used Gear V 9.10.26.7 dated 26. Oktober 2009, 12:31:00 - this is not the original version, but the extended one.
and I loaded the SerialIO.xml plugin, configured it to the correct baudrate and there you go.
Unfortunately I didn't find a way to suppress the autoecho, so typed characters get echoed twice
from the terminal and as usual from Tachyon itself.
EDIT: within serialIO.xml just comment out a few lines
I didn't have my Prop board with me and gave GEAR a try.
AND IT WORKED
yes, it took some time to boot up a standard Tachyon 2.1 image from Peters dropbox
but I think this can be made much faster by not running all COGs
AND by reducing the startup delay (to run the about 40 000 000 cycles it takes about half an hour -
so don't give up to early.
I used Gear V 9.10.26.7 dated 26. Oktober 2009, 12:31:00 - this is not the original version, but the extended one.
and I loaded the SerialIO.xml plugin, configured it to the correct baudrate and there you go.
Unfortunately I didn't find a way to suppress the autoecho, so typed characters get echoed twice
from the terminal and as usual from Tachyon itself.
EDIT: within serialIO.xml just comment out a few lines
And the you can set breakpoints in the cogs and watch whats is going on - at the PASM level ...
Why didn't I try this before ??
I've just updated Dropbox with a newer version of the kernel and extend. You will find the echo function can be turned off and on normally with "OFF ECHO" and "ON ECHO". Turning off the echo also suppresses the space character that is emitted after a line has been accepted.
There is no real need to have any startup delay if you are running Gear so you can just comment out the last line of this section.
[COLOR=#000000][FONT=Ubuntu Mono][B]TERMINAL[/B][/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] byte InitRP[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] byte XCALL,xInitStack[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] byte _WORD,00,50,XCALL,xms ' a little startup delay (also wait for serial cog)[/FONT][/COLOR]
[COLOR=#000000][FONT=Ubuntu Mono] [/FONT][/COLOR]
I've tweaked the FAT32 layer to handle multiple files, four in fact. The files are accessed as virtual memory rather than the traditional seek and read/write. At a later stage I will add FAT16 and more functions for FORMAT, DEL, MKDIR, etc
Once I've done a bit more testing within an application I will release these source files, probably within the week.
EDIT: This is just a simple (and inefficient) demo to show how we can copy one file into another - here we copy from file #1 to file #0.
FILE@ returns with the virtual address of the beginning of the currently selected file
FILE accepts a parameter to set the currently selected file
XC@ works just like a C@ except the address is a virtual 4GB address
XC! works the same but also flags the buffer as modified
FCLOSE is optional and just flushes any modified buffers and resets file pointers
[FONT=courier new][B]0 FILE[/B] ok
[B]FOPEN LOG0001.TXT[/B]...opened at 0000.3B28 ok
[B]1 FILE[/B] ok
[B]FOPEN EXTEND.FTH[/B]...opened at 0000.4B80 ok
ok
[B]0 #57915 ADO 1 FILE FILE@ I + XC@ 0 FILE FILE@ I + XC! LOOP[/B] ok
[B]0 FILE FILE@ 40 XDUMP[/B]
0076_5000: 54 41 43 48 59 4F 4E 0A 7B 20 45 58 54 45 4E 44 TACHYON.{ EXTEND
0076_5010: 2E 66 74 68 20 7D 0A 0A 70 72 69 20 45 58 54 45 .fth }..pri EXTE
0076_5020: 4E 44 2E 66 74 68 20 20 20 20 2E 22 20 50 72 69 ND.fth ." Pri
0076_5030: 6D 61 72 79 20 65 78 74 65 6E 73 69 6F 6E 73 20 mary extensions ok
[B]FCLOSE[/B] ok[/FONT]
I've updated a couple of files in Dropbox and the links pages and these include the current SDCARD and FAT virtual memory drivers. The links page now has sections so this will be updated some more yet.
There's also the W5200 driver but I haven't uploaded the network server layer yet as I am working on the glitches although I can telnet and ftp at present.
EDIT: The data stack will probably get an upgrade in the form of a hybrid with all the advantages of fixed positions for the first 4 items or so and a non-addressable push/pop overflow in hub memory.
As mentioned in the last post I have upgraded the kernel with a hybrid stack which keeps 4 levels internally in fixed positions using the seemingly cumbersome memory move method but now supplemented with an external stack beyond this. What this means is that Tachyon is not any slower for having an external stack as it is never referenced directly, it just exists as the overflow buffer. The Tachyon VM still directly references the top 4 items as if they were fixed registers which simplifies addressing and contributes to the speed and compactness of TF.
The downside of this is that each cog that runs a Tachyon VM needs an external stack allocated. By default the pointer to this stack is zero which effectively turns off writing to hub RAM on a push and confines the VM to a 4 level stack which in some cases may be all that it needs. However the idea is that a new task will set the stack pointer for it's cog just as the main console cog does at startup, another example of which is in EXTEND.FTH where TIMERTASK is started up at boot time. Here a timer stack is created for 12 levels and it passes this address to SP!
[FONT=courier new]TABLE timerstk #12 4 * ALLOT \ allot space for timer data stack
\ 118us for 8 empty timers
pri TIMERTASK
timerstk SP![/FONT]
New words added or updated are:
[FONT=courier new]WORD.....STACK..........PRONOUNCED AS.............DESCRIPTION
[B]!SP[/B] ( -- ) Init Stack Pointer Initialize the data stack (Note: this is now a native VM bytecode, part of the PASM kernel)
[B]SP![/B] ( addr -- ) Stack Pointer Store Store the address in the stack pointer - the stack builds up from here.
[B]DEPTH[/B] ( -- levels ) Depth Return with the depth of the data stack (not including the depth parameter itself)
[/FONT]
Since the stack is a fundamental part of the VM and it now operates a bit differently I have upgraded this source as V2.2 and I have placed all the new files in Dropbox. The webpage versions will have links updated or inserted into the links page.
Note: Popping an empty stack will not cause the SP to go negative (Stack Pointer base address - depth index) but it is now possible to overflow the stack, so beware.
Just a quick note to say that I jumped from V2.2 the other day to V2.3 which essentially added new opcodes for SPIWR and SPIRD which have their own I/O mask registers apart from RUNMOD modules. I have been able to squeeze these in thanks in part to the freeing up of room by removing most of the data stack except for 4 top items which are always accessed as fixed registers, and also in part due to optimizations to the SPI code. To get the most out of SPI without reverting to the counter I have a dedicated write and a dedicated read instruction which default to 8-bits although you can override this. The SPIWR will always shift the msbs from a long so you can chain 4 SPIWR instructions together to get it to shift 32-bits in one go. The SPIRD requires a stack input parameter which is normally set to zero but by chaining 4 SPIRD instructions together you can perform a 32-bit shift. There is also a SPIWRB for writing bytes without having to left justify first as this is faster in PASM and only takes one extra instruction.
The reason for the dedicated SPI instructions is so that I can run two sets of SPI devices easily and efficiently from the one cog and in this case it is the SDCARD using the RUNMOD loadable PASM modules and the WIZnet using the SPI instructions.
@Peter:
you placed the extended stack for the TERMINAL-COG fixed at $7720 with nothing above.
which gives a total stack of 60 longs - nothing to complain about.
and if need be can be made any size - great.
for other cog processes stack needs to be allocated manually as shown in new EXTEND.fth
TABLE timerstk #12 4 * ALLOT \ allot space for timer data stack
pri TIMERTASK
!SP ' init COG stack
timerstk SP! ' set external stack start, stack size is not set explicitly anywhere and not checked, so beware of stack overflows !!
@Peter:
you placed the extended stack for the TERMINAL-COG fixed at $7720 with nothing above.
which gives a total stack of 60 longs - nothing to complain about.
and if need be can be made any size - great.
for other cog processes stack needs to be allocated manually as shown in new EXTEND.fth
TABLE timerstk #12 4 * ALLOT \ allot space for timer data stack
pri TIMERTASK
!SP ' init COG stack
timerstk SP! ' set external stack start, stack size is not set explicitly anywhere and not checked, so beware of stack overflows !!
thanks a lot ...
It's fairly rare that I need a stack more than 12 levels deep but it's also good that it has plenty of room to move or if I have junk being left on the stack then I can still see what's happened. I can't see how I would use 32 levels though even though I have pushed some extra check numbers onto it and ran it through my FTP/TELNET stuff. I can see a real need to get that dictionary out of hub ram though and I've looked at it before and know how I will handle it by using a small unused area of the SD card for this as I only need one sector buffer at a time for dictionary searches with a cache for all the recent hits. But this is significant enough to become V3 although I will still allow for slow EEPROM, or fast SPI Flash to be used instead otherwise the default is as it is now. V3 will also make more use of the pri vs pub declaration so that it knows it can remove the pri heads from the dictionary when it encounters an END directive.
V3 will also make more use of the pri vs pub declaration so that it knows it can remove the pri heads from the dictionary when it encounters an END directive.
I think I saw a comment stating there could be multiple dictionaries searched one after the other.
Putting the pri headers in such a seperate dictionary would make it very easy to reset it on END.
Just reset the dict for the 'ephemeral' dictionary (taken from LISP garbage collection mechanisms ...), no searching, deleting, compacting required.
I think I saw a comment stating there could be multiple dictionaries searched one after the other.
Putting the pri headers in such a seperate dictionary would make it very easy to reset it on END.
Just reset the dict for the 'ephemeral' dictionary (taken from LISP garbage collection mechanisms ...), no searching, deleting, compacting required.
Well it may well be that assuming either SD card or SPI Flash is used that the source code would also be compiled from SD even if it is downloaded serially first as the card write routines can easily keep up with the high baud rates. Compiling from a files system means it's easy to have include directives and also it will compile as fast as it can rather than a serial download that has to have line delays because there is no handshaking. Perhaps I could even fetch the files from the PC via FTP, now that would be nice or simply copy the files across via FTP.
Yes, the pri headers could just be routed into their own dictionary which could be wiped after a load. Even though there is plenty of storage when you have an SD card there is still the inefficiency of searching a large dictionary so removing or ignoring the pri headers would still be advantageous. Of course it would also be possible to give each header a fixed amount of space, say 32 or 64 bytes each so that it would be possible to do simple compares on longs and skip to the next fixed length header without having to process the header any further in case of a mismatch. The longest name I have in the dictionary is 18 characters long so allowing the usual 4 extra bytes for count,code, and attributes that still leaves 28 characters if I use 32 bytes per entry.
with all those great extensions I just want to remind you that there are still small / minimal systems around with just PROP and 32kEEPROM.
So I would hate to see TACHYON following the Windows road and getting more and more resource hungry each version.
I am running it still on PPDB or P-DIP systems only.
with all those great extensions I just want to remind you that there are still small / minimal systems around with just PROP and 32kEEPROM.
So I would hate to see TACHYON following the Windows road and getting more and more resource hungry each version.
I am running it still on PPDB or P-DIP systems only.
Not to worry because it will always handle the minimal system but many of my designs have SD or even SPI Flash so it's a resource I would like to consume a bit more of so that I may have more hub RAM available at least. 32k is all there is and I don't believe in piling banked RAM or multiple Props together to achieve what I could do more efficiently with another type of CPU. But those CPUs are boring and transitory, barely staying around for a couple of years before they are hard to get. Big learning curves on their hardware and tools too. Prop ticks all the boxes.
I had no problem running it in GEAR, so maybe you have a bad download.
Did you check your crystal settings match those of the binary 10MHz PLL8x?
My system has 5MHz Pll16x so I did compile the .spin in BST and PropTool myself after changing those settings - all fine
Comments
Using a 9v battery with a pot as my variable supply and a good DMM I tested the whole 0-5 range and never had a discrepancy greater than 3 1/100ths. Most of the time the reading was 2 1/100ths lower than the DMM and zero was zero.
Here's the code. It replaces the ADC code in EXTEND.fth ... enjoy
cheers ... BBR
Here's the code in Tachyon Forth but it should be very easy to write in Spin or PASM etc.
CRYSTAL
MODE
FREQ
COGS
CURRENT
TACHYON CODE
10MHz
XTAL8
80MHz
8
65ma
10MHz
XTAL8
80MHz
2
28ma
STANDBY
10MHz
XTAL4
40MHz
2
15ma
STANDBY 2 CLK
10MHz
XTAL2
20MHz
2
8.4ma
STANDBY 1 CLK
10MHz
XTAL1
10MHz
2
5.2ma
STANDBY 0 CLK
10MHz
XTAL1
10MHz
8
9.8ma
0 CLK
RCFAST
~!2MHz
8
9.2ma
RCFAST
RCFAST
~12MHz
2
2.2ma
STANDBY RCFAST
RCSLOW
~20kHz
8
215ua
RCSLOW
RCSLOW
~20kHz
2
205ua
STANDBY RCSLOW
RCSLOW
~20kHz
2
130ua*
1 1 TEMP! STANDBY RCSLOW
BTW, the hardware configuration is a AT30TS750 I2C temperature sensor, a 24LC512 EEPROM and a W25Q80 SPI Flash. The 3.3V regulator quiescent current accounts for around 50ua.
*EDIT: Added figure for putting temperature sensor into standby.
EDIT: Noting how WAITCNT (used by ms) saves power I have added a 32ms wait within the IDLE task loop - this reduces normal power down from 65ma to 23ma (CONSOLE,TIMING, and SERIAL cogs running)
For both posts..
Massimo
I figured it was time to do it in Tachyon. I played with it a bit a couple months back with poor results. I was using SERIN and trying to do some of the parsing on the fly. I was spinning my wheels ... so I put it aside. In the interim I pondered some advice that Peter had given me about the RTC. It went something like "... dump all the RTC registers to RAM ... THEN ... process the data." I scrapped 90% of what I had done and concentrated on getting 16 bytes from RFID chip to RFID reader to Prop Hub RAM ... accurately! I got that right on the first try so all that was left was support, display, etc words.
One thing that you need to understand is that a given family of RFID tags, in this case the EM4000 used by Innovations ID series and the Parallax 28140/28340/28440 from Joe Grand has a fixed format for its ID number, BUT the output of each reader, while containing the ID in recognizable form may vary in its START//STOP bytes, may or may not have a checksum, etc
This is the layout of the Innovations ID Series
[STX] [Data (10 ASCII)] [CHECKSUM (2 ASCII)] [CR] [LF] [ETX]
16 BYTES TOTAL
STX (0x02) - Start Transmission
Data 10 ASCII-HEX characters "0"-"9"/"A"-"F"
CHECKSUM - break data to five 2 byte pairs each rep-
resenting a byte and XOR
CR (0x0D) - carriage return
LF (0x0A) - linefeed
ETX (0x03) - End Transmission
This is the Parallax readers
[START] [Data (10 ASCII)] [STOP]
12 BYTES TOTAL
START (0x0A) - linefeed
Data 10 ASCII-HEX characters "0"-"9"/"A"-"F"
STOP (0x0D) - carriage return
The code below is simple enough to adapt to any reader's output format. Then go and grab Peter's RFID.fth, which is setup for the Parallax reader, but has a more complete user application.
I seem to remember that some one had re-written SERIN to be non-blocking, that is you call SERIN with a time out parm. Can someone tell me where to look?
Peter, can you explain how the second parameter to ADO works when you have a "2 +LOOP" Look at my code word ID12cksum.
This code has been running on one of my Propeller Platform Through-Hole boards with the DS3231 backed up by a CR2032 lithium battery and also on a Prop Activity Board backed up by a .3F supercap charge from the 3.3 supply lines via a 1N4148 diode. Both boards are powered from about 0900 to 0100 and from 0100 to 0900 the DS3231s are maintaining via their respective backup sources. In the well over a week of this testing neither RTC differs from the NNTP set time on my iMac by more than a second. Since the discrepancy does not creep I am inclined to think its mostly due to my Parkinson impaired reflexes when I whacked the "Enter" key when I set it 10 days ago!
All in all the DS3231 looks to be an excellent all around choice for RTC
PROs
- operates on 1.8 to 5.5 volts
- pullups on SDA/SCL can be different voltage than Vcc
- built in TXCO resonator
- 5 ppm accuracy
CONs
- $8+ in small quantities
The code can still be used, altering a pair of CONSTANTs, either by the DS1307 or DS3231
I noticed that they for some reason some designers insist on using physical PS/2 connectors although real PS/2 keyboard and mice are hard to come by ($$) although PS/2 compatible USB HIDs are far more common, which is why I just use USB connectors and dispense with any bulky wiring adapters. Besides, it gives you an option to implement USB drivers if necessary.
Is there anything in particular that you would like to do with this board and Forth?
So the option is - cheap new mouse/kbd at micro with convenient USB connector AND simple PS/2 protocol.
The connection is like this:
http://pinouts.ru/InputCables/usb_ps2_mouse_pinout.shtml
Connecting USB-mouse to PS/2 connector of computer. It works only with device which supports both interfaces (USB & PS/2).
USB Pin
Name
USB Pin
Number
Direction
Usb Color
PS/2 mouse controller Pin
Number
PS/2 mouse controller Pin
Name
Description
PS/2 Color
VDC +5V
1
<--
Red
4
VDC +5V
Red
Data-
2
-?-
White
1
Data
White
Data+
3
-?-
Green
5
Clock
Brown
Ground
4
-?-
Black
3
Ground
Black
Very nice to have one more empty USB connector
It's good practice to pull up data/clock lines with some resistors of 10k or so. Especially when connecting to newer motherboards. In some cases signal has levels between 1.5 and 2.5 volts, and mouse don't work. Pulling up helps in that situations and doesn't harm if unnecessary.
Hi Peter,
I was thinking more of using the C3 as a small development platform. Another thing I was wondering about regarding Tachyon is the apparent absence of MARKER, FORGET, etc. Are the definitions for these words available? They're certainly an important part of the code-development cycle.
Regards,
Michael
K6MLE
Yes, the devices that are compatible with either usually come with a USB to PS/2 adaptor so that you can plug your USB HID into a PS/2 socket. That's handy for an ancient motherboard but for new designs it makes more sense to plug the device directly into a USB socket without the unwieldy adaptor which is just a dumb gender-bender. For PS/2 mode you need pull-ups but if you want to implement USB drivers then you should pull the data lines down for slow-speed mode. I use tiny SPDT solder pads about the size of an 0805 so that I just blob on my selection with a warm iron although you could tie the pull-up common to an I/O to make it software selectable.
Hi Peter,
I was thinking more of using the C3 as a small development platform. Another thing I was wondering about regarding Tachyon is the apparent absence of MARKER, FORGET, etc. Are the definitions for these words available? They're certainly an important part of the code-development cycle.
Regards,
Michael
K6MLE[/QUOTE]
Let's not forget that there are many standard Forth words that are really part of a PC standard yet the vast majority of Forth uses are embedded and non-standard and have totally different goals and resources. FORGET is easy enough to implement with a standard Forth and other Forths I have written but I haven't needed it for development at all as normally I just perform a COLD start and load the source back again. I do concede that this model is a bit of a pain sometimes when I have many modules to reload so for systems that have 64K of EEPROM I just hold a stable image in the top 32K ready to RESTORE.
That said I could still implement a FORGET but it might have to go through each word to deallocate the code, dictionary, and vector space individually to be on the safe side. The way I would use FORGET is not at an interactive testing level where it is just as easy to just write a new word but when it comes to reloading a module such as SDCARD.fth etc where I would include the word FORGET at the start of the file. Any failure to find the word would simply issue a warning and continue.
I will probably also release some updated drivers soon including the unreleased FAT32 and WIZnet W5200 drivers which also includes the network servers for TELNET, FTP, and HTTP. The FAT32 is aimed primarily at datalogging where I like to preset the card beforehand with fixed file sizes and even fixed line sizes (128 bytes/line). At startup I just find the last file and binary search through this until I find the last non-blank line and set a virtual memory pointer to this in RAM without changing anything on the card. Since these files are not dynamically allocated or grown then we have no need for writing to the cluster file or worrying about fragmentation. When I save data to the card I only have to write into a preset and known position so it is not possible to corrupt the card (even with removal during writes) nor does the card suffer from premature wear because of FAT32 file size updates etc.
My FTP can decide to strip trailing whitepsace when uploading a file but essentially the SD card is treated as flat memory for the first 4GB (more than enough) without regard to fragmentation (since it doesn't exist in this controlled environment). With the virtual memory access words the first 4GB is treated as virtual memory where file handles are actually sector addresses which translate in virtual memory address with a 9 SHL operation. There are of course a lot of words specifically designed for interactive CLI operation such as DIR, ls, cat, FOPEN <name>, etc and FLOAD <name> to load a source file. But don't expect a full FAT32 driver, at least not at present, since it's not my priority and besides FAT32 is horrible, compatible, but horrible especially for SD cards and embedded work. I will add functionality for having several files open though as I only need a minimum of one sector buffer and directory entry per file.
Tachyon is not a Forth for learning as some of you have found out
Here's a method from the FAT32 module for opening files.
Interacting with it:
[FONT=courier new][B]FOPEN EXTEND.FTH[/B]...opened at 00024440 ok [B]FILE@ 40 XDUMP[/B] 0488_8000: 54 41 43 48 59 4F 4E 0A 7B 20 45 58 54 45 4E 44 TACHYON.{ EXTEND 0488_8010: 2E 66 74 68 20 7D 0A 0A 70 72 69 20 45 58 54 45 .fth }..pri EXTE 0488_8020: 4E 44 2E 66 74 68 20 20 20 20 2E 22 20 50 72 69 ND.fth ." Pri 0488_8030: 6D 61 72 79 20 65 78 74 65 6E 73 69 6F 6E 73 20 mary extensions ok [/FONT]This will make for a wonderful Xmas season, thanks in advance!
AND IT WORKED
yes, it took some time to boot up a standard Tachyon 2.1 image from Peters dropbox
but I think this can be made much faster by not running all COGs
AND by reducing the startup delay (to run the about 40 000 000 cycles it takes about half an hour -
so don't give up to early.
I used Gear V 9.10.26.7 dated 26. Oktober 2009, 12:31:00 - this is not the original version, but the extended one.
you find it here: http://forums.parallax.com/showthread.php/100380-More-GEAR-Improved-Emulation-of-the-Propeller?highlight=GEAR
and I loaded the SerialIO.xml plugin, configured it to the correct baudrate and there you go.
Unfortunately I didn't find a way to suppress the autoecho, so typed characters get echoed twice
from the terminal and as usual from Tachyon itself.
EDIT: within serialIO.xml just comment out a few lines
private void txt_KeyPress(object sender, System.Windows.Forms.KeyPressEventArgs e) { if ((Control.ModifierKeys & Keys.Control) != 0) { return; } e.Handled = true; txBuffer += e.KeyChar; // if (e.KeyChar == '\n' || e.KeyChar == '\r') { // displayBuffer += "\r\n"; // } // else { // displayBuffer += e.KeyChar; // } this.bodyField.Text = displayBuffer; this.bodyField.SelectionStart = this.bodyField.Text.Length; this.bodyField.ScrollToCaret(); if (txPhase == 0) { txPhase = 1; } }And the you can set breakpoints in the cogs and watch whats is going on - at the PASM level ...
Why didn't I try this before ??
I've just updated Dropbox with a newer version of the kernel and extend. You will find the echo function can be turned off and on normally with "OFF ECHO" and "ON ECHO". Turning off the echo also suppresses the space character that is emitted after a line has been accepted.
There is no real need to have any startup delay if you are running Gear so you can just comment out the last line of this section.
Once I've done a bit more testing within an application I will release these source files, probably within the week.
[FONT=courier new][B]MOUNT [/B] E2C4_0203: mkdosfs PBJTECH FAT32 Sectors = 7,739,392 ok [B]DIR[/B] PBJTECH LOG0001 .TXT .....a 0000.4318 04/11/2013 01:25:18 131,072 LOG0002 .TXT .....a 0000.4418 04/11/2013 01:25:18 131,072 LOG0003 .TXT .....a 0000.4518 04/11/2013 01:25:18 131,072 LOG0004 .TXT .....a 0000.4618 04/11/2013 01:25:18 131,072 LOG0005 .TXT .....a 0000.4718 04/11/2013 01:25:18 131,072 LOG0006 .TXT .....a 0000.4818 04/11/2013 01:25:18 131,072 LOG0007 .TXT .....a 0000.4918 04/11/2013 01:25:18 131,072 LOG0008 .TXT .....a 0000.4A18 04/11/2013 01:25:18 131,072 LOG0009 .TXT .....a 0000.4B18 04/11/2013 01:25:18 131,072 LOG0010 .TXT .....a 0000.4C18 04/11/2013 01:25:18 131,072 LOG0011 .TXT .....a 0000.4D18 04/11/2013 01:25:18 131,072 LOG0012 .TXT .....a 0000.4E18 04/11/2013 01:25:18 131,072 LOG0013 .TXT .....a 0000.4F18 04/11/2013 01:25:18 131,072 LOG0014 .TXT .....a 0000.5018 04/11/2013 01:25:18 131,072 LOG0015 .TXT .....a 0000.5118 04/11/2013 01:25:18 131,072 LOG0016 .TXT .....a 0000.5218 04/11/2013 01:25:18 131,072 MULTIFAT.FTH .....a 0000.5318 12/11/2013 10:48:50 7,778 SDCARD .FTH .....a 0000.5328 12/11/2013 10:02:02 14,684 CHARLCD .FTH .....a 0000.5348 12/11/2013 10:01:48 18,440 EXTEND .FTH .....a 0000.5370 12/11/2013 10:01:42 57,915 NETWORK .FTH .....a 0000.53E8 12/11/2013 10:01:36 8,109 W5200 .FTH .....a 0000.53F8 12/11/2013 10:01:26 9,732 MCP79410.FTH .....a 0000.5410 12/11/2013 10:01:20 1,357 ok [B]0 FILE[/B] ok [B]FOPEN SDCARD.FTH[/B]...opened at 0000.5328 ok [B]1 FILE[/B] ok [B]FOPEN EXTEND.FTH[/B]...opened at 0000.5370 ok [B]2 FILE[/B] ok [B]FOPEN MULTIFAT.FTH[/B]...opened at 0000.5318 ok [B]3 FILE[/B] ok [B]FOPEN W5200.FTH[/B]...opened at 0000.53F8 ok [B]FILES [/B] #0 SDCARD .FTH .....a 0000.5328 12/11/2013 10:02:02 14,684 #1 EXTEND .FTH .....a 0000.5370 12/11/2013 10:01:42 57,915 #2 MULTIFAT.FTH .....a 0000.5318 12/11/2013 10:48:50 7,778 #3 W5200 .FTH .....a 0000.53F8 12/11/2013 10:01:26 9,732 ok [B]0 FILE FILE@ 20 XDUMP[/B] 00A6_5000: 54 41 43 48 59 4F 4E 0A 5B 7E 0A 7B 20 53 44 20 TACHYON.[~.{ SD 00A6_5010: 43 41 52 44 20 54 4F 4F 4C 4B 49 54 20 7D 20 20 CARD TOOLKIT } ok [B]1 FILE FILE@ 20 XDUMP[/B] 00A6_E000: 54 41 43 48 59 4F 4E 0A 7B 20 45 58 54 45 4E 44 TACHYON.{ EXTEND 00A6_E010: 2E 66 74 68 20 7D 0A 0A 70 72 69 20 45 58 54 45 .fth }..pri EXTE ok [B]2 FILE FILE@ 20 XDUMP[/B] 00A6_3000: 54 41 43 48 59 4F 4E 0A 5B 7E 0A 46 4F 52 47 45 TACHYON.[~.FORGE 00A6_3010: 54 20 46 41 54 33 32 2E 66 74 68 0A 3A 20 46 41 T FAT32.fth.: FA ok [B]3 FILE FILE@ 20 XDUMP[/B] 00A7_F000: 54 41 43 48 59 4F 4E 0A 5B 7E 0A 7B 20 20 20 20 TACHYON.[~.{ 00A7_F010: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 2A 2A ** ok[/FONT]EDIT: This is just a simple (and inefficient) demo to show how we can copy one file into another - here we copy from file #1 to file #0.
FILE@ returns with the virtual address of the beginning of the currently selected file
FILE accepts a parameter to set the currently selected file
XC@ works just like a C@ except the address is a virtual 4GB address
XC! works the same but also flags the buffer as modified
FCLOSE is optional and just flushes any modified buffers and resets file pointers
[FONT=courier new][B]0 FILE[/B] ok [B]FOPEN LOG0001.TXT[/B]...opened at 0000.3B28 ok [B]1 FILE[/B] ok [B]FOPEN EXTEND.FTH[/B]...opened at 0000.4B80 ok ok [B]0 #57915 ADO 1 FILE FILE@ I + XC@ 0 FILE FILE@ I + XC! LOOP[/B] ok [B]0 FILE FILE@ 40 XDUMP[/B] 0076_5000: 54 41 43 48 59 4F 4E 0A 7B 20 45 58 54 45 4E 44 TACHYON.{ EXTEND 0076_5010: 2E 66 74 68 20 7D 0A 0A 70 72 69 20 45 58 54 45 .fth }..pri EXTE 0076_5020: 4E 44 2E 66 74 68 20 20 20 20 2E 22 20 50 72 69 ND.fth ." Pri 0076_5030: 6D 61 72 79 20 65 78 74 65 6E 73 69 6F 6E 73 20 mary extensions ok [B]FCLOSE[/B] ok[/FONT]Thx, Peter
There's also the W5200 driver but I haven't uploaded the network server layer yet as I am working on the glitches although I can telnet and ftp at present.
EDIT: The data stack will probably get an upgrade in the form of a hybrid with all the advantages of fixed positions for the first 4 items or so and a non-addressable push/pop overflow in hub memory.
The downside of this is that each cog that runs a Tachyon VM needs an external stack allocated. By default the pointer to this stack is zero which effectively turns off writing to hub RAM on a push and confines the VM to a 4 level stack which in some cases may be all that it needs. However the idea is that a new task will set the stack pointer for it's cog just as the main console cog does at startup, another example of which is in EXTEND.FTH where TIMERTASK is started up at boot time. Here a timer stack is created for 12 levels and it passes this address to SP!
[FONT=courier new]TABLE timerstk #12 4 * ALLOT \ allot space for timer data stack \ 118us for 8 empty timers pri TIMERTASK timerstk SP![/FONT]New words added or updated are: Since the stack is a fundamental part of the VM and it now operates a bit differently I have upgraded this source as V2.2 and I have placed all the new files in Dropbox. The webpage versions will have links updated or inserted into the links page.Note: Popping an empty stack will not cause the SP to go negative (Stack Pointer base address - depth index) but it is now possible to overflow the stack, so beware.
The reason for the dedicated SPI instructions is so that I can run two sets of SPI devices easily and efficiently from the one cog and in this case it is the SDCARD using the RUNMOD loadable PASM modules and the WIZnet using the SPI instructions.
you placed the extended stack for the TERMINAL-COG fixed at $7720 with nothing above.
which gives a total stack of 60 longs - nothing to complain about.
and if need be can be made any size - great.
for other cog processes stack needs to be allocated manually as shown in new EXTEND.fth thanks a lot ...
It's fairly rare that I need a stack more than 12 levels deep but it's also good that it has plenty of room to move or if I have junk being left on the stack then I can still see what's happened. I can't see how I would use 32 levels though even though I have pushed some extra check numbers onto it and ran it through my FTP/TELNET stuff. I can see a real need to get that dictionary out of hub ram though and I've looked at it before and know how I will handle it by using a small unused area of the SD card for this as I only need one sector buffer at a time for dictionary searches with a cache for all the recent hits. But this is significant enough to become V3 although I will still allow for slow EEPROM, or fast SPI Flash to be used instead otherwise the default is as it is now. V3 will also make more use of the pri vs pub declaration so that it knows it can remove the pri heads from the dictionary when it encounters an END directive.
Putting the pri headers in such a seperate dictionary would make it very easy to reset it on END.
Just reset the dict for the 'ephemeral' dictionary (taken from LISP garbage collection mechanisms ...), no searching, deleting, compacting required.
Well it may well be that assuming either SD card or SPI Flash is used that the source code would also be compiled from SD even if it is downloaded serially first as the card write routines can easily keep up with the high baud rates. Compiling from a files system means it's easy to have include directives and also it will compile as fast as it can rather than a serial download that has to have line delays because there is no handshaking. Perhaps I could even fetch the files from the PC via FTP, now that would be nice or simply copy the files across via FTP.
Yes, the pri headers could just be routed into their own dictionary which could be wiped after a load. Even though there is plenty of storage when you have an SD card there is still the inefficiency of searching a large dictionary so removing or ignoring the pri headers would still be advantageous. Of course it would also be possible to give each header a fixed amount of space, say 32 or 64 bytes each so that it would be possible to do simple compares on longs and skip to the next fixed length header without having to process the header any further in case of a mismatch. The longest name I have in the dictionary is 18 characters long so allowing the usual 4 extra bytes for count,code, and attributes that still leaves 28 characters if I use 32 bytes per entry.
So I would hate to see TACHYON following the Windows road and getting more and more resource hungry each version.
I am running it still on PPDB or P-DIP systems only.
Not to worry because it will always handle the minimal system but many of my designs have SD or even SPI Flash so it's a resource I would like to consume a bit more of so that I may have more hub RAM available at least. 32k is all there is and I don't believe in piling banked RAM or multiple Props together to achieve what I could do more efficiently with another type of CPU. But those CPUs are boring and transitory, barely staying around for a couple of years before they are hard to get. Big learning curves on their hardware and tools too. Prop ticks all the boxes.
When I open the latest "Tachyon V2.3.binary" from Dropbox the Propeller Tool v. 1.3.2 gives me this error message.
Rick.
Did you check your crystal settings match those of the binary 10MHz PLL8x?
My system has 5MHz Pll16x so I did compile the .spin in BST and PropTool myself after changing those settings - all fine