1 - Agree it is very risky to consider any hardware design changes and that design MUST be frozen
2 - Would like SD card boot if there is a way to fit it - but it isn't the end of the world either given 92 IOs / fact that prop 2 all surface mount anyway
3 - As far as hardware form factors - I'd like at least two:
A - Propeller 2 proto board (like prop 1 proto board) - these are cheap and my main basis for using prop chips
B - Board that adds external RAM, kb/video connectors, SD-CARD slot (don't care about much else)
The Prop I Demo Board that I received from the Propeller intro seminar was my go-to board for all kinds of idea testing and prototyping -- so much so that I wore out some of the wire holes in the breadboard. (The Prop BOE has since replaced the Demo Board as my primary testing platform.) For me, both of these boards have the right mix of features, where the QuickStart and Proto boards fall short. The Prop PDB, OTOH, is way more than I usually need for testing new ideas. I guess my point is that providing too little risks losing your intended audience. What new users want to know is, "What can the Prop II do for me? Show me the benefits." This is answered, more often than not, by reference designs embodied as demo boards. Since the Prop II will be able to do so much, you might need separate reference platforms, say, for video, RF, network connectivity, etc. If prospective users have to do any soldering to experience the benefits, you've lost most of them out of the gate. IMO, it takes more than a minimal module to capture and hold the attention and imagination of prospective customers.
I recommend a board with Digilent Pmod™ headers. Lots of modules ready to plug in. User doesn't pay for things he doesn't use, most of the things on my Propeller Professional Development Board. Others can make modules not provided by Digilent. Licence is zero dollars http://www.digilentinc.com/Pmods/licensing.cfm
Lowest level bit-bashing is the primary goal here. To allow drivers to have multiple tasks or have multiple drivers along side each other. Basically, the Cogs in the Prop2 are more capable, and a lot bigger/beefier, so using a whole Cog to get the timing right but spending most of that time waiting is not effective use of that much hardware.
The WAIT issue is resolved in that a two instruction polling loop is close enough.
The current road block is that, with the smallest implementation of slicing, hub instructions stall the singular pipeline and thereby introducing accumulated delays into the shared hardware threads.
EDIT: As for why this is so. I've come to understand that it's because Chip is offering this as a late addition as long as it doesn't affect the "critical path". The ideal version would work beautifully but requires too deep a re-engineering at this late stage. Hence Pedward's no-go input.
The 'Ideal version' also needs a lot more silicon....
"accumulated delays" is not a general case.
If WAITs are used, then each thread can self-pace, and only have the wait-release jitter.
Even there, if one thread needs time-priority, then it can signal the other when it is allowed Main RAM access, or one thread can collect a packet of variables, and signal the tighter thread, and it can bock-move into main ram, in a slack phase.
I believe Timers now have Capture and true PWM modes, so those are already HW improvements that tolerate small SW jitters.
My design of experimental board to Propeller II are build around ProtoBoards standard of 10 pins connectors 8 signals + VCC, GND only extra pin I added are 5V.
That give users of Propeller 1 possibility of use all modules them have to it on Propeller II board
The Prop I Demo Board that I received from the Propeller intro seminar was my go-to board for all kinds of idea testing and prototyping -- so much so that I wore out some of the wire holes in the breadboard. (The Prop BOE has since replaced the Demo Board as my primary testing platform.) For me, both of these boards have the right mix of features, where the QuickStart and Proto boards fall short. The Prop PDB, OTOH, is way more than I usually need for testing new ideas. I guess my point is that providing too little risks losing your intended audience. What new users want to know is, "What can the Prop II do for me? Show me the benefits." This is answered, more often than not, by reference designs embodied as demo boards. Since the Prop II will be able to do so much, you might need separate reference platforms, say, for video, RF, network connectivity, etc. If prospective users have to do any soldering to experience the benefits, you've lost most of them out of the gate. IMO, it takes more than a minimal module to capture and hold the attention and imagination of prospective customers.
I don't see the need to design for - and support - every SD card in existence. Design for just one...that makes your FAEs response simple. Sure, other cards might work...you can let interested users figure out which ones. Meanwhile, tell me to buy a SanDisk SD card, and I'll buy a SanDisk SD card.
In doing so, you might even help alleviate the problem by steering the biz toward a tighter standard.
I don't see the need to design for - and support - every SD card in existence. Design for just one...that makes your FAEs response simple. Sure, other cards might work...you can let interested users figure out which ones. Meanwhile, tell me to buy a SanDisk SD card, and I'll buy a SanDisk SD card.
In doing so, you might even help alleviate the problem by steering the biz toward a tighter standard.
What happens if SanDisk stops making or supporting SD cards? That's the problem with single sourcing components, and why companies like Parallax try to use as many generic parts as possible. Ken has mentioned it somewhere before, too. <off to find post>
It's even more of an issue with silicon than PCBs: redesign takes x1000s more money.
I am in total agreement with Ken. Any changes to P2 seem to risky and likely to result in P2 delay.
But, these discussions should continue in a different thread (with a link back to here for reference). This discussion should be thought of as a possibility for a P2 rev B provided the P2 sells sufficient volume to support a later rev (fingers crossed these volumes way exceed everyones expectations).
DEBUG IN ROM
As far as I am concerned, the P2 has sufficiently new features, that the methods I used in P1 for my zero footprint debugger are not relevant. The P2 offers so much more features, that I am convinced there are a number of ways to do debugging within the user cog, provided the user sacrifices cog $1F0-$1F5 ($1F6-$1FF are register sets). I am satisfied that we cannot really take advantage of any shaddow ram in the register area to warrant any P2 changes.
I will put my hand up to work with Parallax and the forum to develop debugging on the P2. I will require others more skilled to aid/do the PC side code. This is provided my other major committments come to an end at month's end as I expect.
SPIN2
I will put my hand up to work with Parallax and the forum to help develop the P2 Spin Interpreter. As many of you are aware I have done work on the faster spin interpreter for the P1. My limitations here are that I do not know the higher level requirements, so these will need to be specified by others. My forte is speed and size in pasm, and I am quite slow in doing this (too much of a perfectionist - one should know their own limitations ). Once again, depends on other committments as stated above.
SD BOOT IN ROM
I believe this absolutely should be in the ROM code. It should be only invoked if no Flash is found (or is unitialised), which would then become failsafe. We can clearly state any SD limitations necessary for this to work. Clearly, the Raspberry Pi stated no file system formatting (FAT etc). I think that unwise but no-one is caring.
I am now about to read the posts overnight about the SD card booting and will answer below.
I believe this absolutely should be in the ROM code. It should be only invoked if no Flash is found (or is unitialised), which would then become failsafe. We can clearly state any SD limitations necessary for this to work. Clearly, the Raspberry Pi stated no file system formatting (FAT etc). I think that unwise but no-one is caring.
If the Read has a unique header that it seeks for, then it can become 'tolerant' of FAT etc, if it is there, it simply skips until it finds the key. This is not 100% bullet proof, but as the loader image should always be the same size it should cover most uses.
If it fails, (most likely due to multiple copies of valid-key files) a clean-format and put loader first, should redress.
I believe this absolutely should be in the ROM code. It should be only invoked if no Flash is found (or is unitialised), which would then become failsafe. We can clearly state any SD limitations necessary for this to work. Clearly, the Raspberry Pi stated no file system formatting (FAT etc). I think that unwise but no-one is caring.
I am now about to read the posts overnight about the SD card booting and will answer below.
Does anyone know the size of the boot ROM in the RaspberryPi? My guess is that it is significantly bigger than 2K. I also imagine that it is not on the CPU chip so it compares more directly with our SPI flash boot ROM.
Edit: Looks like I'm wrong. There is no separate boot ROM chip on the Pi. The boot ROM is on the SOC although I can't find anything that says how big it is.
My boot code for ZiCog and the Prop OS takes 1262 longs and var takes 410 longs, plus of course stack. Now while this is a fairly minimal design, it searches for a number of FAT files during the boot process. I should also state spin is used because this will impact negatively.
But, remember, P2 has some special instructions that will simplify things too.
In terms of pin count on the Prop, an SD card can share three of the four pins with the SPI flash chip. So, only a difference of one pin. compared to a single memory solution.
There really is a significant advantage in having an initial boot from SPI flash. The reliability gains alone justify it, both mechanically and the protocols. But having option for filesystem support and operator feedback are two other really good reasons. Having something that isn't completely lifeless without the card plugged in is definitely a benefit.
The main program can still be loaded from the SD card. Field upgrades can still be done. I'm not seeing a problem here.
PS: There is no way the Prop will ever have an impact on card manufacturer conformancy!
PPS: Developer boards can be shipped with the SPI flash preprogrammed to run an ordinary file based program from the SD card. There! Even better than what the Raspberry Pi board offers.
I've been doing some research, and it appears that some of the SD support issues (particularly on simple embedded devices) can be attributed to the fact that some SD cards might be formatted with partition information starting in address 0x0000 where the MBR should reside, instead of 0x01BE. Reformatting the disk won't correct this unless you specify that the formatting utility add the MBR. So that might be something to keep in mind.
I still maintain that the safest route to go is by reading the appropriate SD registers to determine the size of the card and jumping towards the very end where the boot file should reside. This doesn't require it's own partition or filesystem. It would however need a special utility to put the file there, but that doesn't mean it can't place the appropriate file information in the FS tables, that way it would still show up in an OS's file manager. It doesn't look like there are any (embedded) processors that have the ability to boot off SD where you can simply dump the boot file wherever you want - they all have specific requirements which engineers need to be aware of, so it's not unreasonable to place specific requirements for P2 users. I really think this is the simplest implementation since it doesn't require the bootloader to be aware of whatever file system is being used.
Hmm. preloading EEPROM code to boot from the SD-CARD is a pretty good idea if it turns out that it wont fit on the propeller ROM. Like it.
Nothing new here... I have been doing this for years on my RamBlades.
I think many of you miss the point. For volume production that requires a working SD card, designers do not want to add a Flash chip if it's not required. It is not just the cost of the part, but the board space, the inventory cost, and the assembly cost. The P2 is not like other chips that have internal Flash. If you hit a volume production of say 1M units, that would translate to $500,000 in profit straight to the bottom line. Your viewing this from a hobbyists perspective, and that is not where the P2 is being aimed.
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.
Re: Prop Tool vs Projects and such.
You know the single best thing about the Prop Tool is that it compiles from RAM. One can save a state, then go tweaking with a minimum of fuss. I absolutely hate it the other way because it's a much thicker interaction. One of the best attributes about Propellers is they tend to be lean in ways that a lot of stuff isn't.
I don't mean to bash the very fine open tool efforts. They are excellent, and necessary. However, I can honestly say that if we had that methodology starting out, I may not have jumped in.
There is room for both on this. Get the "pro" or "traditional" type and grade of tools done. Then, let's reconsider how building can be done, carrying some of the better Prop Tool attributes forward. They are distinctive and quite potent, if a bit off the beaten path. Phil's comments rang particularly true with me. Very strong resonance there.
One thing I can get specific on is lack of source control and handling multiple files. With the Prop Tool method, one saves off a state, then changes it, saving if good, reverting if bad. This is very lean. With the save it all, then build method, one saves off a state, then changes it, then saves THAT ONE, making a simple revert much more thick and difficult.
IMHO, one resolution to this would be a simple, "build from RAM" option for those who prefer to do that. Another would be to begin thinking about how to incorporate revision control directly into the tool for the longer haul. This has very significant advantages I am quite happy to expand on having had similar experiences with other kind of data that exhibit very similar dynamics.
Re: SD Card.
Would love this option. If it's not native to the chip, then having a standard boot protocol baked in ASAP is second best option.
Cluso,
Perhaps my statement about the ease of writing a raw Rapberry Pi image to SD was misleading.
The Raspberry PI boots from a FAT formatted partition. In there it looks for a specific file name to load and that is a secondary boot loader. That bootloader the looks for an OS to boot, normally a Linux kernel image. There are also some config files in there to setup params for Linux.
Linux then mounts a second partition as its root file system which is normally not FAT.
On the Pi Soc there is the ARM CPU and a GPU. As far as I understand the GPU has built in boot code and actually is the one that loads boot code from SD and starts the ARM.
I have even read that there maybe a third little controller on board that does this boot management.Yet to confirm.
It's all rather complex but at the end of the day the user only need to write the one big disc image to SD that includes the FAT and other partitions with whatever OS inside them.
I think many of you miss the point. For volume production that requires a working SD card, designers do not want to add a Flash chip if it's not required.
Why should products that don't need SD Card have to carry the cost of it? 256KB SPI Flash is available at < $0.5 each (10 at a time) ... this alone is far cheaper than the SD card and connector. Just because some people think they need an O/S on Propeller doesn't mean we all do.
Your viewing this from a hobbyists perspective, and that is not where the P2 is being aimed.
Exactly the same argument can be made for not using an SD card. Industrial customers may consider it a weakness because it requires a mechanical part which reduces the MTBF (but practically also MTTR) of the design. While SD cards have wear leveling etc..., the cards and holders also have a maximum number of insertions, and they may not do well for everyone in a harsh environment.
Now, if multiple boot methods were possible (SPI Flash and SD Card), this wouldn't even be an issue. Chip might be able to add both methods given enough time ... (months?)
This is all up to Parallax of course, and I fully support whatever they think is best. It is, after all, their business and they can make intelligent choices.
. Your viewing this from a hobbyists perspective, and that is not where the P2 is being aimed.
So what are the current specs on the p2? 160mhz? 8 core? 64 pin?
That means video. you gonna generate all this video internally using mad haxor skillz you learnd at demothon 2000?
No yer gonna hook that p2 up to yo sweet stereo, and DVI monitor or HDMI display and code some neato stuff. and you will want sd to do it.
Gaming console. stereo, rgb, full screen fluid motion. Etc..
If the p1 is any indication, the p2 will be multimedia MADNESS. as far as what people do with it. this means they will need SD CARDS, and lots of them, and lots of applications will use them.
They will be used SOO much that everyone will view the eeprom as nuisance if its required to boot sd.
eeproms are not cheap, but I have a TON of sd cards from various phones, cameras, etc.
My only issue is the opensource nature of the p1 forced people to go open. The p2 allows everyone to hoarde their code for profit.
Im all for profit, but the obex and free code on the forums are what makes the p1 shine.
I hope all you coding monsters don't stop giving free code to the community.
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
I've been thinking about this single-clock-granular task switching, and I'm pretty confident that I know exactly how to implement it, but there's a problem:
Let's say you've got four tasks running and each task is coded using only single-clock instructions, so that timing is totally determinant. This is great, because now you've got four fast tasks that can behave just like hardware. This isn't realistic, though, because at least one of those tasks will need to do RDxxxx/WRxxxx instructions to communicate with the hub, lest there be no memory communication with other cogs. This will destroy determinancy. Why do this if there can't be practical determinancy?
I calculated that this feature would add about 0.1 sq mm of silicon to the current 9.5 sq mm, which is negligible. I could implement it in one day and it would not affect the critical path of the synthesis work, which is now focused on scripting the post-layout tools. Introducing new Verilog would only mean having the synthesis engineer compile it and push it through his scripts. No engineering work would have to be done by him to accommodate the change. It would mean, to us, paying for a few hours of his time to have him perform this rote effort, which he's already done at least ~60 times since things have been in final form. There were ~60 versions before we even got to that point. Right now, we are on version 124.
So, never minding Ken's concerns, can anyone make an argument for having this feature, despite it's serious flaw? Kye and I talked earlier that lack of timing determinancy would fatally undermine intended performance, since no task could be sure of timing, from instruction to instruction. By doing scheduled task switching in software using WAITCNT, on the other hand, you'd get timing perfection, though at a much coarser granularity.
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
Why should products that don't need SD Card have to carry the cost of it? 256KB SPI Flash is available at < $0.5 each (10 at a time) ... this alone is far cheaper than the SD card and connector. Just because some people think they need an O/S on Propeller doesn't mean we all do.
What do you mean? In my method there is no requirement for an SD card at all. It's an either or both.
Exactly the same argument can be made for not using an SD card. Industrial customers may consider it a weakness because it requires a mechanical part which reduces the MTBF (but practically also MTTR) of the design. While SD cards have wear leveling etc..., the cards and holders also have a maximum number of insertions, and they may not do well for everyone in a harsh environment.
Now, if multiple boot methods were possible (SPI Flash and SD Card), this wouldn't even be an issue. Chip might be able to add both methods given enough time ... (months?)
Obviouslyyou didn't bother to read my suggestions... If the Flash is not found, then the boot rom code proceeds to verify if an SD card exists and meets minimum requirements, and if so continues to boot from the SD card. As to months, this is not complex.
This is all up to Parallax of course, and I fully support whatever they think is best. It is, after all, their business and they can make intelligent choices.
Of course it is. But you and others are attempting to bias the argument with invalid assumptions. Have you designed and sold hundreds of thousands of products?
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..
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.
One thing to keep in mind is that SimpleIDE is supposed to be "simple". If we keep heaping new features on it we might want to consider if it would be better to just move to Eclipse that already has everything including the kitchen sink. We need to find some way to keep SimpleIDE simple so that it can be used by beginners but provide a more feature-full alternative in Eclipse or something like it. (NetBeans maybe?)
Hence my suggestion that there should be a SimpleIDE for Spin only with no sign of any of the C menues, buttons, dalogs etc. Perhaps built differently for Spin only or with a mode button somewhere.
I would not be opposed to a separate SimpleIDE version for Spin/PASM, especially if combining the two makes it huge. The Prop Tool and PST, together, are less than 1.7MB. Simple IDE is already nearly 23MB, just for the .exe.
Comments
No debugger on you todo list?
2 - Would like SD card boot if there is a way to fit it - but it isn't the end of the world either given 92 IOs / fact that prop 2 all surface mount anyway
3 - As far as hardware form factors - I'd like at least two:
A - Propeller 2 proto board (like prop 1 proto board) - these are cheap and my main basis for using prop chips
B - Board that adds external RAM, kb/video connectors, SD-CARD slot (don't care about much else)
-Phil
John Abshier
Agreed.
The 'Ideal version' also needs a lot more silicon....
"accumulated delays" is not a general case.
If WAITs are used, then each thread can self-pace, and only have the wait-release jitter.
Even there, if one thread needs time-priority, then it can signal the other when it is allowed Main RAM access, or one thread can collect a packet of variables, and signal the tighter thread, and it can bock-move into main ram, in a slack phase.
I believe Timers now have Capture and true PWM modes, so those are already HW improvements that tolerate small SW jitters.
You mean apart from Debug ?
Sure, there are lots of simple state housekeeping tasks that could use a "fractional COG" - even a Watchdog.
Hardware Debug is the largest single missing piece in the Prop 2, with other vendors now offering things like this
From TI :
http://www.ti.com/tool/launchxl-f28027
- This $17 PCB gives you a Isolated(!) Debug link, into their 32 bit DSP series.
From ST, their even lower cost Discovery series, and this includes DEBUG.
http://www.st.com/internet/evalboard/product/250863.jsp
My design of experimental board to Propeller II are build around ProtoBoards standard of 10 pins connectors 8 signals + VCC, GND only extra pin I added are 5V.
That give users of Propeller 1 possibility of use all modules them have to it on Propeller II board
Why reinvent the wheel.
PMOD headers would be a quick way of giving users to all sorts of plug in modules which are already on the market. You can't ask for than that.
In doing so, you might even help alleviate the problem by steering the biz toward a tighter standard.
What happens if SanDisk stops making or supporting SD cards? That's the problem with single sourcing components, and why companies like Parallax try to use as many generic parts as possible. Ken has mentioned it somewhere before, too. <off to find post>
It's even more of an issue with silicon than PCBs: redesign takes x1000s more money.
I am in total agreement with Ken. Any changes to P2 seem to risky and likely to result in P2 delay.
But, these discussions should continue in a different thread (with a link back to here for reference). This discussion should be thought of as a possibility for a P2 rev B provided the P2 sells sufficient volume to support a later rev (fingers crossed these volumes way exceed everyones expectations).
DEBUG IN ROM
As far as I am concerned, the P2 has sufficiently new features, that the methods I used in P1 for my zero footprint debugger are not relevant. The P2 offers so much more features, that I am convinced there are a number of ways to do debugging within the user cog, provided the user sacrifices cog $1F0-$1F5 ($1F6-$1FF are register sets). I am satisfied that we cannot really take advantage of any shaddow ram in the register area to warrant any P2 changes.
I will put my hand up to work with Parallax and the forum to develop debugging on the P2. I will require others more skilled to aid/do the PC side code. This is provided my other major committments come to an end at month's end as I expect.
SPIN2
I will put my hand up to work with Parallax and the forum to help develop the P2 Spin Interpreter. As many of you are aware I have done work on the faster spin interpreter for the P1. My limitations here are that I do not know the higher level requirements, so these will need to be specified by others. My forte is speed and size in pasm, and I am quite slow in doing this (too much of a perfectionist - one should know their own limitations
SD BOOT IN ROM
I believe this absolutely should be in the ROM code. It should be only invoked if no Flash is found (or is unitialised), which would then become failsafe. We can clearly state any SD limitations necessary for this to work. Clearly, the Raspberry Pi stated no file system formatting (FAT etc). I think that unwise but no-one is caring.
I am now about to read the posts overnight about the SD card booting and will answer below.
If the Read has a unique header that it seeks for, then it can become 'tolerant' of FAT etc, if it is there, it simply skips until it finds the key. This is not 100% bullet proof, but as the loader image should always be the same size it should cover most uses.
If it fails, (most likely due to multiple copies of valid-key files) a clean-format and put loader first, should redress.
Edit: Looks like I'm wrong. There is no separate boot ROM chip on the Pi. The boot ROM is on the SOC although I can't find anything that says how big it is.
But, remember, P2 has some special instructions that will simplify things too.
There really is a significant advantage in having an initial boot from SPI flash. The reliability gains alone justify it, both mechanically and the protocols. But having option for filesystem support and operator feedback are two other really good reasons. Having something that isn't completely lifeless without the card plugged in is definitely a benefit.
The main program can still be loaded from the SD card. Field upgrades can still be done. I'm not seeing a problem here.
PS: There is no way the Prop will ever have an impact on card manufacturer conformancy!
PPS: Developer boards can be shipped with the SPI flash preprogrammed to run an ordinary file based program from the SD card. There! Even better than what the Raspberry Pi board offers.
I still maintain that the safest route to go is by reading the appropriate SD registers to determine the size of the card and jumping towards the very end where the boot file should reside. This doesn't require it's own partition or filesystem. It would however need a special utility to put the file there, but that doesn't mean it can't place the appropriate file information in the FS tables, that way it would still show up in an OS's file manager. It doesn't look like there are any (embedded) processors that have the ability to boot off SD where you can simply dump the boot file wherever you want - they all have specific requirements which engineers need to be aware of, so it's not unreasonable to place specific requirements for P2 users. I really think this is the simplest implementation since it doesn't require the bootloader to be aware of whatever file system is being used.
I think many of you miss the point. For volume production that requires a working SD card, designers do not want to add a Flash chip if it's not required. It is not just the cost of the part, but the board space, the inventory cost, and the assembly cost. The P2 is not like other chips that have internal Flash. If you hit a volume production of say 1M units, that would translate to $500,000 in profit straight to the bottom line. Your viewing this from a hobbyists perspective, and that is not where the P2 is being aimed.
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.
Re: Prop Tool vs Projects and such.
You know the single best thing about the Prop Tool is that it compiles from RAM. One can save a state, then go tweaking with a minimum of fuss. I absolutely hate it the other way because it's a much thicker interaction. One of the best attributes about Propellers is they tend to be lean in ways that a lot of stuff isn't.
I don't mean to bash the very fine open tool efforts. They are excellent, and necessary. However, I can honestly say that if we had that methodology starting out, I may not have jumped in.
There is room for both on this. Get the "pro" or "traditional" type and grade of tools done. Then, let's reconsider how building can be done, carrying some of the better Prop Tool attributes forward. They are distinctive and quite potent, if a bit off the beaten path. Phil's comments rang particularly true with me. Very strong resonance there.
One thing I can get specific on is lack of source control and handling multiple files. With the Prop Tool method, one saves off a state, then changes it, saving if good, reverting if bad. This is very lean. With the save it all, then build method, one saves off a state, then changes it, then saves THAT ONE, making a simple revert much more thick and difficult.
IMHO, one resolution to this would be a simple, "build from RAM" option for those who prefer to do that. Another would be to begin thinking about how to incorporate revision control directly into the tool for the longer haul. This has very significant advantages I am quite happy to expand on having had similar experiences with other kind of data that exhibit very similar dynamics.
Re: SD Card.
Would love this option. If it's not native to the chip, then having a standard boot protocol baked in ASAP is second best option.
Perhaps my statement about the ease of writing a raw Rapberry Pi image to SD was misleading.
The Raspberry PI boots from a FAT formatted partition. In there it looks for a specific file name to load and that is a secondary boot loader. That bootloader the looks for an OS to boot, normally a Linux kernel image. There are also some config files in there to setup params for Linux.
Linux then mounts a second partition as its root file system which is normally not FAT.
On the Pi Soc there is the ARM CPU and a GPU. As far as I understand the GPU has built in boot code and actually is the one that loads boot code from SD and starts the ARM.
I have even read that there maybe a third little controller on board that does this boot management.Yet to confirm.
It's all rather complex but at the end of the day the user only need to write the one big disc image to SD that includes the FAT and other partitions with whatever OS inside them.
Why should products that don't need SD Card have to carry the cost of it? 256KB SPI Flash is available at < $0.5 each (10 at a time) ... this alone is far cheaper than the SD card and connector. Just because some people think they need an O/S on Propeller doesn't mean we all do.
Exactly the same argument can be made for not using an SD card. Industrial customers may consider it a weakness because it requires a mechanical part which reduces the MTBF (but practically also MTTR) of the design. While SD cards have wear leveling etc..., the cards and holders also have a maximum number of insertions, and they may not do well for everyone in a harsh environment.
Now, if multiple boot methods were possible (SPI Flash and SD Card), this wouldn't even be an issue. Chip might be able to add both methods given enough time ... (months?)
This is all up to Parallax of course, and I fully support whatever they think is best. It is, after all, their business and they can make intelligent choices.
So what are the current specs on the p2? 160mhz? 8 core? 64 pin?
That means video. you gonna generate all this video internally using mad haxor skillz you learnd at demothon 2000?
No yer gonna hook that p2 up to yo sweet stereo, and DVI monitor or HDMI display and code some neato stuff. and you will want sd to do it.
If the p1 is any indication, the p2 will be multimedia MADNESS. as far as what people do with it. this means they will need SD CARDS, and lots of them, and lots of applications will use them.
They will be used SOO much that everyone will view the eeprom as nuisance if its required to boot sd.
eeproms are not cheap, but I have a TON of sd cards from various phones, cameras, etc.
My only issue is the opensource nature of the p1 forced people to go open. The p2 allows everyone to hoarde their code for profit.
Im all for profit, but the obex and free code on the forums are what makes the p1 shine.
I hope all you coding monsters don't stop giving free code to the community.
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
Of course it is. But you and others are attempting to bias the argument with invalid assumptions. Have you designed and sold hundreds of thousands of products?
I have be thinking --- AND
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.
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
One thing to keep in mind is that SimpleIDE is supposed to be "simple". If we keep heaping new features on it we might want to consider if it would be better to just move to Eclipse that already has everything including the kitchen sink. We need to find some way to keep SimpleIDE simple so that it can be used by beginners but provide a more feature-full alternative in Eclipse or something like it. (NetBeans maybe?)
-Phil