2 megabyte CODE memory for the Propeller

APStech-Attila

Hi!

·I am working on extending the code memory size·of the propeller. The reason is there are several complex applications where it is very easy to separate the·application to several tasks.··(eg. application: simple scope with VGA·display.
··· - Main menu
··· - VGA bitmap display,
··· - VGA hi-res text display with measurement data,
··· - TTL analyzer with serial data analyzer,
··· - Sweep generator etc. etc.)

·Only the VGA display would consume 6600 longs, so not too much can fit beside VGA. If you want text/graphics the easiest solution should be exchanging the complete boot EEPROM and rebooting the Propeller. This is not an option for me .

·I would like to transfer (in assembly) 32kbyte EEPROM image from external memory (4 to 16 megabit FLASH) to the RAM and run the new code from the "secondary boot COG" assembly. (It is possible to reserve a few words for intertask data transfer at the end of internal·RAM)·Naturally I will stop all cogs during bootload, and there will be no uncontrolled write/SPIN code execution during "secondary boot".

· Hope Chip can give us a hint how the first SPIN token gets executed after "primary boot" with the ROM·bootloader.

·Thanks
·· Attila



Post Edited (Attila) : 7/14/2006 11:47:07 AM GMT

Kaos Kidd

Attila:
Well, if you write an assembly to use the i2c protocall from the flash into ram (which is what I think your talking about), Just exclude the ram where your "intertask data" is kept at.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

APStech-Attila

Dear KK,

Kaos Kidd said...
Attila:
Well, if you write an assembly to use the i2c protocall from the flash into ram (which is what I think your talking about), Just exclude the ram where your "intertask data" is kept at.

This is what I already have (HighSpeed, HighCapacity·SPI FLASH) . The bytes are transferred from the FLASH to the RAM, but I do not know how to start the·SPIN code @$10 from assmebly. After filling the RAM I should start the newly loaded code like the built-in boot loader does.

Kaos Kidd

THinking about it, Chip posted some of thin information in a thread for the non windows users.
It's got something to do with the return address thats set into your assembly code that will cause it to start executing when your assembly ends
... I'm fairly sure of this, but not 100%...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

cgracey

Here's what you do to launch a Spin program that is completely loaded into memory:

'
' Start up oscillator and begin Spin program at $0010
' (assumes EEPROM data already loaded into $0000-$7FFF)
' (assumes currently running RCFAST oscillator)
' (assumes this is COG 0 - gets rebooted)
'
······················· rdbyte· address,#$0004········· 'if xtal/pll enabled, start up now
······················· and···· address,#$F8··········· '..while remaining in rcfast mode
······················· clkset· address

:delay················· djnz··· time_xtal,#:delay······ 'allow 20ms @20MHz for xtal/pll to settle

······················· rdbyte· address,#$0004········· 'switch to selected clock
······················· clkset· address

······················· coginit interpreter············ 'reboot cog with interpreter


time_xtal·············· long··· 20 * 20000 / 4 / 1····· '20ms (@20MHz, 1 inst/loop)
interpreter············ long··· $0001 << 18 + $3C01 << 4 + %0000

address················ res···· 1

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Kaos Kidd

Ok, I was off base here.
But there was something about the return address in the assembly... really... I'm not ...
Maybe that was returning to the existing spin program from assembly...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Mike Green

There was a comment about an address ($FFF9 or something similar) being pushed onto the SPIN stack initially and that this points to a set of 3 bytes that get interpreted as "cogstop(cogid))". That's why there's no END in a SPIN program.

cgracey

The COGINIT INTERPRETER instruction reboots the same COG with the Spin interpreter. That's why there are no more instructions after the COGINIT. A whole new program will be running, instead.

Kaos Kidd said...
Ok, I was off base here.
But there was something about the return address in the assembly... really... I'm not ...
Maybe that was returning to the existing spin program from assembly...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 7/15/2006 3:41:13 PM GMT

Mike Green

Chip,
What is the meaning of the PAR value for the interpreter ($0001<<2 here)? Is it simply the address of the CLKSET value? Are there other "useful" values passed. I assume that when someone does a SPIN cognew(), there's an initialized stack (with any parameters pushed and a return to a cogstop(cogid)) with an initial stack address and an entry point address. Anything else?
Mike

cgracey

The interpreter loads 5 word pointers·on startup that it uses to set up the Spin program's operation. The long address passed to PAR ($0004 in this case)·points to the word before the 5 words that matter. This is because the pointer gets pre-incremented by 2 before it is used within the interpreter. So, byte[noparse][[/noparse]$0004] gets used for CLKSET and byte[noparse][[/noparse]$0005] gets used to store a checksum during initial downloading. It's the 5 following words that span $0006 to $000F that hold the pointers that·the Spin interpreter needs on startup.

