OK I have my Tachyon V3.0 with EXTEND, PX2, SDCARD & EASYFILE loaded, and ": BACKUP ;" and ": ?BACKUP ;" commands removed.
Tachyon boots (bit of a problem with TeraTerm as I have to unplug board and disconnect/reconnect TeraTerm. But I have proven it reboots ok.
Is there a command that will save the 32KB hub (or lower eeprom) ie the "Tachyon Boot Image" to a file ?
The trouble with reading RAM is that some of the areas that are initially the cog binary image are reused for buffers, hence reading from eeprom to save to file avoids all that. But we can treat the file in the same way as EEPROM if you like since it is accessed as virtual memory, I just need to make BACKUP handle virtual file memory in place of eeprom. It's easy enough, I will get back to you soon.
Great not even 10 minutes under version control and EXTEND.FTH is gonna change. No worries you did name the system Tachyon, Schrödinger might have worked well too
Peter,
I presume it is not as simple as using the Tachyon V3.0 image as a file ???
ie I presume the commands I used to remove backup and add extend, etc changes the boot image that is stored on eeprom???
If it just a matter of me reading out the lower 32KB image to a file, I can add that part to my OS. I can already write a file to lower or upper eeprom.
Here are the files for the lower and upper 32KB eeprom. They are for my pcb 6MHz and SD on P12-15.
If I program them into the eeprom, then Tachyon boots and runs fine. However, if I program my OS into the lower section and run the lower 32KB from an sd file, tachyon does not run.
Is there anything in the lower 32KB eeprom that Tachyon is checking, or do I have a bug in running the binary???
OK I have my Tachyon V3.0 with EXTEND, PX2, SDCARD & EASYFILE loaded, and ": BACKUP ;" and ": ?BACKUP ;" commands removed.
Tachyon boots (bit of a problem with TeraTerm as I have to unplug board and disconnect/reconnect TeraTerm. But I have proven it reboots ok.
Is there a command that will save the 32KB hub (or lower eeprom) ie the "Tachyon Boot Image" to a file ?
what is in your PX2 ?
usuall this goes before EXTEND.
Since e.g. if you do not have a HW RTC you can specify a SW RTC in PX2 and EXTEND checks for this when loading.
So if you have a soft RTC this could potentially access EEPROM (low or high - depends on how you set it up), but I don'T think it should crash.
Peter,
I presume it is not as simple as using the Tachyon V3.0 image as a file ???
ie I presume the commands I used to remove backup and add extend, etc changes the boot image that is stored on eeprom???
If it just a matter of me reading out the lower 32KB image to a file, I can add that part to my OS. I can already write a file to lower or upper eeprom.
if you do NOT do BACKUP the RAM will not be stored in EEPROM.
So maybe you want to use BACKUP, then save EE->SD,
then reload your OS to lower EE and then load lower 32k from SD->RAM ...
MJB,
Are you saying I need to do BACKUP before I do anything else, or after I load the other .FTH routines?
Currently away for extra long weekend. I didn't get far enough before I left to bother taking anything with me
Guess what I really need is a step by step instruction guide to the few steps needed, and what each does. Eg I know what SDCARD and EASYFILE adds, and in what order. I know what PX2.H (my hardware definition) does, it works. But I am unsure if I have the correct order. I know EXTEND adds lots of commands, but that's it. I know I have to add it in but don't otherwise know any more.
I want to get to a point where what is in the lower 32KB EEPROM can be loaded and run from an SD file by another program into hub, and run from there without needing any code residing in the lower 32KB of EEPROM. The upper 32KB of EEPROM is available for Tachyon.
I have updated my OS so that I can write out the EEPROM (lower or upper 32KB) to an SD file. The reverse was already available.
If I write out Tachyon lower 32KB to a file, program in my OS boot code, and the overwrite the EEPROM boot code with the previously saved EEPROM Tachyon boots and runs fine. But just loading the file into hub and executing it does not.
MJB,
Are you saying I need to do BACKUP before I do anything else, or after I load the other .FTH routines?
Currently away for extra long weekend. I didn't get far enough before I left to bother taking anything with me
Guess what I really need is a step by step instruction guide to the few steps needed, and what each does. Eg I know what SDCARD and EASYFILE adds, and in what order. I know what PX2.H (my hardware definition) does, it works. But I am unsure if I have the correct order. I know EXTEND adds lots of commands, but that's it. I know I have to add it in but don't otherwise know any more.
I want to get to a point where what is in the lower 32KB EEPROM can be loaded and run from an SD file by another program into hub, and run from there without needing any code residing in the lower 32KB of EEPROM. The upper 32KB of EEPROM is available for Tachyon.
I have updated my OS so that I can write out the EEPROM (lower or upper 32KB) to an SD file. The reverse was already available.
If I write out Tachyon lower 32KB to a file, program in my OS boot code, and the overwrite the EEPROM boot code with the previously saved EEPROM Tachyon boots and runs fine. But just loading the file into hub and executing it does not.
Can't help you with your mix-mode use of Tachyon but I can help you with BACKUP.
After EXTEND.fth is loaded it executes BACKUP unless you have changed this in EXTEND.fth
If you add any other modules or your own code you will need to BACKUP if you want them to be persistent between reboots.
Some modules have BACKUP embedded in them, I think EASYNET.fth does.
Guess what I really need is a step by step instruction guide to the few steps needed, and what each does. Eg I know what SDCARD and EASYFILE adds, and in what order. I know what PX2.H (my hardware definition) does, it works. But I am unsure if I have the correct order. I know EXTEND adds lots of commands, but that's it. I know I have to add it in but don't otherwise know any more.
The order is purely determined by dependencies, since it is compiled into memoy as it is received ... no declarations for subsequent loading. Since EXTEND doesn't require any user codes, it normally directly follows the boot code. SDCARD might use pin or board definitions, so I would do your PX2.H, then SDCARD, then EASYFILE, then ... whatever else builds on them. Whatever you have installed and initialized gets put up when you do BACKUP.... like a current snapshot of the system.
MJB,
Are you saying I need to do BACKUP before I do anything else, or after I load the other .FTH routines?
Currently away for extra long weekend. I didn't get far enough before I left to bother taking anything with me
Guess what I really need is a step by step instruction guide to the few steps needed, and what each does. Eg I know what SDCARD and EASYFILE adds, and in what order. I know what PX2.H (my hardware definition) does, it works. But I am unsure if I have the correct order. I know EXTEND adds lots of commands, but that's it. I know I have to add it in but don't otherwise know any more.
I want to get to a point where what is in the lower 32KB EEPROM can be loaded and run from an SD file by another program into hub, and run from there without needing any code residing in the lower 32KB of EEPROM. The upper 32KB of EEPROM is available for Tachyon.
I have updated my OS so that I can write out the EEPROM (lower or upper 32KB) to an SD file. The reverse was already available.
If I write out Tachyon lower 32KB to a file, program in my OS boot code, and the overwrite the EEPROM boot code with the previously saved EEPROM Tachyon boots and runs fine. But just loading the file into hub and executing it does not.
I should have read more closely.
Tachyon is not ready until EXTEND.fth is loaded, you should __always load EXTEND.fth before any user code until you are guru level in the kernel I believe. And yes as posted there are "cascading" dependences so you can't load EASYNET.fth before you load W5500.fth|W5200.fth|W5100.fth and EASYFILE.fth. You can't load EASYFILE.fth until you load SDCARD.fth.
so try this and post your errors if any please
EXTEND.fth
PX2.H
SDCARD.fth
EASYFILE.fth
BACKUP
MJB: what parts of EXTEND.fth do people modify to suit the hardware?
Hi Paul, EXTEND does not need to be modified nor should be, the same as all the rest of the modules, but you should load your hardware module after EXTEND. If you have defined !PCB in your hardware module then it will be executed automatically on startup when EXTEND.boot searches the dictionary for this string.
If you have a DS3231 or MCP79410 compatible RTC then you it should be covered by the RTC driver in EXTE3ND. Devices such as DS1307 and PCF85xx chips have the same basic register layout as the DS3231 except for a few minor differences.
Can I use THIS SP3485 485 transceiver chip with Tachyon 3.0?
Pretty much any chip will work. Short 2&3 together as the TE pin and 1&4 as the TR pin and ideally couple the TR pin to the Prop with a small resistor (100 to 330R) which just helps to prevent any I/O conflict. Also ideally you should have a pulldown of around 10k or so on the TE pin just to make sure it doesn't grab the bus while the Prop is reset or loading. But even so, without the resistors it will work.
BTW, I'm fixing some little bug that's crept into the 485 networking but I should have it sorted out soon.
That was my impression Peter, but I was curious after MJB's post
can you show your PX2.h ?
There might be dependencies with extend.fth, so it might need to be loaded before extend.
Cheers!
Sometimes you are pretty sure about s.th. but yu can not find the proof ... and sometimes you are just wrong ;-)
there is a little tricky thing with the realtime clock and the virtual real time clock, which I probably remembered wrong.
I went back to the oldest EXTEND I could find, but there is no IFNDEF DATE@ or IFNDEF TIME@ as I remembered.
Maybe somethiing was in an older version.
Some HW definition files like DS3231-RTC.fth also define an RTC
and EXTEND defines RTC functions and to prepare for a default where no HW RTC is there a virtual RTC is set up.
I was thinking the HW definition file goes first and EXTEND contains a IFNDEF to load the virtual RTC should no real one be there.
But it is handeled differently.
EXTEND always loads the virtual RTC and the HW module later redefines the words like DATE@ and TIME@ to use the HW RTC.
Since e.g. DS3231-RTC.fth does not use REVECTOR it also needs to redefine the words build on top of the TIME@, which would not or only be partially required if using REVECTOR.
But care has to be taken since other more high level words might be affected as well.
@Peter
END for example will still reuse the old .TIME and not the redefined HW one.
other dependencies I did not see so far.
So it's just a few bytes wasted by making the new RTC functions superceede the old ones. (I know we have plenty of bytes now ;-)
I'm trying to understand some of the code here and I'm looking for a description of what #P15 means. I find this in the glossary:
# Decimal prefix - " " i.e. #P26
So, I get it that '#' indicates a decimal number but what does the 'P' mean? Is #P15 just a synonym for decimal 15?
As long as a prefixed number ends in a digit it can contain any symbols excepting hex digits if it is a decimal prefix. So #P26 is always 26 decimal but it also helps us to read that as I/O pin P26.
So #P26 is fine, so is #PORT26 or #IO26 or #OUT26 but not #EN26 as that contains a valid hex digit. These are very simple rules and of course I could allow hex digits in a decimal number but the number processor has been kept fairly simple and it is more being less strict with what a number should look like.
%PORT0001_1010 . 26 ok
#PORT26 . 26 ok
#CS26 ??? ok
I'm trying to understand some of the code here and I'm looking for a description of what #P15 means. I find this in the glossary:
# Decimal prefix - " " i.e. #P26
So, I get it that '#' indicates a decimal number but what does the 'P' mean? Is #P15 just a synonym for decimal 15?
As long as a prefixed number ends in a digit it can contain any symbols excepting hex digits if it is a decimal prefix. So #P26 is always 26 decimal but it also helps us to read that as I/O pin P26.
So #P26 is fine, so is #PORT26 or #IO26 or #OUT26 but not #EN26 as that contains a valid hex digit. These are very simple rules and of course I could allow hex digits in a decimal number but the number processor has been kept fairly simple and it is more being less strict with what a number should look like.
%PORT0001_1010 . 26 ok
#PORT26 . 26 ok
#CS26 ??? ok
Thanks! I agree that #P15 makes it clearer that you're talking about a pin than just #15.
.
.
.
These are very simple rules and of course I could allow hex digits in a decimal number but the number processor has been kept fairly simple and it is more being less strict with what a number should look like.
%PORT0001_1010 . 26 ok
#PORT26 . 26 ok
#CS26 ??? ok
Right cause as some point (couldn't help that) the number processor will convert 123.456 to $42F6E979 and $42F6E979 to 123.456 for F32 sanity
I've been studying _NUMBER to see where this would be jammed in. Gonna need another prefix? Also been looking for an efficient routine to do the 2* the fractional part carry the 1, again.... to build the mantissa, yuck. Not gonna be to fast unless it's assembler but then not worried about speed over here.
Right cause as some point (couldn't help that) the number processor will convert 123.456 to $42F6E979 and $42F6E979 to 123.456 for F32 sanity
I've been studying _NUMBER to see where this would be jammed in. Gonna need another prefix? Also been looking for an efficient routine to do the 2* the fractional part carry the 1, again.... to build the mantissa, yuck. Not gonna be to fast unless it's assembler but then not worried about speed over here.
All being sorted out but I've been a bit busy on other things. I was thinking of specifying FP in the format 123456E-02 so that as long as _NUMBER sees an "E" and a sign in those places it will be accepted as FP. Now a simple number like 1234.56 could likewise be interpreted as floating point but that might be an unnecessary complication.
Once an FP number is read and converted it is simply data on the stack so conversion speed doesn't really matter.
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.
All being sorted out but I've been a bit busy on other things. I was thinking of specifying FP in the format 123456E-02 so that as long as _NUMBER sees an "E" and a sign in those places it will be accepted as FP.
.
.
.
Right E-02 type syntax, why didn't I think of that
FCREATE, I don't know if 4000 files @ 1Meg eack is gonna cut it for my next Prop1 embedded system, what are you kidding I can't find any 4Gig SD cards now locally, 8 Gig is the smallest with best pricing at 16Gig.
1. Compile & Program into EEPROM TACHYON3_rr001.spin (my 12MHz PLLx8 version) with bst
2. Setup TeraTerm for 115,200 8N1 and 20ms line delay
3. Sendfile EXTEND.FTH
4. Sendfile P8XBLADE2.H (my hardware: SD pins P12..P15)
5. Sendfile SDCARD.FTH
6. Sendfile EASYFILE.FTH
7. BACKUP
8. ?BACKUP
9. : BACKUP ;
10. : ?BACKUP ;
11. SAVEROM
Now I copied the lower 32KB of EEPROM to a file using my OS.
Then I programmed my OS into the lower 32KB EEPROM.
Then I ran a binary (the TACHYON binary saved from the lower 32KB EEPROM).
No Luck! Tachyon does not run. No response.
But if I reprogram the lower 32KB EEPROM from the saved Tachyon binary file and reboot, Tachyon runs fine.
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.
1. Compile & Program into EEPROM TACHYON3_rr001.spin (my 12MHz PLLx8 version) with bst
2. Setup TeraTerm for 115,200 8N1 and 20ms line delay
3. Sendfile EXTEND.FTH
4. Sendfile P8XBLADE2.H (my hardware: SD pins P12..P15)
5. Sendfile SDCARD.FTH
6. Sendfile EASYFILE.FTH
7. BACKUP
8. ?BACKUP
9. : BACKUP ;
10. : ?BACKUP ;
11. SAVEROM
Now I copied the lower 32KB of EEPROM to a file using my OS.
Then I programmed my OS into the lower 32KB EEPROM.
Then I ran a binary (the TACHYON binary saved from the lower 32KB EEPROM).
No Luck! Tachyon does not run. No response.
But if I reprogram the lower 32KB EEPROM from the saved Tachyon binary file and reboot, Tachyon runs fine.
Peter,
Is the above the correct sequence???
I can't see the effectiveness of a dummy BACKUP if the aim is not to have the EEPROM written thus keeping your OS intact. You would really want the equivalent of BACKUP for the SD card as BACKUP will maintain the cog images and not overwrite the cog image areas that were reused as buffers in RAM. But this is a bit hard to do since by the time the filesystem is active it has trashed those areas in RAM.
However that doesn't explain what isn't happening when you load directly into RAM vs EEPROM. What is different from a normal Prop boot. I know that normally the Spin interpreter is loaded into cog 0 on boot and it uses the headers in low memory to setup and run the main Spin file, in this case just a couple of lines of coginiting plus a baudrate setup, that should be it.
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.
1. Compile & Program into EEPROM TACHYON3_rr001.spin (my 12MHz PLLx8 version) with bst
2. Setup TeraTerm for 115,200 8N1 and 20ms line delay
3. Sendfile EXTEND.FTH
4. Sendfile P8XBLADE2.H (my hardware: SD pins P12..P15)
5. Sendfile SDCARD.FTH
6. Sendfile EASYFILE.FTH
7. BACKUP
8. ?BACKUP
9. : BACKUP ;
10. : ?BACKUP ;
11. SAVEROM
Now I copied the lower 32KB of EEPROM to a file using my OS.
Then I programmed my OS into the lower 32KB EEPROM.
Then I ran a binary (the TACHYON binary saved from the lower 32KB EEPROM).
No Luck! Tachyon does not run. No response.
But if I reprogram the lower 32KB EEPROM from the saved Tachyon binary file and reboot, Tachyon runs fine.
Peter,
Is the above the correct sequence???
7, 9 and 10 should not be needed.
8 does the backup only if there were no load errors, but 7 does an unconditional backup before wich makes no sense. so just keep 8
then 11 saves the EEPROM image you created with ?BACKUP to file
9 and 10 might be a protection against accidentally doing a backup later and destroying your OS.
so if you want this, then fine, keep it.
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?
To avoid confusion can we change the timer demo in the latest extend please. It no longer matches the current implementation
\ demo LED flasher which takes 5 seconds before it starts flashing every 100ms
DOUBLE blinktimer
WORD blinky
: BLINKY
#16 PIN@ 0= #16 PIN! \ toggle pin 16
blinky W@ blinktimer TIMEOUT \ reload timer
;
\ Setup the timeout vector for TIMER 0
' BLINKY 0 ALARM
\ Write a reload value to timer's memory which we can change anytime
#100 blinky W!
\ Setup timer 0 to timeout in 5 seconds
#5,000 blinktimer TIMEOUT
}
TO
\ demo LED flasher which takes 5 seconds before it starts flashing every 100ms
TIMER blinktimer
WORD blinky
: BLINKY
#16 PIN@ 0= #16 PIN! \ toggle pin 16
blinky W@ blinktimer TIMEOUT \ reload timer
;
\ Setup the timeout vector for this TIMER
' BLINKY blinktimer ALARM
\ Write a reload value to timer's memory which we can change anytime
#100 blinky W!
\ Setup this timer to timeout in 5 seconds
#5,000 blinktimer TIMEOUT
}
Comments
Great not even 10 minutes under version control and EXTEND.FTH is gonna change. No worries you did name the system Tachyon, Schrödinger might have worked well too
I presume it is not as simple as using the Tachyon V3.0 image as a file ???
ie I presume the commands I used to remove backup and add extend, etc changes the boot image that is stored on eeprom???
If it just a matter of me reading out the lower 32KB image to a file, I can add that part to my OS. I can already write a file to lower or upper eeprom.
If I program them into the eeprom, then Tachyon boots and runs fine. However, if I program my OS into the lower section and run the lower 32KB from an sd file, tachyon does not run.
Is there anything in the lower 32KB eeprom that Tachyon is checking, or do I have a bug in running the binary???
usuall this goes before EXTEND.
Since e.g. if you do not have a HW RTC you can specify a SW RTC in PX2 and EXTEND checks for this when loading.
So if you have a soft RTC this could potentially access EEPROM (low or high - depends on how you set it up), but I don'T think it should crash.
So maybe you want to use BACKUP, then save EE->SD,
then reload your OS to lower EE and then load lower 32k from SD->RAM ...
Are you saying I need to do BACKUP before I do anything else, or after I load the other .FTH routines?
Currently away for extra long weekend. I didn't get far enough before I left to bother taking anything with me
Guess what I really need is a step by step instruction guide to the few steps needed, and what each does. Eg I know what SDCARD and EASYFILE adds, and in what order. I know what PX2.H (my hardware definition) does, it works. But I am unsure if I have the correct order. I know EXTEND adds lots of commands, but that's it. I know I have to add it in but don't otherwise know any more.
I want to get to a point where what is in the lower 32KB EEPROM can be loaded and run from an SD file by another program into hub, and run from there without needing any code residing in the lower 32KB of EEPROM. The upper 32KB of EEPROM is available for Tachyon.
I have updated my OS so that I can write out the EEPROM (lower or upper 32KB) to an SD file. The reverse was already available.
If I write out Tachyon lower 32KB to a file, program in my OS boot code, and the overwrite the EEPROM boot code with the previously saved EEPROM Tachyon boots and runs fine. But just loading the file into hub and executing it does not.
Can't help you with your mix-mode use of Tachyon but I can help you with BACKUP.
After EXTEND.fth is loaded it executes BACKUP unless you have changed this in EXTEND.fth
If you add any other modules or your own code you will need to BACKUP if you want them to be persistent between reboots.
Some modules have BACKUP embedded in them, I think EASYNET.fth does.
can you show your PX2.h ?
There might be dependencies with extend.fth, so it might need to be loaded before extend.
I should have read more closely.
Tachyon is not ready until EXTEND.fth is loaded, you should __always load EXTEND.fth before any user code until you are guru level in the kernel I believe. And yes as posted there are "cascading" dependences so you can't load EASYNET.fth before you load W5500.fth|W5200.fth|W5100.fth and EASYFILE.fth. You can't load EASYFILE.fth until you load SDCARD.fth.
so try this and post your errors if any please
EXTEND.fth
PX2.H
SDCARD.fth
EASYFILE.fth
BACKUP
If you have a DS3231 or MCP79410 compatible RTC then you it should be covered by the RTC driver in EXTE3ND. Devices such as DS1307 and PCF85xx chips have the same basic register layout as the DS3231 except for a few minor differences.
Pretty much any chip will work. Short 2&3 together as the TE pin and 1&4 as the TR pin and ideally couple the TR pin to the Prop with a small resistor (100 to 330R) which just helps to prevent any I/O conflict. Also ideally you should have a pulldown of around 10k or so on the TE pin just to make sure it doesn't grab the bus while the Prop is reset or loading. But even so, without the resistors it will work.
BTW, I'm fixing some little bug that's crept into the 485 networking but I should have it sorted out soon.
Sometimes you are pretty sure about s.th. but yu can not find the proof ... and sometimes you are just wrong ;-)
there is a little tricky thing with the realtime clock and the virtual real time clock, which I probably remembered wrong.
I went back to the oldest EXTEND I could find, but there is no IFNDEF DATE@ or IFNDEF TIME@ as I remembered.
Maybe somethiing was in an older version.
Some HW definition files like DS3231-RTC.fth also define an RTC
and EXTEND defines RTC functions and to prepare for a default where no HW RTC is there a virtual RTC is set up.
I was thinking the HW definition file goes first and EXTEND contains a IFNDEF to load the virtual RTC should no real one be there.
But it is handeled differently.
EXTEND always loads the virtual RTC and the HW module later redefines the words like DATE@ and TIME@ to use the HW RTC.
Since e.g. DS3231-RTC.fth does not use REVECTOR it also needs to redefine the words build on top of the TIME@, which would not or only be partially required if using REVECTOR.
But care has to be taken since other more high level words might be affected as well.
@Peter
END for example will still reuse the old .TIME and not the redefined HW one.
other dependencies I did not see so far.
So it's just a few bytes wasted by making the new RTC functions superceede the old ones. (I know we have plenty of bytes now ;-)
Hope to retest it all tonight
TACHYON [~ FORGET PX2.fth pub PX2.fth ." P8XBlade2 HARDWARE DEFINITIONS 160724.0000 " ; --- Cluso's P8XBlade2 --- ( P8X32A PINOUTS ) #P15 |< == &SDCS '' SDCARD CS #P14 |< == &SDDI '' Data to SDCARD #P13 |< == &SDCK '' SDCARD clocks #P12 |< == &SDDO '' Data out from SDCARD &SDCS >| #24 SHL &SDDO >| 16 SHL OR &SDDI >| 8 SHL OR &SDCK >| OR == SDC ( PCB DEFINITIONS ) \ Do what we need to do to init the hardware on this pcb pub !PCB &SDCS OUTSET ; " P8XBlade2" 0 STRING PCB$ #8888 == PCB ]~ ENDAs long as a prefixed number ends in a digit it can contain any symbols excepting hex digits if it is a decimal prefix. So #P26 is always 26 decimal but it also helps us to read that as I/O pin P26.
So #P26 is fine, so is #PORT26 or #IO26 or #OUT26 but not #EN26 as that contains a valid hex digit. These are very simple rules and of course I could allow hex digits in a decimal number but the number processor has been kept fairly simple and it is more being less strict with what a number should look like.
I've been studying _NUMBER to see where this would be jammed in. Gonna need another prefix? Also been looking for an efficient routine to do the 2* the fractional part carry the 1, again.... to build the mantissa, yuck. Not gonna be to fast unless it's assembler but then not worried about speed over here.
All being sorted out but I've been a bit busy on other things. I was thinking of specifying FP in the format 123456E-02 so that as long as _NUMBER sees an "E" and a sign in those places it will be accepted as FP. Now a simple number like 1234.56 could likewise be interpreted as floating point but that might be an unnecessary complication.
Once an FP number is read and converted it is simply data on the stack so conversion speed doesn't really matter.
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.
FCREATE, I don't know if 4000 files @ 1Meg eack is gonna cut it for my next Prop1 embedded system, what are you kidding
Tried the following...
1. Compile & Program into EEPROM TACHYON3_rr001.spin (my 12MHz PLLx8 version) with bst
2. Setup TeraTerm for 115,200 8N1 and 20ms line delay
3. Sendfile EXTEND.FTH
4. Sendfile P8XBLADE2.H (my hardware: SD pins P12..P15)
5. Sendfile SDCARD.FTH
6. Sendfile EASYFILE.FTH
7. BACKUP
8. ?BACKUP
9. : BACKUP ;
10. : ?BACKUP ;
11. SAVEROM
Now I copied the lower 32KB of EEPROM to a file using my OS.
Then I programmed my OS into the lower 32KB EEPROM.
Then I ran a binary (the TACHYON binary saved from the lower 32KB EEPROM).
No Luck! Tachyon does not run. No response.
But if I reprogram the lower 32KB EEPROM from the saved Tachyon binary file and reboot, Tachyon runs fine.
Peter,
Is the above the correct sequence???
great, this allows it now to save EEPROM images any time on any SD card at hand.
However that doesn't explain what isn't happening when you load directly into RAM vs EEPROM. What is different from a normal Prop boot. I know that normally the Spin interpreter is loaded into cog 0 on boot and it uses the headers in low memory to setup and run the main Spin file, in this case just a couple of lines of coginiting plus a baudrate setup, that should be it.
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.
7, 9 and 10 should not be needed.
8 does the backup only if there were no load errors, but 7 does an unconditional backup before wich makes no sense. so just keep 8
then 11 saves the EEPROM image you created with ?BACKUP to file
9 and 10 might be a protection against accidentally doing a backup later and destroying your OS.
so if you want this, then fine, keep it.
TO