Do we have a FAT driver for SD cards that understands multiple partitions?
Hmmm...if we have I could have been using it for a CP/M partition a long time ago.
AntoineDoinel: Perhaps a simpler way would be to just shift the block each time (as you said), but just increment the block. No need for a random generator. When at the end, start from the beginning again.
AntoineDoinel: Perhaps a simpler way would be to just shift the block each time (as you said), but just increment the block. No need for a random generator. When at the end, start from the beginning again.
jazzed: very interesting article.
That was meant to continue with uniform wearing after power off or reset, without having to save a pointer to the current location.
Please provide a schematic link in this thread if you want support your external hardware design to be considered with Propeller GCC. I'm trying to document what we have.
If your hardware is not already supported, it will be necessary for you to be involved with driver development and testing, period. Some boards are supported now because we have access to hardware and have had time and motivation to do it all ourselves.
@Dr_Acula, I do not have a link to the DRACBLADE schematic. Please provide one.
Below is a table of current board types and supported memory models.
LMM is "Large Memory Model" which uses only Propeller HUB memory.
XMM is "eXternal Memory Model" which can have code and data in external memory depending on the linker.
XMMC is "eXternal Memory Model Code" which has only code in external memory.
Any executable code can be put into HUB for LMM mode even if the Model is XMM or XMMC.
Stack is always in HUB memory regardless of Model.
Board Type Memory Types Description
C3
LMM XMM XMMC
Parallax Open Source Hardware with Flash
I am really disappointed Steve. Since I pretty much started the push to use SRAM with my TriBlade and then followed by the RamBlade I would have expected more from Parallax. All the schematics were published and many have produced copies of my boards or derivatives of them, which included free help from me. Guess I will just stay with Catalina!
I am really disappointed Steve. Since I pretty much started the push to use SRAM with my TriBlade and then followed by the RamBlade I would have expected more from Parallax. All the schematics were published and many have produced copies of my boards or derivatives of them, which included free help from me. Guess I will just stay with Catalina!
I have a RamBlade that I'm planning on building a cache driver for once I get a number of other tasks done. I was slowed down by needing to hook up a power supply and a PropPlug as well as a USB2serial interface. I have a few more wires to solder before I can power up the RamBlade and start working on software. I'm not really a hardware person so I worked on boards that were easy to plug-and-play first. As I've mentioned before, I don't have a TriBlade and it isn't possible to get one anymore so that wasn't a possiblity. Sorry that support for your boards has been delayed.
In the end, the officially supported list of external memory hardware at GA release is up to Parallax, Inc. Cooperating may influence that outcome.
Part of the point of the survey as stated in post one is to ensure we have a solution where engineers can develop their own solution. The other part was to ensure we have a minimum set for testing.
"Please help determine which external memory hardware solutions should be added to the initial Propeller GCC release. Hardware developers can easily add their own solution, but we need a minimum set for testing.
The number of entries allowed by the survey tool is limiting, and I don't want to seem biased. Please just mention the hardware you have in a reply. We already have drivers for C3, SpinSocket-Flash, DracBlade, and SDRAM."
The only reason for the solutions in hand was to prove that they could be done, and by extension prove that other solutions could be added. I'm still working on the documentation for adding a new design. It will be released later.
Replies that have been mentioned:
RamPage, FlashPoint, W25X chips, AT45DB***, RamBlade, and TriBlade.
I've already said that RamPage, FlashPoint, and Duane Degn's W25X design could be supported. Most of the work required for these was done many months ago.
The Atmel Dataflash AT45DB*** solution is a fair suggestion, but may have to wait for a volunteer.The parallel bus Dataflash which I thought was the perfect solution long ago is end of life.
RamBlade and TriBlade are end of life. Unless there is a volunteer for them, they won't be supported. If you have something not end of life and are willing to help develop and test the solution, we can implement it.
As I said, in the end, the "officially supported" list at GA release is up to Parallax, Inc. It is not up to me. Right now, they are not committed to more than 2 solutions. For any solution to be seriously considered, it should have support from the developer. Think about it.
Just for the record, RamBlade is NOT EOL - it is still available and will continue to be, because it is a little faster than RamBlade3. I did run out of a few parts a couple of months ago and had to wait to combine these parts with another order (shipping to Oz is expensive). The first RamBlade3 (stackable version) is being delivered. The standalone/pluggable RamBlade3 is not yet available. The RamBlade3 pasm driver for ZiCog works and has been published. I am working with Ross to get the Catalina driver running. There are pasm drivers published for both the TriBlade and RamBlades.
The only reason the TriBlade pcb is not available is because I believe the pcbs are too expensive for me to outlay the funds. If someone wants a few of them, then they can be made at a price. However, there are a number of them out there, plus clones.
Anyway Steve, you obviously have a hidden agenda. I never said I was not willing to cooperate. Quite the contrary. I just cannot help in GCC project because I do not know anything about GCC and very little about C.
You asked...
Please help determine which external memory hardware solutions should be added to the initial Propeller GCC release. Hardware developers can easily add their own solution, but we need a minimum set for testing.
The number of entries allowed by the survey tool is limiting, and I don't want to seem biased. Please just mention the hardware you have in a reply. We already have drivers for C3, SpinSocket-Flash, DracBlade, and SDRAM.
and I replied (to what I thought was your intent of this thread)...
I would think that either TriBlade (Prop #2) or the RamBlade should be included as it is arguably the fastest SRAM interface, but it does consume the whole prop chip to do it.
What do you require for testing (please note I no longer have TriBlades available and only 1 myself). I could provide a RamBlade2 for testing.
to which you responded...
I want you and others to be able to produce compliant drivers for new hardware. Driver interface specification details, usage info, and a test program will be available later for this purpose. The Propeller GCC design does not require anything other than a functional hardware/software interface encapsulated in a single Spin/PASM module and a short entry in the loader's config file.
All external memory drivers have the same interface and will run in a COG separately from the main XMM VM. Embedding hardware access directly in the XMM (external LMM VM) will not be officially supported; however, nothing will stop the adventurous from doing that on their own.
In a normal setting, a knowledgeable solution developer should have full control of their own schedule and products without requiring a third party to do it for them. This is a goal of Propeller GCC XMM. There should be no reason at all to ask a compiler developer (or Parallax for that matter) to do any of this work for a knowledgeable developer, but the team is available short term to verify these concepts. I will PM you details about team availability.
I thought I merely replied to what I thought was a simple question. I offered hardware for testing. I have published my drivers (MIT licence) and schematics. I was told to go and write my own drivers. There has been no information as far as I am aware to be able to write my own drivers. So what do you expect! Now I am no longer interested. My boards will run fine on Catalina.
Perhaps others have noticed your attitude in the Catalina thread. You DO seem to have something against Catalina (at least that is how it comes across to me in your postings). Maybe both sides can dial it back a little bit?
Boy.. so many decent people getting flustered. Why the venom folks? It is just writing code and working together. I think there is just a mis-understanding that is taking away the point of this thread.
One thing that people here might not realize is that mostly the PropGCC external memory drivers are being developed by volunteers. In my case, that means I work on hardware that I already own and that is easy for me to configure. That has meant the C3 and the DracBlade so far. I hope to work on the RamBlade soon but I still have some wiring to do before my RamBlade is ready to use. The C3 and DracBlade just required a serial connection and maybe power. The RamBlade requires me to do some wiring that I just haven't had time to complete yet. So the order in which I'm doing things has nothing to do with any value judgement about the products. It is entirely based on which is easist to configure and use and which I actually own. I've had the DracBlade and the RamBlade for a long time and I was a tester for the C3. I don't own a TriBlade or Morpheus or any of the other external memory boards. I do own one of Steve's SDRAM modules and his SpinSocketFlash but he did the drivers for those boards as well as the EEPROM driver.
@JLocke, you got it wrong, I think everybody here thinks that RossH has something against jazzed, and the PropGCC project. I personally could care less about C for the Propeller, I would like to see an enhanced Spin that can handle external memory (LMM,XMM).
I personally could care less about C for the Propeller, I would like to see an enhanced Spin that can handle external memory (LMM,XMM).
I'm curious as to why you prefer Spin over C? Both are fairly low-level languages but C has the advantage of better support for data structures. Is there a reason you prefer Spin?
"I'm curious as to why you prefer Spin over C?" - Spin is/was designed for the Propeller, therefore a natural fit. From what I have read on this forum, it seems that C is like an added appendage, not a natural fit. With the unnatural fit comes a lot of compromises, which in the long run will probably not enhance the experience with programming the Propeller.
"I'm curious as to why you prefer Spin over C?" - Spin is/was designed for the Propeller, therefore a natural fit. From what I have read on this forum, it seems that C is like an added appendage, not a natural fit. With the unnatural fit comes a lot of compromises, which in the long run will probably not enhance the experience with programming the Propeller.
Ray
Thanks for your response. I'm not quite sure in what way Spin is a "natural fit" except that it does fit in hub memory better than C. Actually, there was another C effort called ZOG that was closer to the code density achieved by Spin but it was also based on emulating another instruction set rather than running native on the Propeller hardware. You could argue that either Catalina C or PropGCC fits the Propeller better than either Spin or ZOG because it produces native PASM code rather than some interpreted language. Anyway, I understand your point and appreciate your comment.
"I'm curious as to why you prefer Spin over C?" - Spin is/was designed for the Propeller, therefore a natural fit.
Personally I agree with this because that's the way Chip designed Propeller.
However, Parallax needs a flexible C solution to attract bigger customers and maintain a presence in education.
We hobbyists are good customers, but our purchases alone may not be the best growth path.
I have SPIN running from external memory with limits. It's relatively slow but not bad. One limit stands out among the rest:
the structure of SPIN restricts the size of the program without special tricks - that frustrates further progress.
I'm curious as to why you prefer Spin over C? Both are fairly low-level languages but C has the advantage of better support for data structures. Is there a reason you prefer Spin?
As a language C is clearly superior to Spin.
As a language and compiler and IDE for the Propeller that is not so clear.
The Prop is memory constrained. The C compilers generate much bigger code than Spin. Some clever person (Chip), realizing this, devised Spin so that you could actually get functionality into the Prop. After all for speed there is PASM in other COGs.
So far no C compiler has managed to come close to Spin on the Prop in terms of the functionality you can get into 32K HUM memory.
As for structures, well on suc small programs as we have in the Prop I wonder if they are much of an advantage.
@Rayman,
I think one big reason to want C for Prop2 is that there is a ton of existing code like:
MP3 codec
USB device driver
JPG codec
etc.
Nice idea but I have a sneaking suspicion that such codes won't fit in the Prop II space either. We shall see.
Heater,
Prop 2 should have enough I/O to implement a high-speed external memory interface to allow big programs...
This is very true.
Maybe we can all get on with one (or two) boards so we can make progress when the time comes.
Sapieha started something and it has basic prototyping features. If we could have a plugin for memories it would be nice.
There are so many possibilities with a P2. ... Wish I could contain my enthusiasm.
One thing that people here might not realize is that mostly the PropGCC external memory drivers are being developed by volunteers. In my case, that means I work on hardware that I already own and that is easy for me to configure. That has meant the C3 and the DracBlade so far
Thanks ++ for doing this. I think there are two drivers out there for the Dracblade. There is the original one that was part of the Z80 emulation, and then some clever person (not sure who but it is in the code) improved the code and I think that improved code is the one that is in Catalina. I think the Catalina driver ends up a little faster.
[I need to get my work/life balance sorted - where for "life", substitute "propeller" ]
Other drivers are possible too - tonight I'm going to try breadboarding up something using TTL counters as I'm hoping to get it fast enough for a video loop which is 4 pasm instructions. If it works, that could be useful as a caching driver.
But I digress. This post is to say thanks to David for doing the Dracblade driver for GCC.
@JLocke, you got it wrong, I think everybody here thinks that RossH has something against jazzed, and the PropGCC project. I personally could care less about C for the Propeller, I would like to see an enhanced Spin that can handle external memory (LMM,XMM).
Ray
Hi Ray,
I respond to Jazzed when he seems to be simply taking potshots at Catalina, or when he is plainly wrong. I would respond the same way to anyone. I do not have anything against Jazzed personally, and the only thing I have against PropGCC is that some people seem to believe it is a magical pathway to making C++, Fortran and Java practical on the Propeller. It isn't.
Thanks ++ for doing this. I think there are two drivers out there for the Dracblade. There is the original one that was part of the Z80 emulation, and then some clever person (not sure who but it is in the code) improved the code and I think that improved code is the one that is in Catalina. I think the Catalina driver ends up a little faster.
[I need to get my work/life balance sorted - where for "life", substitute "propeller" ]
Other drivers are possible too - tonight I'm going to try breadboarding up something using TTL counters as I'm hoping to get it fast enough for a video loop which is 4 pasm instructions. If it works, that could be useful as a caching driver.
But I digress. This post is to say thanks to David for doing the Dracblade driver for GCC.
Dr_Acula
I did the optimization, but from my measurements it's not worth the hassle.
While with that changes I gain a round 20% performance on my board, that is true only in uncached mode.
With 8KB cache the difference is under 1% (just like Ross told us ).
Furthermore it comes with the risk of not working on all boards (i.e. I have only one delay instruction between enable and read, same for write gate).
So I'd suggest David to start with the original driver.
and the only thing I have against PropGCC is that some people seem to believe it is a magical pathway to making C++, Fortran and Java practical on the Propeller. It isn't.
What happened to let's move on?
Fortran and Java were not specified for Propeller GCC. Don't make things up please.
The rest is a matter of understanding what the customer wants and providing it.
Yes the delays might be an issue if the memory chip and propeller are some distance apart. And I agree - with caching, the absolute speed of any external memory becomes less important.
Fortran and Java were not specified for Propeller GCC. Don't make things up please.
The rest is a matter of understanding what the customer wants and providing it.
Hi Jazzed,
I've moved on. I was not responding to you - I was correcting a comment from Ray, who was mistaken about my having something against you.
Also, I'm not making things up - it just seem that a few things have been forgotten. Perhaps you will recall this quote from the very first GCC announcement by Ken (bold emphasis added by me):
Parallax Semiconductor is interested in assembling a small team of developers familiar with the GCC compiler suite and perhaps the Eclipse plug-in. The objective is create an open-source cross-platform compatible compiler suite for Propeller 2 (code name) supporting Spin, C/C++ and possibly other languages.
Also, perhaps you may remember making this comment in the same thread:
Answering questions about Java: the GNU Compiler Collection includes GCJ. It is not clear at this point if GCJ will be supported. It and other languages such as Objective C, Fortran, and Ada may be considered. The main emphasis however at this point is C/C++.
Or perhaps this one:
This is a serious question because as the direction of GCC becomes more clear, we'll have to decide whether or not to support other languages. The default answer is to support whatever GCC supports.
I presume from your response that you have now considered the other languages that GCC supports and have decided not to support them?
I've moved on. I was not responding to you - I was correcting a comment from Ray, who was mistaken about my having something against you.
"and the only thing I have against PropGCC is that some people seem to believe it is a magical pathway to making C++, Fortran and Java practical on the Propeller. It isn't."
Clearly your answers prove Rays point that you have animosity towards GCC which is an effort I'm responsible for and by extension animosity towards me.
We talked about languages. Parallax wants C/C++. The other languages are possible, but not specified for this project. The other languages were not requested by Parallax and are not in the requirements. We are providing what GCC provides as specified for C/C++. I'm delivering what Parallax wants. Can you?
Please stop spewing arguments and manipulative propaganda. It's not doing anyone any good.
Comments
Hmmm...if we have I could have been using it for a CP/M partition a long time ago.
jazzed: very interesting article.
That was meant to continue with uniform wearing after power off or reset, without having to save a pointer to the current location.
If your hardware is not already supported, it will be necessary for you to be involved with driver development and testing, period. Some boards are supported now because we have access to hardware and have had time and motivation to do it all ourselves.
@Dr_Acula, I do not have a link to the DRACBLADE schematic. Please provide one.
Below is a table of current board types and supported memory models.
LMM is "Large Memory Model" which uses only Propeller HUB memory.
XMM is "eXternal Memory Model" which can have code and data in external memory depending on the linker.
XMMC is "eXternal Memory Model Code" which has only code in external memory.
Any executable code can be put into HUB for LMM mode even if the Model is XMM or XMMC.
Stack is always in HUB memory regardless of Model.
Board Type
Memory Types
Description
C3
LMM XMM XMMC
Parallax Open Source Hardware with Flash
DEMOBOARD
LMM
Parallax Propeller Demoboard
DRACBLADE
LMM XMM XMMC
3rd Party SBC with SRAM
EEPROM
LMM XMMC
Any Propeller with a single 64KB+ EEPROM
HYDRA
LMM XMMC
Parallax Hydra with 128KB EEPROM
SDRAM
LMM XMM XMMC
3rd Party GadgetGangster SDRAM Module
SSF
LMM XMMC
3rd Party Spin Socket Flash or compatible design
Other board types:
Board Type
Memory Types
Description
PROTOBOARD
LMM XMMC
Parallax Propeller Protoboard with 64KB EEPROM
QUICKSTART
LMM XMMC
Parallax Propeller QuickStart with 64KB EEPROM
HUB
LMM
Generic LMM board type for any Parallax board.
PPDB
LMM
Parallax Professional Development Board
BACKPACK
LMM XMMC
Parallax Propeller Backpack with 64KB EEPROM
So, remind me ... what exactly was the point of this "survey" again?
Ross.
Part of the point of the survey as stated in post one is to ensure we have a solution where engineers can develop their own solution. The other part was to ensure we have a minimum set for testing.
"Please help determine which external memory hardware solutions should be added to the initial Propeller GCC release. Hardware developers can easily add their own solution, but we need a minimum set for testing.
The number of entries allowed by the survey tool is limiting, and I don't want to seem biased. Please just mention the hardware you have in a reply. We already have drivers for C3, SpinSocket-Flash, DracBlade, and SDRAM."
The only reason for the solutions in hand was to prove that they could be done, and by extension prove that other solutions could be added. I'm still working on the documentation for adding a new design. It will be released later.
Replies that have been mentioned:
RamPage, FlashPoint, W25X chips, AT45DB***, RamBlade, and TriBlade.
I've already said that RamPage, FlashPoint, and Duane Degn's W25X design could be supported. Most of the work required for these was done many months ago.
The Atmel Dataflash AT45DB*** solution is a fair suggestion, but may have to wait for a volunteer.The parallel bus Dataflash which I thought was the perfect solution long ago is end of life.
RamBlade and TriBlade are end of life. Unless there is a volunteer for them, they won't be supported. If you have something not end of life and are willing to help develop and test the solution, we can implement it.
As I said, in the end, the "officially supported" list at GA release is up to Parallax, Inc. It is not up to me. Right now, they are not committed to more than 2 solutions. For any solution to be seriously considered, it should have support from the developer. Think about it.
The only reason the TriBlade pcb is not available is because I believe the pcbs are too expensive for me to outlay the funds. If someone wants a few of them, then they can be made at a price. However, there are a number of them out there, plus clones.
Anyway Steve, you obviously have a hidden agenda. I never said I was not willing to cooperate. Quite the contrary. I just cannot help in GCC project because I do not know anything about GCC and very little about C.
You asked... and I replied (to what I thought was your intent of this thread)... to which you responded...
I thought I merely replied to what I thought was a simple question. I offered hardware for testing. I have published my drivers (MIT licence) and schematics. I was told to go and write my own drivers. There has been no information as far as I am aware to be able to write my own drivers. So what do you expect! Now I am no longer interested. My boards will run fine on Catalina.
Even if we provide a driver, you still need to verify your board works suitably well. This is too much to ask? I think not.
Of course. I fully expect you to do that. No bias there
What agenda would that be? There is no agenda. Show me your ability to cooperate. Why all this distortion?
Ray
Ray
However, Parallax needs a flexible C solution to attract bigger customers and maintain a presence in education.
We hobbyists are good customers, but our purchases alone may not be the best growth path.
I have SPIN running from external memory with limits. It's relatively slow but not bad. One limit stands out among the rest:
the structure of SPIN restricts the size of the program without special tricks - that frustrates further progress.
MP3 codec
USB device driver
JPG codec
etc.
that are all in C...
As a language C is clearly superior to Spin.
As a language and compiler and IDE for the Propeller that is not so clear.
The Prop is memory constrained. The C compilers generate much bigger code than Spin. Some clever person (Chip), realizing this, devised Spin so that you could actually get functionality into the Prop. After all for speed there is PASM in other COGs.
So far no C compiler has managed to come close to Spin on the Prop in terms of the functionality you can get into 32K HUM memory.
As for structures, well on suc small programs as we have in the Prop I wonder if they are much of an advantage.
@Rayman,
Nice idea but I have a sneaking suspicion that such codes won't fit in the Prop II space either. We shall see.
Prop 2 should have enough I/O to implement a high-speed external memory interface to allow big programs...
Maybe we can all get on with one (or two) boards so we can make progress when the time comes.
Sapieha started something and it has basic prototyping features. If we could have a plugin for memories it would be nice.
There are so many possibilities with a P2. ... Wish I could contain my enthusiasm.
Thanks ++ for doing this. I think there are two drivers out there for the Dracblade. There is the original one that was part of the Z80 emulation, and then some clever person (not sure who but it is in the code) improved the code and I think that improved code is the one that is in Catalina. I think the Catalina driver ends up a little faster.
[I need to get my work/life balance sorted - where for "life", substitute "propeller"
Other drivers are possible too - tonight I'm going to try breadboarding up something using TTL counters as I'm hoping to get it fast enough for a video loop which is 4 pasm instructions. If it works, that could be useful as a caching driver.
But I digress. This post is to say thanks to David for doing the Dracblade driver for GCC.
Hi Ray,
I respond to Jazzed when he seems to be simply taking potshots at Catalina, or when he is plainly wrong. I would respond the same way to anyone. I do not have anything against Jazzed personally, and the only thing I have against PropGCC is that some people seem to believe it is a magical pathway to making C++, Fortran and Java practical on the Propeller. It isn't.
Ross.
Dr_Acula
I did the optimization, but from my measurements it's not worth the hassle.
While with that changes I gain a round 20% performance on my board, that is true only in uncached mode.
With 8KB cache the difference is under 1% (just like Ross told us
Furthermore it comes with the risk of not working on all boards (i.e. I have only one delay instruction between enable and read, same for write gate).
So I'd suggest David to start with the original driver.
Fortran and Java were not specified for Propeller GCC. Don't make things up please.
The rest is a matter of understanding what the customer wants and providing it.
My (belated) thanks!
Yes the delays might be an issue if the memory chip and propeller are some distance apart. And I agree - with caching, the absolute speed of any external memory becomes less important.
Hi Jazzed,
I've moved on. I was not responding to you - I was correcting a comment from Ray, who was mistaken about my having something against you.
Also, I'm not making things up - it just seem that a few things have been forgotten. Perhaps you will recall this quote from the very first GCC announcement by Ken (bold emphasis added by me):
Also, perhaps you may remember making this comment in the same thread:
Or perhaps this one:
I presume from your response that you have now considered the other languages that GCC supports and have decided not to support them?
I apologize if I missed that clarification.
Ross.
"and the only thing I have against PropGCC is that some people seem to believe it is a magical pathway to making C++, Fortran and Java practical on the Propeller. It isn't."
Clearly your answers prove Rays point that you have animosity towards GCC which is an effort I'm responsible for and by extension animosity towards me.
We talked about languages. Parallax wants C/C++. The other languages are possible, but not specified for this project. The other languages were not requested by Parallax and are not in the requirements. We are providing what GCC provides as specified for C/C++. I'm delivering what Parallax wants. Can you?
Please stop spewing arguments and manipulative propaganda. It's not doing anyone any good.