Mike Green said...
Chip,
What is the meaning of the PAR value for the interpreter ($0001<<2 here)? Is it simply the address of the CLKSET value? Are there other "useful" values passed. I assume that when someone does a SPIN cognew(), there's an initialized stack (with any parameters pushed and a return to a cogstop(cogid)) with an initial stack address and an entry point address. Anything else?
Mike

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

CJ

this is getting to be very much like the multibank stamps, now if only you could set aliases for ram locations so you could access them by name rather than have to retype every byte/word/long command
kinda like pbasic "cat var W12"

the only problem I can see with it would be if you used the end it could possibly get clobbered by an active stack

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

Rob7

I may be thinking in the wrong direction,

Has anybody, or is someone thinking of useing the low power SD data logger to fetch memory for any·cogs to read,·just throwing ideas out there?

The SD Data Logger @ ··http://www.sddatalogger.com/

????

Rob7

Mike Green

Yes, I was going to work with one next week. I mostly plan to use it for text storage, but may experiment with moving programs back and forth from serial EEPROM. I think it's really too slow for loading programs, but maybe the combination of the SD data logger and an extra serial EEPROM might do the trick.

Rob7

Great,



By useing it for extra text storage: ie EEPROM data, the possibilities may·be endless. It would make for some interesting experiments ?

Rob7

Mike Green

Well, I did forget that this really is a data logger and you can't delete or overwrite files using it. It does work very nicely with the Propellor. I've attached a Propellor version of the test program for the Stamp that's included with the Logger.

I'm waiting for delivery of a USBwiz which is on backorder until early August. That's a general purpose interface for SD/MMC cards and USB devices like "thumb drives". It does have the ability to interface via SPI and I2C as well as asynchronous serial. I suspect I'll use I2C since that way I'll need only one driver, it's high speed, and clocked (for reliability at high speeds), yet it uses only 2 pins that, if they were accessible on the demo board, could be shared with the boot EEPROM.

In the meantime, I've got a bunch of 64Kx8 EEPROMs I can use to experiment with an overlay loader system.

Mike Green

For those that might be interested, here's a test program that copies the boot eeprom into a 32K segment of another external eeprom, then verifies the copy against the boot eeprom. It does run, but I haven't extensively tested it. It demonstrates sequential reading of an eeprom (which is faster since you don't supply an address for each byte) and paged writing of an eeprom (also without addresses for each byte, but, importantly, the write doesn't get initiated until the end of the block of data). I'm using 2 - 24LC512 eeproms with the address of the second wired as %01, but anything at least 32K x 8 in size will work.

Included in the archive is a modified version of the i2cObject which is necessary to access the boot eeprom on the demo board (no pullup on the clock line). The standard i2cObject will work with the PropellorStick and "home-brew" systems with both pullups on the boot eeprom.

Next step is to redo the I2C object in assembly.

sharpie

For SD and even CF reader/writers, these guys have a great solution... Work great with the prop.. Not sure if they'd fit into this but since it was mentioned I thought I'd share...
http://www.comfiletech.com/index.asp?PageAction=VIEWCATS&Category=7
Specifically- http://www.comfiletech.com/index.asp?PageAction=VIEWPROD&ProdID=79

APStech-Attila

Thanks Chip. This is exactly what I need. I will keep testing and post the code as soon as I will be ready.

Chip Gracey (Parallax) said...

Here's what you do to launch a Spin program that is completely loaded into memory:

'
' Start up oscillator and begin Spin program at $0010
' (assumes EEPROM data already loaded into $0000-$7FFF)
' (assumes currently running RCFAST oscillator)
' (assumes this is COG 0 - gets rebooted)
'
·

APStech-Attila

Hi!

· Anyone interested in bootloading @ 4MBPs? (code is up and running in less than 80msec!) Size of codespace? Nearly unlimited!

· You will only need a W25P40 SPI FLASH preloaded with BootEEPROM images, and the attached FLASH OS.spin! (50 Cents / FLASH)

··This thing·works really simple: A complete·BootEEPROM image is copied into the FLASH attached to the PChip (with the Xmodem.spin I have posted earlier). In a Spin program you should invoke : FLASH.LoadCode(DI, DO, CS, CK, IndexOfBootimage).·// There are 16 longs intact during bootload at the end of codespace, so you can interchange data between applications //

· The whole thing behaves like "programatically swapping boot EEPROMS" and pressing the Reset button.

· You can give it a test run on my P8X32 DIP demo BOX demoboard·(·Can ship only inside EU )

· The development of a "DOD Shell" like enverionment is on the way, utilizing FOS, TV, Mouse. I will post pictures in a few days.

Best regards,

· Attila

··