Regarding "compile from RAM" in the Prop Tool or its successor, as potatohead mentioned, here are the alternatives:
1. Compile from RAM without saving to disk.
2. Create a backup file upon loading, and autosave the Top Level program to disk before compiling from disk.
3. Create a backup file upon loading, and autosave the Top Level program and all affected, open objects to disk before compiling from disk.
4. Require an explicit save to disk before compiling from disk if changes were made.
5. Compile from disk, ignoring changes in RAM.
The Prop Tool uses #1, and I like it, although it lacks the security of an autosave in case of a system crash. When I'm programming in Perl, UltraEdit uses #2, autosaving only the top-level program but not any called modules. Since I'm seldom editing external modules, it works fine. #3 might be better for Spin -- at least for people who write and edit their own objects. #4 and #5 are non-starters, IMO. BTW, one essential menu command the Prop Tool omits is "Revert". Every editor should have it.
-Phil
I really like how things now just compile from RAM. You don't save anything until you want to. Having an automatic archive made each compile wouldn't be bad, if it used a FIFO list of names in a directory that is constant (like maybe where the IDE resides) to make a recent history, but spewing files all over the work directory with different extension names is the bane of modern IDE's. I really hate that. You go to backup what is important and you are wading in a sea of detritus. Ideally, your work directory should only have source files in it, or at least ones that YOU put there.
I agree with pedward in that the current implementation is clean. My objection to this change would be the loss of code that "just works" As soon as that line is broken, lots of code will target the niche, significantly reducing how "clean" the Propeller really is. IMHO, that's a core strength I would not want to see impacted for some niche cases that can very easily be dealt with in other ways, or frankly on P3, which should scale to a point where we are not talking micro-controller type devices anymore.
That's the problem, fitting multiple threads in is more than just having the space when it comes to the drivers. Timing is often very important while at the same time the mips is often way over the top for the driver using that Cog, and nothing else can use it. Four way slicing provides an opportunity to have effectively up to 32 low latency Cogs and still give out full mips between them. Where as task switching is an either-or situation.
While this implementation may be flawed, it isn't going to be a different design in the supposed Prop3 - Assuming the supposed Prop3 goes for compatibility that is, the Prop3 will just have the flaw removed. It'll still able to run the same "sliced" driver software that was written for the Prop2. Newer software after that can make use of the fact that the flaw is gone and be more efficient and precise.
I wonder what Ken thinks of all the enthusiasm for the Prop3 being just around the corner?
... but spewing files all over the work directory with different extension names is the bane of modern IDE's.
True enough. That's the one aspect of UltraEdit that bugs me a little. OTOH, since they are in the work directory, the .bak files get captured during my daily backup. BTW, UE writes over previous .bak files on LOAD, so at least the work directories don't grow ad infinitum.
If Yours SDRAM interface with initializing of it Can initialize SDRAM and have auto refresh
Then with separate state machine to --- RDxxxx / WRxxxx instructions them can handle read write SDRAM as SLOW HUB-RAM still with predicable timing.
Only use more time to read/write one LONG
To that addressing need know as all addresses that are bigger as HUB -RAM space are SDRAM and shall handles differently in theirs state machine..
Ps. That opens runing LMM type programs directly from SDRAMS and much more.
I thought about this, but the protocol for dealing with an SDRAM is not simple. There are quite a few commands that must be fed to it, and data turns around over maybe 10 clocks. Plus, you have to have some refresh strategy that involves various trade-offs with bank-selection. I think this belongs on the software domain for the Prop.
That is true for cog-2-hub communication. What about cog-2-cog through the port D. Perhaps we can have a master cog owning 4 slave processes in the neighbor cog
You guys have good memory. Yes, you could single-cycle access the port D, or better yet, use the XCH mechanism where each cog can post a whole long and every other cog can receive it. This would afford a single-cycle mechanism for data transfer among cogs, but would involve some handshaking for more than one long, unlike hub RAM.
I like the Propeller for it's Spin/Pasm not that it can do C. I know the new platform is going to be open, I just wish I had the smarts to customize it for Spin/Pasm. Not that I've never used C, I just like Spin/Pasm better.
The Prop Tool and PST, together, are less than 1.7MB. Simple IDE is already nearly 23MB, just for the .exe.
Delphi is pretty cool. The language and the compiler were very carefully crafted, in it's founding Pascal tradition, to be readable and build efficient binaries. They took bloat seriously. Pity a little more of the open source movement isn't as concerned.
I like the Propeller for it's Spin/Pasm not that it can do C. I know the new platform is going to be open, I just wish I had the smarts to customize it for Spin/Pasm. Not that I've never used C, I just like Spin/Pasm better.
It would be nice actually to have a main program in Spin but be able to include modules that are in C (like mp3, jpg or png codecs for example).
I write that as a question as to the scope of P2, and I find it very useful to do one "think ahead" on potential features. The longer time line helps to put things into context.
I'm opposed to the feature this late in the game. Better to do it right and clean in the future than to just tack on now, hoping to resolve a kludge in the future. We had this discussion early on and kludge avoidance as well as determinism / code re-use were high on the list. They should remain high now, despite the temptation to do otherwise. We will find, as we did with Prop I, lots of ways to make the thing sing. This one will be no different. And when we do that with a clean, deterministic device, those means and methods will be broadly applicable as they are on this one too. That's worth a lot.
Delphi is pretty cool. The language and the compiler were very carefully crafted, in it's founding Pascal tradition, to be readable and build efficient binaries. They took bloat seriously. Pity a little more of the open source movement isn't as concerned.
The BASIC Stamp tool was a DOS program that contained an editor, compiler, downloader, and debugger - a complete IDE - in under 10k:
02/26/1993 01:37 PM 9,682 STAMP.EXE
Unfortunately, it won't run under Windows 7. I think I'd need to run it through something the opposite of pkzip a few times to get it up into the 10's of megabytes. Then, my computer could take it seriously.
'Less' always means 'more', in terms of reliability.
Okay, the Prop II ROM booter is pretty much done now. We've got 150 longs left within the 512-long ROM at the end of hub memory. Is this enough to talk to an SD card and find a boot file (or, at least, a stretch of contiguous data that could be authenticated and executed)?
Okay, the Prop II ROM booter is pretty much done now. We've got 150 longs left within the 512-long ROM at the end of hub memory. Is this enough to talk to an SD card and find a boot file (or, at least, a stretch of contiguous data that could be authenticated and executed)?
It may be enough to load a bootloader from the MBR if you can share some of the SPI code that you've already written for reading the flash. Another possiblity would be to have a cluster map stored in the MBR that points to a file in the FAT filesystem.
I'm all for lean and mean. But just now I can install 200MB of propgcc and SimpleIDE with its Qt GUI libraries on a machine that fits in a cigarette packet, has a power consumption of 2 watts and quite a few free GigaBytes on its SD card storage.
I'm not inclined to worry about the bloat so much.
I think you can run that old stamp.exe using DosBox. www.dosbox.com
I just tried it and it seems to work. (But, I really don't know what it's supposed to do...)
For my FPGA I have looked on various SDRAM handlers on Internet.
Some of them have in-build all logic for Initiate RAMs -and as it needs only one time that don't impact on read/write trimming. It is only 2 parameters to Initiate that can be settable before Call to initiate SDRAMs
To that them have in-build Refresh so no this impact trimming.
NOW we have to handle only Read/Write of data. And that can be in-build in RDxxxx, WRxxxx state machine that if it read from HUB use one state type else if from SDRAMs another type BUT still with predicable timing (determinacy).
If I write program I know what type of RAM I use and IF Slow one I don't want me more speed them can give me so and 10-5 Clocks in that case is not so much. on other hand HUB ram need TO as I think about 8-16 Clock cycles to read ( RoundRobin window) so we don't missing much --- Only difference of speed between HUB bus and SDRAM bus.
I thought about this, but the protocol for dealing with an SDRAM is not simple. There are quite a few commands that must be fed to it, and data turns around over maybe 10 clocks. Plus, you have to have some refresh strategy that involves various trade-offs with bank-selection. I think this belongs on the software domain for the Prop.
For the SD boot, what if you only support the eMMC standard? eMMC is a very useful interface for industrial control and consumer devices, and some SD cards are eMMC compliant as well. Support eMMC, and SD cards that support it. Beyond that, it's a ***shoot for the customer. If they want to have an SD card slot to boot from, it's up to them to find eMMC compatible SD cards, or experiment until they find one that works.
Why not use DOS mechanics to boot from HD ---
Read Partition -(MBR) to LUT
Find place of DIR read it to LUT --- and see if BOOT filename exist.
IF so track its partition table to load it !!
Then start it for more advanced BOOT --- System loading
If there's enough space to do that it would be great. I suspect Chip's best alternative is to discuss this with Kye. Kye seems to have the most detailed knowledge of the SD card protocol of anyone here and Chip certainly has the best knowledge of the P2 instruction set. Both will be required to fit SD card booting into 150 longs.
PS: There is no way the Prop will ever have an impact on card manufacturer conformancy!
Certainly not Parallax alone. But if every embedded system designer in the world who was looking for a minimal kernel to talk to an SD card all converged on one class of cards, it may be sufficient inducement to perpetuate that class as well as steer future designers in that direction.
As anyone have already pointed.
SPI driver is already in boot code --- so that 150 LONGs needs only to handle SD read from MBR to find starting points fro DIR
DOS have only 512 bytes for that BOOT to spel on and from them You need subtract Bytes used for HD geometry.
If there's enough space to do that it would be great. I suspect Chip's best alternative is to discuss this with Kye. Kye seems to have the most detailed knowledge of the SD card protocol of anyone here and Chip certainly has the best knowledge of the P2 instruction set. Both will be required to fit SD card booting into 150 longs.
Why not use DOS mechanics to boot from HD ---
Read Partition -(MBR) to LUT
Find place of DIR read it to LUT --- and see if BOOT filename exist.
IF so track its partition table to load it !!
Then start it for more advanced BOOT --- System loading
If you read the MBR and partition table it should be enough. If on SD you can make more than one partition (like on HDD) you can have a second hidden partition without file system, just read from the partition starting block retrieved from the partition table (raw read). This will leave untouched the primary partition with file system and read from the second one like from an eeprom. It should require less code.
If you read the MBR and partition table it should be enough. If on SD you can make more than one partition (like on HDD) you can have a second hidden partition without file system, just read from the partition starting block retrieved from the partition table (raw read). This will leave untouched the primary partition with file system and read from the second one like from an eeprom. It should require less code.
dMajo's approach is less optimal than having the ROM code find a file, but hell, this approach is infinitely better (having to do a custom format for prop booting.) than not having SD boot. This lets us boot and do all kinds of cool stuff. Regular formatted SD-CARDS are still readable (just not bootable). Nice compromise!
dMajo's approach is less optimal than having the ROM code find a file, but hell, this approach is infinitely better (having to do a custom format for prop booting.). This lets us boot and do all kinds of cool stuff. Regular formatted SD-CARDS are still readable (just not bootable). Nice compromise!
I think you should consider the possiblity of using the MBR to store the cluster map of a file in the FAT filesystem. This would allow the P2 boot code to locate the clusters of the file without having to understand the FAT filesystem but it would still be booting a normal FAT file that is also visible in the filesystem. You'd have to run a special utility to write the cluster map into the MBR but once you did that you could overwrite that file with normal filesystem tools and since the cluster map wouldn't change you could still boot from that file without having to run the special utility again. This BOOT file in the FAT filesystem could be just a second stage boot that would then go ahead and look for some other file that actually contains the program you want to load.
I would like to say that I think the idea of the Prop II being able to chain load code from the MBR of a SD/MMC fantastic. I would think that offers the greatest flexibility with the minimum amount of code required in ROM. The feature of SD/MMC boot is absolutely worth trying. If Chip can get it to read those first 512 bytes and start executing them, we (the community) should be able to do the rest. (I think it would be helpful if code called from the MBR utilized the read routines used in ROM, to squeeze the most out of the code loaded from the MBR.)
As MBRs place is always know (Always Cylinder 0 - Sector 0) --- It is no problem to find and read it
And in it are Drives geometry and positions of partitions parameter table
I would like to say that I think the idea of the Prop II being able to chain load code from the MBR of a SD/MMC fantastic. I would think that offers the greatest flexibility with the minimum amount of code required in ROM. The feature of SD/MMC boot is absolutely worth trying. If Chip can get it to read those first 512 bytes and start executing them, we (the community) should be able to do the rest. (I think it would be helpful if code called from the MBR utilized the read routines used in ROM, to squeeze the most out of the code loaded from the MBR.)
As MBRs place is always know (Always Cylinder 0 - Sector 0) --- It is no problem to find and read it
And in it are Drives geometry and positions of partitions parameter table
Okay. Let's do this, then.
Does anybody have any quick pointers to what I need to learn?
How much memory could we expect to consistently be available to us in the MBR?
1) Attempt to boot from serial RX/TX
2) Attempt to boot from SPI flash
3) Attempt to boot from SD card
4) If none of the above validated, shut down and wait for another reset
Comments
I really like how things now just compile from RAM. You don't save anything until you want to. Having an automatic archive made each compile wouldn't be bad, if it used a FIFO list of names in a directory that is constant (like maybe where the IDE resides) to make a recent history, but spewing files all over the work directory with different extension names is the bane of modern IDE's. I really hate that. You go to backup what is important and you are wading in a sea of detritus. Ideally, your work directory should only have source files in it, or at least ones that YOU put there.
That's the problem, fitting multiple threads in is more than just having the space when it comes to the drivers. Timing is often very important while at the same time the mips is often way over the top for the driver using that Cog, and nothing else can use it. Four way slicing provides an opportunity to have effectively up to 32 low latency Cogs and still give out full mips between them. Where as task switching is an either-or situation.
While this implementation may be flawed, it isn't going to be a different design in the supposed Prop3 - Assuming the supposed Prop3 goes for compatibility that is, the Prop3 will just have the flaw removed. It'll still able to run the same "sliced" driver software that was written for the Prop2. Newer software after that can make use of the fact that the flaw is gone and be more efficient and precise.
I wonder what Ken thinks of all the enthusiasm for the Prop3 being just around the corner?
-Phil
I thought about this, but the protocol for dealing with an SDRAM is not simple. There are quite a few commands that must be fed to it, and data turns around over maybe 10 clocks. Plus, you have to have some refresh strategy that involves various trade-offs with bank-selection. I think this belongs on the software domain for the Prop.
You guys have good memory. Yes, you could single-cycle access the port D, or better yet, use the XCH mechanism where each cog can post a whole long and every other cog can receive it. This would afford a single-cycle mechanism for data transfer among cogs, but would involve some handshaking for more than one long, unlike hub RAM.
Delphi is pretty cool. The language and the compiler were very carefully crafted, in it's founding Pascal tradition, to be readable and build efficient binaries. They took bloat seriously. Pity a little more of the open source movement isn't as concerned.
It would be nice actually to have a main program in Spin but be able to include modules that are in C (like mp3, jpg or png codecs for example).
I write that as a question as to the scope of P2, and I find it very useful to do one "think ahead" on potential features. The longer time line helps to put things into context.
I'm opposed to the feature this late in the game. Better to do it right and clean in the future than to just tack on now, hoping to resolve a kludge in the future. We had this discussion early on and kludge avoidance as well as determinism / code re-use were high on the list. They should remain high now, despite the temptation to do otherwise. We will find, as we did with Prop I, lots of ways to make the thing sing. This one will be no different. And when we do that with a clean, deterministic device, those means and methods will be broadly applicable as they are on this one too. That's worth a lot.
The BASIC Stamp tool was a DOS program that contained an editor, compiler, downloader, and debugger - a complete IDE - in under 10k:
02/26/1993 01:37 PM 9,682 STAMP.EXE
Unfortunately, it won't run under Windows 7. I think I'd need to run it through something the opposite of pkzip a few times to get it up into the 10's of megabytes. Then, my computer could take it seriously.
'Less' always means 'more', in terms of reliability.
I'm not inclined to worry about the bloat so much.
www.dosbox.com
I just tried it and it seems to work. (But, I really don't know what it's supposed to do...)
For my FPGA I have looked on various SDRAM handlers on Internet.
Some of them have in-build all logic for Initiate RAMs -and as it needs only one time that don't impact on read/write trimming. It is only 2 parameters to Initiate that can be settable before Call to initiate SDRAMs
To that them have in-build Refresh so no this impact trimming.
NOW we have to handle only Read/Write of data. And that can be in-build in RDxxxx, WRxxxx state machine that if it read from HUB use one state type else if from SDRAMs another type BUT still with predicable timing (determinacy).
If I write program I know what type of RAM I use and IF Slow one I don't want me more speed them can give me so and 10-5 Clocks in that case is not so much. on other hand HUB ram need TO as I think about 8-16 Clock cycles to read ( RoundRobin window) so we don't missing much --- Only difference of speed between HUB bus and SDRAM bus.
DosBox is great! I use it on a WinXP machine for a CAM program that was never updated to Windows and won't run from the WinXP command line.
-Phil
Read Partition -(MBR) to LUT
Find place of DIR read it to LUT --- and see if BOOT filename exist.
IF so track its partition table to load it !!
Then start it for more advanced BOOT --- System loading
Certainly not Parallax alone. But if every embedded system designer in the world who was looking for a minimal kernel to talk to an SD card all converged on one class of cards, it may be sufficient inducement to perpetuate that class as well as steer future designers in that direction.
As anyone have already pointed.
SPI driver is already in boot code --- so that 150 LONGs needs only to handle SD read from MBR to find starting points fro DIR
DOS have only 512 bytes for that BOOT to spel on and from them You need subtract Bytes used for HD geometry.
If you read the MBR and partition table it should be enough. If on SD you can make more than one partition (like on HDD) you can have a second hidden partition without file system, just read from the partition starting block retrieved from the partition table (raw read). This will leave untouched the primary partition with file system and read from the second one like from an eeprom. It should require less code.
That is to GOOD way to go !!
As MBRs place is always know (Always Cylinder 0 - Sector 0) --- It is no problem to find and read it
And in it are Drives geometry and positions of partitions parameter table
Okay. Let's do this, then.
Does anybody have any quick pointers to what I need to learn?
How much memory could we expect to consistently be available to us in the MBR?
1) Attempt to boot from serial RX/TX
2) Attempt to boot from SPI flash
3) Attempt to boot from SD card
4) If none of the above validated, shut down and wait for another reset