Phase1. PASM-HUB-loader (PHL)
1. Allocate 2K of HUB DAT for COG load swap space.
2. <2K HUB initially holds PASM loader.
3. PASM loader includes EEPROM read code.
4. PASM loads HUB and starts each COG.
5. Spin uses 2K for Heap or other purposes.
Phase2. PASM-HUB-loader (PHL)
1. PASM stub loader and COG load swap space in hub (target total <0.5KB)
2. PASM loader includes EEPROM read code.
3. PASM loads COG and starts each COG.
@Carl: I gather from your eeprom code, that a read may begin at any byte offset, and may be of any length. Is this correct?
Do you know how many clocks it takes to read a byte?
Impact table B2: No cogs are wasted. Only the cog to be loaded is used to load itself and then execute and no cog space is required (it is reused via zero footprint shadow ram $1F0-1F3).
All coginit/cognew etc instructions work exactly as they do now, except the user points to a table instead of the real start address. PAR is as per normal. The table holds the real address (in eeprom) and its length, and is followed by the cog eeprom load code. This loads the cog (up to 496 longs) and then executes the loaded code at $000. The only issue is that the loading will be slower, and if multiple cogs are being loaded from eeprom, they will be queued and so will be slower to boot.
Carl: Would you like to do for me the pasm code (routine) to read a block of eeprom (from upper 32KB) into hub or cog? I will preset 2 longs, 1 with the 18 bit eeprom start address. Bits 17-15 will be set "001" indicating 2nd 32KB block being 32KB-64KB. This allows for later expansion. Bits 14-0 will indicate the byte offset within the block. The other long will be preset with the length in bytes (I will convert from longs). Is this the best way???
@Cluso99: My I2C routines are as slow as a wet week. The contents of the EEPROM are loaded out at a baud rate of about 20000 bits per second. I'll probably not be persuing the loader algorithm any further, as what I was really interested in was process. In my own mind I have established a process that works and that is not a whole lot more difficult than the existing process for code development.
The only changes I'll probably make are to have a long word at the start of each high EEPROM object PASM block which consists of:
1) A word which tells how many bytes of code are stored - to cut loader time
2) A word which is a sum of all the bytes in the object
I might also think about adding another long that's an object signature. "JDCS" = JDCogSerial? But I'm really not too concerned about this.
Reads from EEPROM memory can be continuous, although it generally falls apart if you try and cross a 32K boundary. There may be cases where a continuous read is not permissable, but I'm not aware of any. There are excellent PASM routines for I2C available in the obex, and I would suggest these be investigated, as the SPIN bit-bash code I presented does not require any speed throttling - something which is absolutely essential when writing PASM based I2C. Great insight can be gained from studying the I2C code presented in FemtoBasic.
The loss of 2K of HUBRAM to the loader is not a problem for me as I generally need that amount of RAM for SD Card buffers, Ethernet buffers and other general buffering. (VGA Buffers?)
Please not that a lot of my code is an adhoc mixture of Forth, spin and PASM. The loader I've presented could just as easily be written in Forth - except that for that I first need a Forth kernel which I plan to store in high EEPROM. In Forth I can do bit-bash I2C at about 80000 bits per second without resorting to in-line PASM, which is probably as fast as I'd want to go with generic EEPROMs. If startup time becomes an issue I'll do further investigation (ie code writing) later.
Regards,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Carl Jacobs
JDForth - Forth to Spin Compiler http://www.jacobsdesign.com.au/software/jdforth/jdforth.php
Includes: FAT16 support for SD cards. Bit-bash Serial at 2M baud. 32-bit floating point maths.·Fib(28) in 0.86 seconds. ~3x faster than spin, ~40% larger than spin.
I've started on the I2C routines (using Chip's booter.spin as the I2C basis). I've updated to 128 byte pages (was 64) and using the upper address of $8000-$FFFF in eeprom. It is in pasm, but timing is using the RC oscillator, so once working I can speed it up. I am only checking it for the AT24C512 at present.
Cluso99 said...
I've started on the I2C routines (using Chip's booter.spin as the I2C basis). I've updated to 128 byte pages (was 64) ...
If you're reading, then this will be fine. If you're writing, then beware! There's a reason that both Chip and myself are using 64 byte blocks - it is all that some EEPROM devices will support.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Carl Jacobs
JDForth - Forth to Spin Compiler http://www.jacobsdesign.com.au/software/jdforth/jdforth.php
Includes: FAT16 support for SD cards. Bit-bash Serial at 2M baud. 32-bit floating point maths.·Fib(28) in 0.86 seconds. ~3x faster than spin, ~40% larger than spin.
Comments
Phase1. PASM-HUB-loader (PHL)
1. Allocate 2K of HUB DAT for COG load swap space.
2. <2K HUB initially holds PASM loader.
3. PASM loader includes EEPROM read code.
4. PASM loads HUB and starts each COG.
5. Spin uses 2K for Heap or other purposes.
Phase2. PASM-HUB-loader (PHL)
1. PASM stub loader and COG load swap space in hub (target total <0.5KB)
2. PASM loader includes EEPROM read code.
3. PASM loads COG and starts each COG.
No other cogs used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Do you know how many clocks it takes to read a byte?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Impact table B2: No cogs are wasted. Only the cog to be loaded is used to load itself and then execute and no cog space is required (it is reused via zero footprint shadow ram $1F0-1F3).
All coginit/cognew etc instructions work exactly as they do now, except the user points to a table instead of the real start address. PAR is as per normal. The table holds the real address (in eeprom) and its length, and is followed by the cog eeprom load code. This loads the cog (up to 496 longs) and then executes the loaded code at $000. The only issue is that the loading will be slower, and if multiple cogs are being loaded from eeprom, they will be queued and so will be slower to boot.
Carl: Would you like to do for me the pasm code (routine) to read a block of eeprom (from upper 32KB) into hub or cog? I will preset 2 longs, 1 with the 18 bit eeprom start address. Bits 17-15 will be set "001" indicating 2nd 32KB block being 32KB-64KB. This allows for later expansion. Bits 14-0 will indicate the byte offset within the block. The other long will be preset with the length in bytes (I will convert from longs). Is this the best way???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
The listings are from the homespun022 compiler.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
The only changes I'll probably make are to have a long word at the start of each high EEPROM object PASM block which consists of:
1) A word which tells how many bytes of code are stored - to cut loader time
2) A word which is a sum of all the bytes in the object
I might also think about adding another long that's an object signature. "JDCS" = JDCogSerial? But I'm really not too concerned about this.
Reads from EEPROM memory can be continuous, although it generally falls apart if you try and cross a 32K boundary. There may be cases where a continuous read is not permissable, but I'm not aware of any. There are excellent PASM routines for I2C available in the obex, and I would suggest these be investigated, as the SPIN bit-bash code I presented does not require any speed throttling - something which is absolutely essential when writing PASM based I2C. Great insight can be gained from studying the I2C code presented in FemtoBasic.
The loss of 2K of HUBRAM to the loader is not a problem for me as I generally need that amount of RAM for SD Card buffers, Ethernet buffers and other general buffering. (VGA Buffers?)
Please not that a lot of my code is an adhoc mixture of Forth, spin and PASM. The loader I've presented could just as easily be written in Forth - except that for that I first need a Forth kernel which I plan to store in high EEPROM. In Forth I can do bit-bash I2C at about 80000 bits per second without resorting to in-line PASM, which is probably as fast as I'd want to go with generic EEPROMs. If startup time becomes an issue I'll do further investigation (ie code writing) later.
Regards,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Carl Jacobs
JDForth - Forth to Spin Compiler http://www.jacobsdesign.com.au/software/jdforth/jdforth.php
Includes: FAT16 support for SD cards. Bit-bash Serial at 2M baud. 32-bit floating point maths.·Fib(28) in 0.86 seconds. ~3x faster than spin, ~40% larger than spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Carl Jacobs
JDForth - Forth to Spin Compiler http://www.jacobsdesign.com.au/software/jdforth/jdforth.php
Includes: FAT16 support for SD cards. Bit-bash Serial at 2M baud. 32-bit floating point maths.·Fib(28) in 0.86 seconds. ~3x faster than spin, ~40% larger than spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz