Experimentally I should be able to SAVEROM and load a saved image directly back into RAM via a dedicated loader cog. If I play with doing this then I think that should nail whatever is affecting your OS load.
@Cluso99 you have such a PASM loader COG already don't you? That can load an image from SD and start it?
Yes. My OS can load a binary file into hub (32KB) and then execute it. This is the same way the downloaded works, and it works fine.
It seems to me that Tachyon is requiring something to be resident in lower EEPROM.
@D.P. (and MJB) - agreed and done. Let me know if there are any other sections that need updating or improving. I just checked edit permissions with Dropbox and they can only be applied to folders which means I may need to move the main Tachyon files into their own sub-folder to make it easier to grant edit permissions to just that section. Would you like edit permissions for these files?
I can appreciate you trying everything to get Tachyon to work with your OS.
I'm just wondering if this is for a " I did it " or a actual need of project work.
There is much more to be done in the Kernel as Peter has alluded to.
What are you goals with this Prop OS / Tachyon combo?
In order to "play" with Tachyon, I want it to exist on my prop boards, all of which run my OS.
I have nothing specific that I want to do with Tachyon, other than to see how it works and what it can do. Then perhaps there will be something that I might find to do with it.
@Cluso99 - I've been a bit shy and too busy to get involved in working out the issues with trying to load the Tachyon OS with your loader OS although I am still interested in what the technical issues are. Now if you used Tachyon as your "OS" to load those other binaries then that's another story!
Does this seem to be the correct amount of free memory for these loaded files?
My code is bloated, back to the refactor board... Not using any ROMS on this project so looking for maximum code space.
Does this seem to be the correct amount of free memory for these loaded files?
My code is bloated, back to the refactor board... Not using any ROMS on this project so looking for maximum code space.
Yes, that's about right although I am adjusting EXTEND to only include the necessary sections in a default compile. But how come you aren't using EEWORDS to compact the bulky dictionary as that hogs a lot of memory?
@Cluso99 - I've been a bit shy and too busy to get involved in working out the issues with trying to load the Tachyon OS with your loader OS although I am still interested in what the technical issues are. Now if you used Tachyon as your "OS" to load those other binaries then that's another story!
Peter,
If you can point me where to look in Tachyon, I can try and understand what Tachyon requires in lower eeprom.
I just don't now where to look and it's way too big to look at the lot. Might be best for me to phone for some pointers?
@Cluso99 - I've been a bit shy and too busy to get involved in working out the issues with trying to load the Tachyon OS with your loader OS although I am still interested in what the technical issues are. Now if you used Tachyon as your "OS" to load those other binaries then that's another story!
Peter,
If you can point me where to look in Tachyon, I can try and understand what Tachyon requires in lower eeprom.
I just don't now where to look and it's way too big to look at the lot. Might be best for me to phone for some pointers?
I will ring you then. All of us are only a phone call (and a time-zone) apart no matter where we are in the world, most international calls are unlimited with phone plans these days and then there is Skype/Viber etc.
@Cluso99 - I've been a bit shy and too busy to get involved in working out the issues with trying to load the Tachyon OS with your loader OS although I am still interested in what the technical issues are. Now if you used Tachyon as your "OS" to load those other binaries then that's another story!
Peter,
If you can point me where to look in Tachyon, I can try and understand what Tachyon requires in lower eeprom.
I just don't now where to look and it's way too big to look at the lot. Might be best for me to phone for some pointers?
I will ring you then. All of us are only a phone call (and a time-zone) apart no matter where we are in the world, most international calls are unlimited with phone plans these days and then there is Skype/Viber etc.
Yes I've had a couple of nice chats with MJB over skype.
3709 Free with all my stuff loaded on this new setup. Forgot all about compact and EEWORDS.fth
I had a nice chat with Peter by phone. Here is where I/we are up to..
I m going to try and just get the basic Tachyon module working. To be able to test it basically, Peter has added "words" to the kernel.
Looks like it might be the little spin booter may be overwritten as a buffer, so that is where I will be looking. Also possibly I will just boot the pasm tachyon rather than the spin stub. Will see where that leads.
When just using Tachyon (without extend.fth, etc), I am able to save the lower eeprom to a file. Then with my OS reprogrammed into lower eeprom, I am able to
* perform all my OS commands, etc
* I can "RUN BOOTTACH.LOW" (the lower eeprom I saved above) which loads the SD file into hub ram $0000..$7FFF and then executes the spin program pointed to by hub #0010.
Tachyon then runs and I can do "WORDS" which displays the tachyon words.
When I do "CTL_C" Tachyon reboots from eeprom which contains my OS bootloader, and OS comes up fine.
Peter, the only alteration to your latest code today was to change the xtal to 12MHz PLL8.
Next, I will now look at the listing to see how you are starting Tachyon. As we discussed, probably the spin is being overwritten as a buffer by something later in the process (extend, etc).
Well everything was going peachy until I used COMPACT and this file. If I COMPACT after this file is loaded OR before this file is loaded it will not work. I need to use the DS1302 because it has ram that I write to and read from often during system runtime, else I would use a more modern clock chip. And I have a bunch of these with battery holder .....
Also this current file is using it's own i2c lines, the chip works great on 28, 29 but I was trying to debug the issue. I can't read or write from the chip once compact gets run.
UPDATES
Cleaned up default EXTEND build and tidied the console reporting so you can see what was included. There are now 10,059 bytes free and EXTEND also checks which RTC to use as well so that is set as a default.
EASYFILE now has FCREATE$ and also FCREATE with the alias "mk" which is a little nix like as the closest nix command is mkdir. You need to specify the size in bytes so that mk preallocates the clusters and sets the file size. Only contiguous clusters will be allocated anyway, no fragmentation allowed.
$10.0000 mk MEGA.TXT will create a 1MB file. You can also use lower case in the standard 8.3 format as neither EASYFILE nor Linux minds.
@D.P. I'm getting around to checking what may be not so peachy!
Well everything was going peachy until I used COMPACT and this file. If I COMPACT after this file is loaded OR before this file is loaded it will not work. I need to use the DS1302 because it has ram that I write to and read from often during system runtime, else I would use a more modern clock chip. And I have a bunch of these with battery holder .....
Also this current file is using it's own i2c lines, the chip works great on 28, 29 but I was trying to debug the issue. I can't read or write from the chip once compact gets run.
your SET_DS0 calls for a fall through - saves ~15..20 bytes ;-)
{ DS1302 set register words }
pub SET_DS0 ( reg -- ) --- Set the DS register, second byte 0
0 SWAP
pub SET_DS ( packed reg -- ) --- Set the DS register
CCE OUTSET
DS1302!
DS1302!
CCE OUTCLR
;
Yesterday I had a reasonable look at the Tachyon kernel code (Tachyon V3.0 JUNO.spin)
This is what I understand (without EXTEND.FTH)...
From boot, the propeller copies the lower 32B from EEPROM to HUB RAM.
Spin then boots which in turn does...
COGINIT (1, @TachyonRx, 0)
COGINIT (2..7, @RESET, @IDLE_reset)
COGINIT (0, @RESET, @TERMINAL_reset)
So...
COG 1 loads/runs the PASM Tachyon Receiver
COGS 2..7 loads/runs the PASM LMM loop in IDLE mode
COG 0 loads/runs the PASM LMM loop from TERMINAL_reset
The TERMINAL_reset falls into TERMINAL which then initialises the propeller xtal, etc, displays the Tachyon version, and runs Tachyon.
The Tachyon Receiver is the PASM serial receive routine, and once loaded into cog 1, the hub section is reused as buffers.
Tachyon provides extremely basic functions which are then used by other function calls (Tachyon words) to make more complex functions.
Many basic functions are in the form of overlays, that will be loaded into the top area of cog for execution. The area commences at cog address _RUNMOD (currently $1DB).
An area in HUB RAM is used for PASM COG Drivers, called "roms". Currently VGARUN, UART, SIDEMU, QUART, MONO16, F32 are defined, with further space available (currently $325C..$6A8C, see "TRIM").
Next, the low level dictionary is located, beginning with "DUP", and ending with "enddict". This is some form of call table to the primary code ???
Next ($7500) the PASM "TachyonRx" code, which is loaded/run in Cog 1, is located. Once loaded this space is reused as "rxbuffers".
At $77A8 is "RESET" which also contains the LMM routine. This is loaded into COGs 2..7 and then Cog 0.
At $7F68..$7F90 is the Spin Block which is used to start the cogs/Tachyon via spin.
Please let me know if there are any errors in my understanding, or anything else you would like to add.
BTW, finally getting around to doing something with FCREATE to create files. I want to preallocate space for files because even if I preallocated 1MB for any file that means I could still have up to 4,000 or so files on a 4GB card. Larger files can be preallocated but an open-ended allocation will always start at the end of all the used clusters so it can keep growing. I don't see a need for this though as most files have to be kept to a manageable size anyway otherwise I know how much space a file needs anyway.
great, this allows it now to save EEPROM images any time on any SD card at hand.
Yesterday I had a reasonable look at the Tachyon kernel code (Tachyon V3.0 JUNO.spin)
This is what I understand (without EXTEND.FTH)...
From boot, the propeller copies the lower 32B from EEPROM to HUB RAM.
Spin then boots which in turn does...
COGINIT (1, @TachyonRx, 0)
COGINIT (2..7, @RESET, @IDLE_reset)
COGINIT (0, @RESET, @TERMINAL_reset)
So...
COG 1 loads/runs the PASM Tachyon Receiver
COGS 2..7 loads/runs the PASM LMM loop in IDLE mode
COG 0 loads/runs the PASM LMM loop from TERMINAL_reset
The TERMINAL_reset falls into TERMINAL which then initialises the propeller xtal, etc, displays the Tachyon version, and runs Tachyon.
The Tachyon Receiver is the PASM serial receive routine, and once loaded into cog 1, the hub section is reused as buffers.
Tachyon provides extremely basic functions which are then used by other function calls (Tachyon words) to make more complex functions.
Many basic functions are in the form of overlays, that will be loaded into the top area of cog for execution. The area commences at cog address _RUNMOD (currently $1DB).
An area in HUB RAM is used for PASM COG Drivers, called "roms". Currently VGARUN, UART, SIDEMU, QUART, MONO16, F32 are defined, with further space available (currently $325C..$6A8C, see "TRIM").
Next, the low level dictionary is located, beginning with "DUP", and ending with "enddict". This is some form of call table to the primary code ???
Next ($7500) the PASM "TachyonRx" code, which is loaded/run in Cog 1, is located. Once loaded this space is reused as "rxbuffers".
At $77A8 is "RESET" which also contains the LMM routine. This is loaded into COGs 2..7 and then Cog 0.
At $7F68..$7F90 is the Spin Block which is used to start the cogs/Tachyon via spin.
Please let me know if there are any errors in my understanding, or anything else you would like to add.
as far as I understand, that is pretty much ok.
I would not call the Tachyon inner byte code interpreter LMM to not confuse it with the common use of Bill Hennings LMM running PASM code from HUB.
And just recently Peter also added the option to execute real LMM as a special feature inside the kernel as well. Haven't seen an example and not used it yet. But could be great with the optional embedded assembler.
The 'overlays' called RUNMODs are just tiny ~ 18 longs long PASM snippets to speed up certain operations, that do not fit inside the kernel 2k COG image. They are manually paged-in on demand.
@Cluso99 have a look at the Tachyon document linked in my footer ...
Well everything was going peachy until I used COMPACT and this file. If I COMPACT after this file is loaded OR before this file is loaded it will not work. I need to use the DS1302 because it has ram that I write to and read from often during system runtime, else I would use a more modern clock chip. And I have a bunch of these with battery holder .....
Also this current file is using it's own i2c lines, the chip works great on 28, 29 but I was trying to debug the issue. I can't read or write from the chip once compact gets run.
I had only a very quick look at your code and decided that it might be better to add the DS1302 bits to the RTC section in EXTEND. So I did that last night using the SPI instructions and a remap and it looks like it should work although the forum was down last night and I couldn't post. I just need to add some simple RAM access method to it and it should be right. I think the DS1302 is a bit of a throwback but decided to see how I could integrate it anyway and maybe make some other improvements to make the RTC routines adapt easily to other devices.
You can specify the RTC device as <pins> DS1302 where pins are the normal group of four bytes specifying CE,MISO,MOSI,SCK using the & prefix. So if P0 was the CLK and P1 was the data I/O and P2 the CE this would be &02.01.01.00 DS1302. This can be locked in after a BACKUP or you can put it in your !PCB function etc.
Perhaps you could test your RTC and report back in case I need to tweak something but at least the driver makes it work like any of the other RTCs. I will probably modify RTC@ and RTC! function as well for accessing the RTC RAM and control registers such as trickle charge. I think I have DS1302s somewhere as I do remember using them last century sometime that I can test
btw, the DS1302 SPI seems to be very non-standard, using an active high CS (RST) and LSB first.
Well everything was going peachy until I used COMPACT and this file. If I COMPACT after this file is loaded OR before this file is loaded it will not work. I need to use the DS1302 because it has ram that I write to and read from often during system runtime, else I would use a more modern clock chip. And I have a bunch of these with battery holder .....
Also this current file is using it's own i2c lines, the chip works great on 28, 29 but I was trying to debug the issue. I can't read or write from the chip once compact gets run.
I had only a very quick look at your code and decided that it might be better to add the DS1302 bits to the RTC section in EXTEND. So I did that last night using the SPI instructions and a remap and it looks like it should work although the forum was down last night and I couldn't post. I just need to add some simple RAM access method to it and it should be right. I think the DS1302 is a bit of a throwback but decided to see how I could integrate it anyway and maybe make some other improvements to make the RTC routines adapt easily to other devices.
You can specify the RTC device as <pins> DS1302 where pins are the normal group of four bytes specifying CE,MISO,MOSI,SCK using the & prefix. So if P0 was the CLK and P1 was the data I/O and P2 the CE this would be &02.01.01.00 DS1302. This can be locked in after a BACKUP or you can put it in your !PCB function etc.
Perhaps you could test your RTC and report back in case I need to tweak something but at least the driver makes it work like any of the other RTCs. I will probably modify RTC@ and RTC! function as well for accessing the RTC RAM and control registers such as trickle charge. I think I have DS1302s somewhere as I do remember using them last century sometime that I can test
btw, the DS1302 SPI seems to be very non-standard, using an active high CS (RST) and LSB first.
Hi Peter,
To recap here is my working code running
MODULES LOADED:
3502: DS1302mini.fth DS1302 RTC Mini 160802.2100
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 160805-0040
SETDST
Setting Date: 160804
Setting Time: 197830 ok
#181100 DSTIME! ok
4 DSDAY! ok
SETDST
Setting Date: 160804
Setting Time: 181128 ok
.DT 2016/08/04 THU 18:11:34 ok
I tried the new RTC type DS1302 and could not get it to respond. I double checked my pin assigments. Don't need to fight with this, I will move on to the 3231 and be done I guess. I was worried about the eeprom write cycles since I store runtime stuff off every minute in case of reboot ....
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730
FREQ: 96MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $5B44...74D0 for 6,540 bytes (+3,911)
CODE: $0930...3502 for 11,218 bytes (+7,490)
RAM: 9,794 bytes free
BUILD: FIRMWARE BUILD DATE 160804:180000 BOOTS: 6 runtime 37
BOOT: EXTEND.boot
MODULES LOADED:
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 160805-0040
ROMS
0848 VGA32x15
----------------------------------------------------------------
. 1397575506 ok
&14.01.01.02 DS1302 ok
.S Data Stack (0) ok
.DT 2065/12/31 SUN 46:65:00 ok
RDRTC ok
.DT 2065/12/31 SUN 46:65:00 ok
.DAY SUN ok
.TIME 46:65:00 ok
@D.P. - The MCP79410 is also supported and has 64 bytes of RAM as well as 128 bytes of EEPROM. In fact I'm just working with this chip now and will add some RAM/EEPROM supportg for it.
Thanks for the feedback but I will check this myself just to help make Tachyon more flexible although I2C RTCs are definitely the way to go.
Okay, thanks, I will compare the SPI-ish signals of what my code produces compared to the new extend.fth version and see what I can see. I did this to mimic arduino code I found online to create what I have now.
Just ordered those other chips @ .90 each and some SOIC-8 breakouts for prototyping.
Okay, thanks, I will compare the SPI-ish signals of what my code produces compared to the new extend.fth version and see what I can see. I did this to mimic arduino code I found online to create what I have now.
Just ordered those other chips @ .90 each and some SOIC-8 breakouts for prototyping.
If you are sneaky you can place the SOICs straight onto the 0.1" matrix pads. I did this with my P2 motherboard proto and positioned correctly I could solder down the pins while a couple of others just had their legs in the air. In one case I soldered directly to a leg up as well but my serial flash and eeprom didn't require anything else.
Anyhow I mostly use those cheap DS3231 modules either plugged in horizontally so that the RTC PCB is vertical as this is quite stable or I even remove the connector and just solder wire directly to the RTC PCB.
The MCP79410's RAM can be accessed just using the RTC@ and RTC! commands at the $20 address offset while the EEPROM can be accessed with the same commands after altering the RTC address with RTCEE word - just switch back again with MCP79410.
Before I dig in to make any suggestions/changes, I believe I need to get feel for why some things have been done the way they have. (PS I am not being critical here as I am in awe of what has been achieved)
* All cogs are started and those effectively unused are placed in an LMM idle loop, waiting for a flag to start the doing something useful. Was there any reason for this?
* Cogs are started by spin. The propeller boot rom requires the first program to be spin. Was there any other reason to start the other cogs in spin?
* The Tachyon kernel resides in the lower 32KB of EEPROM. Was there any reason why the base kernel does not use the upper 32KB of EEPROM (for VGA/UART etc)? For cases where only 32KB EEPROM is present? Because that is the way it developed? Anything else?
BTW I have always been impressed by Tachyon. Delving into it a little only impresses me more!
Before I dig in to make any suggestions/changes, I believe I need to get feel for why some things have been done the way they have. (PS I am not being critical here as I am in awe of what has been achieved)
* All cogs are started and those effectively unused are placed in an LMM idle loop, waiting for a flag to start the doing something useful. Was there any reason for this?
* Cogs are started by spin. The propeller boot rom requires the first program to be spin. Was there any other reason to start the other cogs in spin?
* The Tachyon kernel resides in the lower 32KB of EEPROM. Was there any reason why the base kernel does not use the upper 32KB of EEPROM (for VGA/UART etc)? For cases where only 32KB EEPROM is present? Because that is the way it developed? Anything else?
BTW I have always been impressed by Tachyon. Delving into it a little only impresses me more!
Sorry, I've been sidetracked and meant to get back to you on your earlier post. In the meantime:
1 - Initially spare cogs were loaded with Tachyon and left in an idle loop so that it would be a very simple matter of handing it something to start executing which it would do immediately. Also COGINIT will only be useful if you have a copy of the Tachyon image to load, which we don't as the memory is reused for buffers. These days with V3 this could be made to happen that way though.
2 - I never knew any better when I coded the first few parts of the kernel but I'm guessing that if I look at the boot rom source code I will see how I can tell it to run my code directly. The Spin boot is of course only a few lines before cog 0 is loaded over with the kernel.
3 - Tachyon was designed so that it would only require a simple one step F11 in Prop tool to load and besides the Prop booter only supports the first 32k anyway. I wish the boot ROM did handle >32k loads but then Prop tool would need to be able to compile to these areas too
When I first wrote Tachyon I didn't have file system stuff or Ethernet etc so I had so much memory I actually tested V1 with bitmap VGA graphics at the time. So I didn't have any need to squeeze memory or try to use upper EEPROM, that need came much later.
Thanks for your comments Ray, maybe you would like to suggest a Spinless boot method?
Comments
It seems to me that Tachyon is requiring something to be resident in lower EEPROM.
I'm just wondering if this is for a " I did it " or a actual need of project work.
There is much more to be done in the Kernel as Peter has alluded to.
What are you goals with this Prop OS / Tachyon combo?
In order to "play" with Tachyon, I want it to exist on my prop boards, all of which run my OS.
I have nothing specific that I want to do with Tachyon, other than to see how it works and what it can do. Then perhaps there will be something that I might find to do with it.
My code is bloated, back to the refactor board... Not using any ROMS on this project so looking for maximum code space.
Yes, that's about right although I am adjusting EXTEND to only include the necessary sections in a default compile. But how come you aren't using EEWORDS to compact the bulky dictionary as that hogs a lot of memory?
Thx
If you can point me where to look in Tachyon, I can try and understand what Tachyon requires in lower eeprom.
I just don't now where to look and it's way too big to look at the lot. Might be best for me to phone for some pointers?
I will ring you then. All of us are only a phone call (and a time-zone) apart no matter where we are in the world, most international calls are unlimited with phone plans these days and then there is Skype/Viber etc.
Yes I've had a couple of nice chats with MJB over skype.
3709 Free with all my stuff loaded on this new setup. Forgot all about compact and EEWORDS.fth
doh
WORDS DUP OVER DROP 2DROP SWAP ROT BOUNDS STREND 0 1 2 3 4 8 ON TRUE -1 BL 16 FALSE OFF 1+ 1- + - DO LOOP +LOOP FO R NEXT INVERT AND ANDN OR XOR ROL ROR SHR 8>> SHL 8<< 2/ 2* REV MASK >N >B 9BITS 0= NOT = > C@ W@ @ C+! C! C@+ + W+! W! +! ! UM* ABS -NEGATE ?NEGATE NEGATE CLOCK OUTSET OUTCLR OUTPUTS INPUTS SHROUT SHRINP RESET 0EXIT EXIT NOP 3DROP ?DUP 3RD 4TH CALL JUMP BRANCH> >R R> >L L> REG (WAITPNE) I SPIWRB SPIWR16 SPIWR SPIRD SPICE (OPCODE ) c UM/MOD64 UM/MOD32 RUNMOD (WAITPEQ) CMOVE (EMIT) (EMITX) CMPSTR LOADMOD COGID (COGINIT) !RP COG@ COGREG COG ! DELTA WAITCNT LAP FLOAT NIP ADO 2+ 2- 4* 4/ 2DUP 2OVER * 0<> <> UM/MOD TUCK CELLS -ROT 9<< 9>> 16<< 16>> HIG H LOW LSTACK SET CLR !SP SP! DEPTH (:) : pub pri UNSMUDGE IF ELSE THEN ENDIF BEGIN UNTIL AGAIN WHILE REPEAT ; \ '' ( { } IFNDEF IFDEF " ." (.") TO BCOMP C, | || , BREAK CASE SWITCH SWITCH@ SWITCH= SWITCH>< STACKS XCALLS REBOOT STOP [TX485] [SERIN] [SSD] [ESPIO] [SPIO] [MCP32] [SDRD] [SDWR] [PWM32] [PWM32!] [PLOT] [PLAYER] BCA [W S2812] [SQRT] [CAP] SET? U/ U/MOD */ 0< < U< WITHIN ?EXIT ERASE FILL ms READBUF KEY WKEY (KEY) HEX DECIMAL BIN ARY .S HDUMP COGDUMP .STACKS DEBUG EMIT CLS SPACE BELL CR SPINNER .HEX .BYTE .WORD .LONG . >DIGIT NUMBER SCRUB GETWORD SEARCH FINDSTR NFA>BFA EXECUTE VER .VER TACHYON @PAD HOLD >CHAR #> <# # #S <D> PRINT$ LEN$ U. .DEC DI SCARD COGINIT <CMOVE lastkey rx flags base digits delim @word switch autorun keypoll tasks unum uemit ukey nam es here codes errors baudcnt prompt ufind create lines ALLOT ALLOCATED HERE >VEC BFA>CFA [NFA'] ['] ERROR NOTF OUND NFA' ' [COMPILE] GRAB LITERAL (CREATE) CREATEWORD CREATE TASK IDLE LOOKUP +CALL BUFFERS FREE TERMINAL CON SOLE rxpars V3 KOLD WORDS *end* okMemo to MJB: That took another 40 code bytes!
I m going to try and just get the basic Tachyon module working. To be able to test it basically, Peter has added "words" to the kernel.
Looks like it might be the little spin booter may be overwritten as a buffer, so that is where I will be looking. Also possibly I will just boot the pasm tachyon rather than the spin stub. Will see where that leads.
When just using Tachyon (without extend.fth, etc), I am able to save the lower eeprom to a file. Then with my OS reprogrammed into lower eeprom, I am able to
* perform all my OS commands, etc
* I can "RUN BOOTTACH.LOW" (the lower eeprom I saved above) which loads the SD file into hub ram $0000..$7FFF and then executes the spin program pointed to by hub #0010.
Tachyon then runs and I can do "WORDS" which displays the tachyon words.
When I do "CTL_C" Tachyon reboots from eeprom which contains my OS bootloader, and OS comes up fine.
Peter, the only alteration to your latest code today was to change the xtal to 12MHz PLL8.
Next, I will now look at the listing to see how you are starting Tachyon. As we discussed, probably the spin is being overwritten as a buffer by something later in the process (extend, etc).
Thanks so much for your help today
Also this current file is using it's own i2c lines, the chip works great on 28, 29 but I was trying to debug the issue. I can't read or write from the chip once compact gets run.
just discovered I did not put enough effort in understanding dropbox, just used it to download your folder ZIPs ...
Cleaned up default EXTEND build and tidied the console reporting so you can see what was included. There are now 10,059 bytes free and EXTEND also checks which RTC to use as well so that is set as a default.
EASYFILE now has FCREATE$ and also FCREATE with the alias "mk" which is a little nix like as the closest nix command is mkdir. You need to specify the size in bytes so that mk preallocates the clusters and sets the file size. Only contiguous clusters will be allocated anyway, no fragmentation allowed.
$10.0000 mk MEGA.TXT will create a 1MB file. You can also use lower case in the standard 8.3 format as neither EASYFILE nor Linux minds.
@D.P. I'm getting around to checking what may be not so peachy!
$1,000,000 mk MEGA.TXT
'.' could be the decimal point for D.P. ;-) an his floats ...
{ DS1302 set register words } pub SET_DS0 ( reg -- ) --- Set the DS register, second byte 0 0 SWAP pub SET_DS ( packed reg -- ) --- Set the DS register CCE OUTSET DS1302! DS1302! CCE OUTCLR ;This is what I understand (without EXTEND.FTH)...
From boot, the propeller copies the lower 32B from EEPROM to HUB RAM.
Spin then boots which in turn does...
COGINIT (1, @TachyonRx, 0)
COGINIT (2..7, @RESET, @IDLE_reset)
COGINIT (0, @RESET, @TERMINAL_reset)
So...
COG 1 loads/runs the PASM Tachyon Receiver
COGS 2..7 loads/runs the PASM LMM loop in IDLE mode
COG 0 loads/runs the PASM LMM loop from TERMINAL_reset
The TERMINAL_reset falls into TERMINAL which then initialises the propeller xtal, etc, displays the Tachyon version, and runs Tachyon.
The Tachyon Receiver is the PASM serial receive routine, and once loaded into cog 1, the hub section is reused as buffers.
Tachyon provides extremely basic functions which are then used by other function calls (Tachyon words) to make more complex functions.
Many basic functions are in the form of overlays, that will be loaded into the top area of cog for execution. The area commences at cog address _RUNMOD (currently $1DB).
An area in HUB RAM is used for PASM COG Drivers, called "roms". Currently VGARUN, UART, SIDEMU, QUART, MONO16, F32 are defined, with further space available (currently $325C..$6A8C, see "TRIM").
Next, the low level dictionary is located, beginning with "DUP", and ending with "enddict". This is some form of call table to the primary code ???
Next ($7500) the PASM "TachyonRx" code, which is loaded/run in Cog 1, is located. Once loaded this space is reused as "rxbuffers".
At $77A8 is "RESET" which also contains the LMM routine. This is loaded into COGs 2..7 and then Cog 0.
At $7F68..$7F90 is the Spin Block which is used to start the cogs/Tachyon via spin.
Please let me know if there are any errors in my understanding, or anything else you would like to add.
great, this allows it now to save EEPROM images any time on any SD card at hand.
as far as I understand, that is pretty much ok.
I would not call the Tachyon inner byte code interpreter LMM to not confuse it with the common use of Bill Hennings LMM running PASM code from HUB.
And just recently Peter also added the option to execute real LMM as a special feature inside the kernel as well. Haven't seen an example and not used it yet. But could be great with the optional embedded assembler.
The 'overlays' called RUNMODs are just tiny ~ 18 longs long PASM snippets to speed up certain operations, that do not fit inside the kernel 2k COG image. They are manually paged-in on demand.
@Cluso99 have a look at the Tachyon document linked in my footer ...
I had only a very quick look at your code and decided that it might be better to add the DS1302 bits to the RTC section in EXTEND. So I did that last night using the SPI instructions and a remap and it looks like it should work although the forum was down last night and I couldn't post. I just need to add some simple RAM access method to it and it should be right. I think the DS1302 is a bit of a throwback but decided to see how I could integrate it anyway and maybe make some other improvements to make the RTC routines adapt easily to other devices.
You can specify the RTC device as <pins> DS1302 where pins are the normal group of four bytes specifying CE,MISO,MOSI,SCK using the & prefix. So if P0 was the CLK and P1 was the data I/O and P2 the CE this would be &02.01.01.00 DS1302. This can be locked in after a BACKUP or you can put it in your !PCB function etc.
Perhaps you could test your RTC and report back in case I need to tweak something but at least the driver makes it work like any of the other RTCs. I will probably modify RTC@ and RTC! function as well for accessing the RTC RAM and control registers such as trickle charge. I think I have DS1302s somewhere as I do remember using them last century sometime that I can test
btw, the DS1302 SPI seems to be very non-standard, using an active high CS (RST) and LSB first.
Hi Peter,
To recap here is my working code running
I tried the new RTC type DS1302 and could not get it to respond. I double checked my pin assigments. Don't need to fight with this, I will move on to the 3231 and be done I guess. I was worried about the eeprom write cycles since I store runtime stuff off every minute in case of reboot ....
Thanks for the feedback but I will check this myself just to help make Tachyon more flexible although I2C RTCs are definitely the way to go.
Just ordered those other chips @ .90 each and some SOIC-8 breakouts for prototyping.
Anyhow I mostly use those cheap DS3231 modules either plugged in horizontally so that the RTC PCB is vertical as this is quite stable or I even remove the connector and just solder wire directly to the RTC PCB.
The MCP79410's RAM can be accessed just using the RTC@ and RTC! commands at the $20 address offset while the EEPROM can be accessed with the same commands after altering the RTC address with RTCEE word - just switch back again with MCP79410.
* All cogs are started and those effectively unused are placed in an LMM idle loop, waiting for a flag to start the doing something useful. Was there any reason for this?
* Cogs are started by spin. The propeller boot rom requires the first program to be spin. Was there any other reason to start the other cogs in spin?
* The Tachyon kernel resides in the lower 32KB of EEPROM. Was there any reason why the base kernel does not use the upper 32KB of EEPROM (for VGA/UART etc)? For cases where only 32KB EEPROM is present? Because that is the way it developed? Anything else?
BTW I have always been impressed by Tachyon. Delving into it a little only impresses me more!
Sorry, I've been sidetracked and meant to get back to you on your earlier post. In the meantime:
1 - Initially spare cogs were loaded with Tachyon and left in an idle loop so that it would be a very simple matter of handing it something to start executing which it would do immediately. Also COGINIT will only be useful if you have a copy of the Tachyon image to load, which we don't as the memory is reused for buffers. These days with V3 this could be made to happen that way though.
2 - I never knew any better when I coded the first few parts of the kernel but I'm guessing that if I look at the boot rom source code I will see how I can tell it to run my code directly. The Spin boot is of course only a few lines before cog 0 is loaded over with the kernel.
3 - Tachyon was designed so that it would only require a simple one step F11 in Prop tool to load and besides the Prop booter only supports the first 32k anyway. I wish the boot ROM did handle >32k loads but then Prop tool would need to be able to compile to these areas too
When I first wrote Tachyon I didn't have file system stuff or Ethernet etc so I had so much memory I actually tested V1 with bitmap VGA graphics at the time. So I didn't have any need to squeeze memory or try to use upper EEPROM, that need came much later.
Thanks for your comments Ray, maybe you would like to suggest a Spinless boot method?