Let's say I abandon the idea of using the Propeller Memory Card.......
Are there any DIP flash memory chips that are compatible with SimpleIDE Version 1.0.2(RC2) and the drivers delivered with that package????
Yes, XMMC worked fine with a number of different external flash, SRAM and even SDRAM memory. Certainly, the flash chip that is included on the C3 works fine. Really, the PMC can be used with release_1_0 as well but I have to find the driver. It never got added to release_1_0 because I thought we would be moving to the master branch long ago.
@idbruce, just a reminder, since you will be using SimpleIDE Version 1.0.2(RC2), the use of newcogs in XMM mode are not supported. Yes, you will get access to the extended memory, but you will only be able to implement threads. And this is why I have all my Propeller projects on hold, with interest moving in another direction ever so slowly...
@idbruce, just a reminder, since you will be using SimpleIDE Version 1.0.2(RC2), the use of newcogs in XMM mode are not supported. Yes, you will get access to the extended memory, but you will only be able to implement threads. And this is why I have all my Propeller projects on hold, with interest moving in another direction ever so slowly...
Surely you are joking?
If this is the case, then it is truly a case of fubar.
If this is the case, then it is truly a case of fubar.
The Propeller isn't a PC. There are tradeoffs associated with using a limited resource device like the Propeller. When we first developed the XMM support in PropGCC we assumed that people would write a single "main application" that was written in C or C++ and ran in a single COG. This would be accompanied by a number of either COG C or PASM drivers that would run in the other COGs. This is, in fact, how Spin programs seem to be written most of the time. Later, Parallax wanted the ability to run XMM C or C++ code in more than one COG at a time. This has a big cost associated with it because you end up a cache for each COG that is running XMM code and those caches necessarily are in hub memory and reduce the amount of hub memory that is available for your program. So in the process of gaining the ability to run XMMC on multiple COGs, you lose some of one of your most valuable resources, hub memory. I guess we could implement XMM without a cache but that would be significantly slower unless you're willing to dedicate a large number of pins to a parallel interface to external SRAM or SDRAM. If you have any better suggestions as to how this can all be managed, I'd be happy to hear them.
If you have any better suggestions as to how this can all be managed, I'd be happy to hear them.
I don't have any better ideas.... my comments:
Surely you are joking?
If this is the case, then it is truly a case of fubar.
were intended to mean that this was something that I was unaware of and that my situation is all screwed up and that I must reevaluate all my plans. It was not intended to mean that alot of the thought did not go into the current setup, because I certainly could not have come up with anything viable.
were intended to mean that this was something that I was unaware of and that my situation is all screwed up and that I must reevaluate all my plans. It was not intended to mean that alot of the thought did not go into the current setup, because I certainly could not have come up with anything viable.
What kind of XMM support do you need to implement your plans? Can you post a list of your requirements so I can see if we can meet them?
As close as I can determine and what I do know, I will do my best to give you an overall view.
I am currently already maxing out my memory on one propeller chip and that does not include all the features that I want to support. At the present point, my code is failing, and I believe the main reason is due to insuffient stack space for one of the cogs, but if I increase the stack space or add the additional features that I want, the hub overflows.
In the current setup, the program will be running at least five cogs full time and it will be necessary to implement locks.
I am currently thinking about a different strategy of dividing the code amongst two Propellers and running about 9 or 10 cogs full time. I think a two Propeller design will eliminate most of the headaches that I am now getting but I could be wrong and it may compound them.
Being able to compile C into LMM or raw COG PASM is pretty amazing. I for one thought it could never happen back in the day. One of those "impossible on the Propeller" things that got done.
Then we get to the problem that HUB RAM is to small and we need external memory for any useful C programs. OK it's possibly reasonable to expect to be able to fetch code from external memory and run it. All be it we are now running at a snails pace compared to an MCU with the memory space.
Now I hear we get to the idea of multiple COGs being able to execute code from external memory at the same time!
Do what? How is that even sensible in any way? What kind of performance does that give? Isn't it even slower than running multiple threads from a single COG that use external RAM?
I am currently thinking about a different strategy of dividing the code amongst two Propellers and running about 9 or 10 cogs full time.
I really have to ask why?
I presume you are still on the Teacup thing here. Well it works on a 2 cent AVR, use that. What advantage is to be gained from a slower and more complex, more expensive Propeller solution?
Being able to compile C into LMM or raw COG PASM is pretty amazing. I for one thought it could never happen back in the day. One of those "impossible on the Propeller" things that got done.
Then we get to the problem that HUB RAM is to small and we need external memory for any useful C programs. OK it's possibly reasonable to expect to be able to fetch code from external memory and run it. All be it we are now running at a snails pace compared to an MCU with the memory space.
Now I hear we get to the idea of multiple COGs being able to execute code from external memory at the same time!
Do what? How is that even sensible in any way? What kind of performance does that give? Isn't it even slower than running multiple threads from a single COG that use external RAM?
Is there something I am missing here?
No, you're not missing anything. You're right that multiple COGs running C code from external memory is likely too slow to be very useful. That is why our first implementation of XMM only supported a single COG running code from external memory. You could argue that you could get four COGs running from external memory, each with a 2K cache, that would perform reasonably well since Steve tested 2K caches and found them acceptable for some use cases. And four 2K caches is about the same size as a single 8K cache which is currently the default for XMM. I haven't done any tests with real programs that run XMM C in multiple COGs to know what the performance would be like. I've only run simple LED blinking code to verify that the multi-COG XMM support actually works. You really run into trouble if you try to put data in external memory and access it from multiple COGs since you then have cache coherency issues. That's why we have stuck with XMMC.
If you have a chance, please test this driver and let me know if it works for you. All you have to do is this (from the directory where you unzipped my file):
propeller-load -b pmc-ab ebasic.elf -r -t
Then type this in the terminal:
10 print "Hello"
run
Here is what you should see:
david-betzs-macbook-pro:pmc dbetz$ propeller-load -b pmc-ab ebasic.elf -r -t
Propeller Version 1 on /dev/cu.usbserial-DAXLIRBW
Loading the serial helper to hub memory
10392 bytes sent
Verifying RAM ... OK
Loading cache driver 'winbond_sqi_flash_sram_xcache.dat'
1964 bytes sent
Loading program image to flash
44168 bytes sent
Loading .xmmkernel
1736 bytes sent
[ Entering terminal mode. Type ESC or Control-C to exit. ]
10 print "Hello"
run
000017CC 19 00 00 17 D8 LIT 000017D8
6104
000017D1 28 02 TRAP 02
Hello000017D3 28 05 TRAP 05
000017D5 00 HALT
OK
Oops! Forgot to turn off the debugging code. Anyway, you get the idea. Let me know if this works with your PMC setup.
It appears that you have success David Is this usable within SimpleIDE?
Yes, it is usable with SimpleIDE. I compiled the ebasic.elf file with the release_1_0 tools. Just put the pmc-ab.cfg file into /opt/parallax/propeller-load along with the .dat file and add pmc-ab.cfg to boards.txt.
Thank you very much for your time and effort. I am certain this will come in handy, and in fact, I may still need it for this project. This may allow me to increase the size of the parse to enable more G + M commands.:)
It is very ironic that you need XMM for exactly the same reason that got me thinking about it about 8 years ago (I.E. Gee codes). I should have just moved on to another chip. Sounds like a good place to find closure for me.
Hmmm.... I guess you don't consider XMM to be a viable solution to this problem? In that case, why did you push its development for so many years?
It is very ironic that you need XMM for exactly the same reason that got me thinking about it about 8 years ago (I.E. Gee codes). I should have just moved on to another chip. Sounds like a good place to find closure for me.
Now you tell me
I am going to give the single Propeller one more shot, by attempting to write my own parser. However yesterday, I was thinking about just adding a PC motherboard and harddrive to the project. That would eliminate 99.9% of my headaches and give me a very wide range of possibilities.
By using a motherboard, I could create a full blown PC app to do everything I need and I could just use the Propeller board as an IO controller.
EDIT: Additionally, at that point, I could add all kinds of supporting apps, with no worries about hub ram or eeprom, with the added benefit, that I would be back to programming in a Windows environment.
I am going to give the single Propeller one more shot, by attempting to write my own parser. However yesterday, I was thinking about just adding a PC motherboard and harddrive to the project. That would eliminate 99.9% of my headaches and give me a very wide range of possibilities.
By using a motherboard, I could create a full blown PC app to do everything I need and I could just use the Propeller board as an IO controller.
EDIT: Additionally, at that point, I could add all kinds of supporting apps, with no worries about hub ram or eeprom, with the added benefit, that I would be back to programming in a Windows environment.
Not a bad solution although I would use a RaspberryPi instead of a PC motherboard.
Not a bad solution although I would use a RaspberryPi instead of a PC motherboard.
I truly don't know anything about using a RaspberryPi, so I really could not debate a comparison. However I do know that with a PC, I can create some nice full blown GUI apps that can be displayed on any monitor. The main benefit would be that I know the Windows environment pretty darn well, but I am certain that a lot has changed over the years. However, for the sake of discussion....
I could take one of my worthless Windows discs, say 98, ME, NT, 2000, etc... and load it onto an old mother board, along with say VS C++ 6.0, and from there I really could do some experimentation, with interfacing the Prop and various GUIs. All the way from a GCODE interpreter to a slicer to a serial terminal.
However, I may look into the RaspberryPi to see why everyone is so gung ho about it.
I truly don't know anything about using a RaspberryPi, so I really could not debate a comparison. However I do know that with a PC, I can create some nice full blown GUI apps that can be displayed on any monitor. The main benefit would be that I know the Windows environment pretty darn well, but I am certain that a lot has changed over the years. However, for the sake of discussion....
I could take one of my worthless Windows discs, say 98, ME, NT, 2000, etc... and load it onto an old mother board, along with say VS C++ 6.0, and from there I really could do some experimentation, with interfacing the Prop and various GUIs. All the way from a GCODE interpreter to a slicer to a serial terminal.
However, I may look into the RaspberryPi to see why everyone is so gung ho about it.
You should be able to create nice GUI apps to run on the RaspberryPi using Qt or any number of other graphical frameworks that run under Linux. You will, however, be limited to HDMI video output. I guess the Pi also supports CVBS but I doubt that would meet your needs. No VGA support that I know of.
You should be able to create nice GUI apps to run on the RaspberryPi using Qt or any number of other graphical frameworks that run under Linux. You will, however, be limited to HDMI video output. I guess the Pi also supports CVBS but I doubt that would meet your needs. No VGA support that I know of.
Thanks for the info.... And thanks once again for all of your help with the PMC. I truly appreciate it.
Comments
Let's say I abandon the idea of using the Propeller Memory Card.......
Are there any DIP flash memory chips that are compatible with SimpleIDE Version 1.0.2(RC2) and the drivers delivered with that package????
Ray
Surely you are joking?
If this is the case, then it is truly a case of fubar.
pmc-ab.zip
I don't have any better ideas.... my comments:
were intended to mean that this was something that I was unaware of and that my situation is all screwed up and that I must reevaluate all my plans. It was not intended to mean that alot of the thought did not go into the current setup, because I certainly could not have come up with anything viable.
As close as I can determine and what I do know, I will do my best to give you an overall view.
I am currently already maxing out my memory on one propeller chip and that does not include all the features that I want to support. At the present point, my code is failing, and I believe the main reason is due to insuffient stack space for one of the cogs, but if I increase the stack space or add the additional features that I want, the hub overflows.
In the current setup, the program will be running at least five cogs full time and it will be necessary to implement locks.
I am currently thinking about a different strategy of dividing the code amongst two Propellers and running about 9 or 10 cogs full time. I think a two Propeller design will eliminate most of the headaches that I am now getting
Being able to compile C into LMM or raw COG PASM is pretty amazing. I for one thought it could never happen back in the day. One of those "impossible on the Propeller" things that got done.
Then we get to the problem that HUB RAM is to small and we need external memory for any useful C programs. OK it's possibly reasonable to expect to be able to fetch code from external memory and run it. All be it we are now running at a snails pace compared to an MCU with the memory space.
Now I hear we get to the idea of multiple COGs being able to execute code from external memory at the same time!
Do what? How is that even sensible in any way? What kind of performance does that give? Isn't it even slower than running multiple threads from a single COG that use external RAM?
Is there something I am missing here?
I presume you are still on the Teacup thing here. Well it works on a 2 cent AVR, use that. What advantage is to be gained from a slower and more complex, more expensive Propeller solution?
If you have a chance, please test this driver and let me know if it works for you. All you have to do is this (from the directory where you unzipped my file):
Then type this in the terminal:
Here is what you should see:
Oops! Forgot to turn off the debugging code. Anyway, you get the idea. Let me know if this works with your PMC setup.
Most cointenly }
It appears that you have success David
pmc-ab.zip
Thank you very much for your time and effort. I am certain this will come in handy, and in fact, I may still need it for this project. This may allow me to increase the size of the parse to enable more G + M commands.:)
Now you tell me
I am going to give the single Propeller one more shot, by attempting to write my own parser. However yesterday, I was thinking about just adding a PC motherboard and harddrive to the project. That would eliminate 99.9% of my headaches and give me a very wide range of possibilities.
By using a motherboard, I could create a full blown PC app to do everything I need and I could just use the Propeller board as an IO controller.
EDIT: Additionally, at that point, I could add all kinds of supporting apps, with no worries about hub ram or eeprom, with the added benefit, that I would be back to programming in a Windows environment.
I truly don't know anything about using a RaspberryPi, so I really could not debate a comparison. However I do know that with a PC, I can create some nice full blown GUI apps that can be displayed on any monitor. The main benefit would be that I know the Windows environment pretty darn well, but I am certain that a lot has changed over the years. However, for the sake of discussion....
I could take one of my worthless Windows discs, say 98, ME, NT, 2000, etc... and load it onto an old mother board, along with say VS C++ 6.0, and from there I really could do some experimentation, with interfacing the Prop and various GUIs. All the way from a GCODE interpreter to a slicer to a serial terminal.
However, I may look into the RaspberryPi to see why everyone is so gung ho about it.
Thanks for the info.... And thanks once again for all of your help with the PMC. I truly appreciate it.