boot from an µSD card, (desired hardware)
Fred Hawkins
Posts: 997
Two cents tossed into the fountain.
Wouldn't it be nice (interesting, useful) to have a version of the·propeller chip that booted·from an µSD card instead of looking for an eeprom? And to·give the IDE·the option of putting the binary to 'the proper place' on the µSD card?
·
Wouldn't it be nice (interesting, useful) to have a version of the·propeller chip that booted·from an µSD card instead of looking for an eeprom? And to·give the IDE·the option of putting the binary to 'the proper place' on the µSD card?
·
Comments
anyway, and it seems unfortunate to require an EEPROM in addition. This may also speed boot time
(which is a problem in the current chip, and potentially more so in the newer one).
Of course I'm not sure how the signaling would work. Currently we check for EEPROM and for
external serial both. Hmm . . .
It would be easy to write a program using Rokicki's FAT file routines that would just load a program with a particular name from an SD card. That's what would reside in the EEPROM.
Can we get uSD Card booting into the Prop v2? From what I understand, it first executes code from masked rom in the chip, and then boots from serial, failing that boots from I2c eeprom.
It would be a lot handier, in my opinion to load from a specified file on a FAT16 or FAT32 filesystem. I don't know if you have enough mask rom to do this, but it would be quicker than chain loading a eeprom then SDCard.
I also do not really understand the bit packing stuff. Is there a good document on this?
By bit packing I am referring to the object that loads a prop from another prop and the Delphi code presented by(I can not remember what staff member at the moment)Parallax in one of these threads. I have looked at it and I can sort of understand how it is loading, but to attempt to mimic that on a pic is over the rainbow for me! I really don't have the dev time·right now, but I try to keep up with the documentation as it is presented!
The download process is not a very easy process to understand. There are really two major issues:
1) The Propeller is running off its internal clock during the boot process and can't produce a known Baud, so it has to use a technique that's not dependent on knowing what Baud is being used by the PC. The start bit of the serial character frame is always a logic zero. By using a cell of 3 bits, you can represent a zero with a 0, 0, 1 and a one with a 0, 1, 1 (with the zero first). Three bits can be represented in a single 10 bit serial character frame (start bit, LSB, ... MSB) like cccbbbaa with the start bit being the first "a" bit. You can also send only a single bit in a character frame.
2) The Propeller and the PC have to negotiate an identification sequence. There's a sync character, then 250 pseudo-random bits from a LFSR. The Propeller has to respond with the next 250 bits and the chip version. The PC then sends a command, then the download data if needed. Some of this information is sent one bit at a time and some of it is packed 3 bits per byte (from the PC).
You mentioned 3 bits per 10 so is this right.
First byte of data is say $55 would be: 0011001011 for the first 3 bits and then what?
····················································· ,1· ,2· ,3
Do we pause and· start a new set with the remaining one bit of the LSB and two bits of the MSB or do we just continue until the whole byte is sent?
If 10 bits is a character frame and 10 bits can get 3 bits of data across how is only 1 bit transferred in a character frame?
Right, Mike?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
http://forums.parallax.com/showthread.php?p=591445
It is really a 9 bit frame, because the stop bit does not convey any information. It just has to be there to separate from the next start bit. One is a pulse of length t ((high level on the RS232 line=logical 0) and zero is a pulse of length 2t. The RS232 line is normally in marking state=1. So the sequence to send 8 bits of $55=%01010101, lsb first would be something like this, reading left to right in three bytes separated by lots of stop bits:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Let's say you wanted to send a byte $5A / %01011010
The first thing is to convert each bit to a three bit symbol ( 0 -> 001 / 1 -> 011 )
01011010 -> 001 011 001 011 011 001 011 001
Then three 3-bit symbols are concatenated to create 9-bit symbols
001 011 001 011 011 001 011 001 -> 001011001 011011001 011001...
Each of these 9-bit symbols are sent as a byte using 'normal UART-style' serial with the leading zero conveniently being the start bit, the remaining eight bits being the 'byte' data of the character sent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
The PC may send them. When you configure a UART to send one stop bit, it guarantees there's at least one stop bit. If you configure it to send two stop bits, it guarantees at least two stop bits. If the PC is busy for some reason or is slow to supply characters to the UART, it (the UART) fills in with more stop bits since a logic high is the idle state of the communications line.
Also, you'll notice that the responses from the Prop to the PC are all single bits
The original question posed was the most interesting and I thought to get back to that.
I’ve been doing some work with one of the new uOLED-96-PROP displays this evening and it occurred to me that most of the pieces are there to do what Fred asked if I knew more about the load/run process “after” the EEPROM was loaded.
I’m curious to know, from the Prop experts here,·if the following could be made to work:
1---Load the program you wanted to save·into RAM and EEPROM.
2---Load and run a small “saver” program into RAM that would write the contents of the EEPROM, containing the previously loaded program, to the uSD card. Multiple programs could be saved by repeating the above steps and writing each successive program with a 32K offset on the card I guess.
3---When you’re ready to run one of the saved programs, load and run a “loader” program that would read the EEPROM “image” from the uSD card and write it to RAM.
4---Reset the Prop and run the loaded program.
There may be any number of reasons why the above won’t work and I don’t see them because I don’t know enough about what the Prop expects to see when it starts up from a reset and where the program code needs to be.
With a Prop chip, display and uSD card, the uOLED-96-PROP would provide all the requisite hardware to do what Fred proposed. It would be up to the programming wizards here to sort out just how to get it to work. Using the display to provide a menu for saving and loading more than one program on the card would be great.
I know from talking with Atilla at 4D Systems that one of the reasons for putting the uSD card on the 96-PROP was for storing Propeller programs as well as images and data. He said to me that it probably wouldn’t take the Propeller users long to come up with a way to do all those things and more.··
Duffer
All of what you ask is doable. FemtoBasic now does all of that using an ordinary SD card accessed via SPI. It looks like the existing loader could be trivially modified to work with the uSD card on the uOLED-96-PROP and that can be incorporated into other programs. For that matter, Rokicki's FAT file system routines could also be used and the uSD card used with an adapter on a PC to directly store compiled programs on the card using the Propeller Tool.
For that matter, it would be easy to incorporate the uOLED-96 display driver into FemtoBasic. The only question would be whether to also include the PS/2 keyboard driver and make a little box that only needs a PS/2 keyboard to have a complete Prop system that could also run stand-alone if there's no keyboard attached. FemtoBasic has the ability to automatically run a Basic program off the attached SD card and this program can run completely independent Spin programs off the SD card. Currently, FemtoBasic checks to see if there's a keyboard attached and won't continue if not. It could be easily modified to run a specific Basic program if there's no keyboard (and properly inhibit keyboard input statements).
Post Edited (Mike Green) : 10/7/2007 4:34:41 AM GMT
I think the initial question from Fred was, how - if ever - you can substitute the EEPROM by a SPI device, to save the additional expenditures for an EEPROM
No, was the answer.
With the exception of an interpretor between the Prop and uSD was the solution.
Maybe it does't belong in this thread, I would be happy to start another if that is the general opinion here!
Ps. Thank you Tracy, I would like to persue this farther, It just might not be the right place!
Post Edited (bambino) : 10/7/2007 11:21:39 AM GMT
What would the propeller environment be like if we just programmed it with a SD card that we moved from the pc to the prop? (Skip the cord, if you want) I guess we'd quickly find uses for up to 4G of storage. And swapping out cards to change programs. [noparse][[/noparse]Mike suggests that we need to use the FAT to let the pc write to the card, but as I understand things, 4D shows a way around that -- we could let the propeller do all of the writing; the data could just come down the usb cord. And visa versa. But really, why not do a FAT-aware boot?]
That aside, I think I was also gently shifting the forum viewpoint from looking for serial bus eeprom solutions (which feel like wearing buckets on one's feet. Ready, set, hobble.) And more properly, gently nudging Parallax to take the Propeller out of the boonies and get into a bit higher gear. What would this forum (and our group enterprise here) look like if the prop had spent the last year (and a half?) on a platform that had started out with µSD cards? At least someone at Parallax would have spent some time working up a method.* It bothers me that the quickest and best way to get µSD cards working now is in 4D's oled units, much as I like them. The propeller doesn't really need all that much hand holding.
Lastly, I think it's fine that the debate also takes in the boot code as it exists now. Might as well, its the only option we have.
Fred
* water under the bridge. I know they have been busy getting the prop ROG and I don't want to start a blame game. All I am suggesting is that there may be an alternative worth thinking about.
Post Edited (Fred Hawkins) : 10/7/2007 11:51:37 AM GMT
deSilva has kindly reposted an explanation of the bit packing in another thread and you just resounded what was confusing me! All we really need to do is interface with the eeprom. If uSDs had an I2C interface the problem would disappear! Let the prop do its own writting of program code. And once formatted A uSD could accept raw data· to its first 32k, and the SD routines could put that in fat format after boot possibly.
Again, the issues for Parallax (looking as an outside observer) are that SPI requires at least 3, usually 4 I/O pins while I2C requires only 2 pins and those can be used for other devices. With SPI, one of the I/O pins is dedicated to a single device. The other piece is that much of the advantage of using SD cards is their PC compatibility ... they can be inserted into any PC now and are expected to appear just like any other disk drive to the user. Unfortunately, that requires a specific file system structure on the SD card and, even where the device is not expected to create any new files, it takes a lot of code just to look up a specific file by name and locate its area on the drive. Admittedly, there will be more ROM on the Prop 2. Is this how we (as buyers) would like the ROM space used? Would it not be better to continue with the I2C boot convention and have standard FAT file system loader support that can be installed by default in the attached EEPROM? It would certainly help for the Propeller Tool to have better support for other kinds of media attached to the Propeller. If the Propeller Tool had the right scripting hooks built in, it could download any "helper" program to RAM, then download the program just compiled with the "helper" program doing the writing to an SD card or flash EEPROM or whatever and make it feel seamless from the user's perspective.
In order for this to be feasible, there must be *some* file system support somewhere in the Prop 2,
along with *somewhere* to store those files. And if those files are to be interchangeable with others,
easily, then writing them somewhere in a PC-compatible way may not be a bad idea.
So I think built-in support for SD is along the lines that Chip *may* be thinking, and if that is the
case, it's a very small jump to actually *booting* off the SD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
So, before the IDE shoved into the prop, I would still like the µSD card interface. Today I'm thinking let's do a both-and. In other words, our current boot failure case goes off looking for an µSD card. If you find it, try booting. If you don't brownout.
I don't see any particular reason why we can't be using the same set of 4 pins (28,29,30,31). Just arrange the SD card interface so it fails·the RAM load and·the eeprom load.
Post Edited (Fred Hawkins) : 10/10/2007 12:02:56 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.