Very strange. I tried your loader and there's no patching. I'm wondering what would disable patching?
OK, I think I've figured something out. I don't get the patching, because my catching isn't "c3_cache_flash.dat", it's "eeprom_cache.dat"
I'm wondering about these stock dat files. What would need to be changed?
Patching won't work if you strip the symbol information from the ELF file. Is it possible that is what's happening? Send me the ELF file and I'll try to figure out why it isn't working for you.
Not sure which ELF file you are talking about so I am zipping both sd_cache_loader.elf and sd_loader.elf. As far as stripping symbols from the elf file? I'm not real sure what you are talking about. I'm a total noob when it comes to PropGCC, and very unfamiliar with C to begin with.
I appreciate you guys trying to help very much!
The "strip" flag "-s" was used at one point to get an estimate of how big the image was. That is no longer needed since we SimpleIDE precisely calculates the LMM memory requirement from the image. As David said, it can cause patching to fail.
A problem is that I removed the ability to change the strip flag from SimpleIDE, so it may be that a -s is hanging around in an old project file.
Use the attached project and change the board type to your board.
Not sure which ELF file you are talking about so I am zipping both sd_cache_loader.elf and sd_loader.elf. As far as stripping symbols from the elf file? I'm not real sure what you are talking about. I'm a total noob when it comes to PropGCC, and very unfamiliar with C to begin with.
I appreciate you guys trying to help very much!
Sorry but neither of those files is what I was looking for. I forgot that for some reason SimpleIDE calls its executables "a.out" rather than the more common "myapp.elf". I would need the "a.out" that is generated by SimpleIDE. All I'm going to do is run propeller-elf-objdump -t on it to see if it has any symbols so I guess you could try that yourself.
The "strip" flag "-s" was used at one point to get an estimate of how big the image was. That is no longer needed since we SimpleIDE precisely calculates the LMM memory requirement from the image. As David said, it can cause patching to fail.
I'd like to make a stronger statement than this. If you strip the symbols from your executable file (a.out for SimpleIDE and usually something like myapp.elf for programs built with a Makefile) then the loader WILL NOT BE ABLE TO PATCH any user variables. This is because the loader knows which variables to patch by looking them up in the symbol table. If there is no symbol table, it can't patch any variables. The only variables that will end up reflecting values on the board configuration file will be CLKFREQ and CLKMODE which aren't patched in the same way and don't rely on the symbol table because they are at fixed locations in hub memory.
Got it! Thanks for the clarification David. I knew it was something I was doing wrong, but I didn't know what. Seems I should have made a new project. Simple noob mistake. Now what I don't understand is this, What are the requirements for running LMM? It seems everything works now in XMMC. LMM fails to open a file. I only have 32k eeproms so I have not been able to test a 64k.
Got it! Thanks for the clarification David. I knew it was something I was doing wrong, but I didn't know what. Seems I should have made a new project. Simple noob mistake. Now what I don't understand is this, What are the requirements for running LMM? It seems everything works now in XMMC. LMM fails to open a file. I only have 32k eeproms so I have not been able to test a 64k.
Looks like you used a different board type DRACBLADE for the failed LMM case. Try using DRACTOUCH with LMM.
Good eyes! I totally missed that! So, I tried again and it works!
[code]
Project Directory: C:/Users/Joe/Downloads/DrAFile/DrAFile/
propeller-elf-gcc.exe -o a.out -Os -mxmmc -I . -Wall -fno-exceptions -Dprintf=__simple_printf DrAFile.c
No, THANK YOU! Both Steve and David! I'm still scratching my head on what comes next. Might revive the OTHER post, as I believe cache driver is next and that thread contains almost all the resources needed *I'm just too dense to know what to do!*
Once again, you guys rock! Thanks for all your help and your patience!
To keep things really simple, all I'm doing is taking the standard download of SIDE and GCC, and then modifying the Board of Education config file for the 4 SD pin numbers. That is all. So if there is a change somewhere along the line the solution ought to work for the Board of Education as well (and indeed any Propeller board which has 4 prop pins directly connected to an SD card).
I'm finding that C programs fairly quickly run out of space with LMM. So LMM is useful for testing fragments of code and small programs, but for serious programs the generic solution would probably be XMMC, cache from the SD card, and all input and output for debugging is via the programming serial port to the terminal. ie - select XMMC and hit the download arrow. If this works quickly "out of the box" for any propeller board with an SD card, that is a pretty powerful demo that should be able to get lots of people running big C programs. And for the GCC developers, not having to worry about a myriad of external memory cache drivers ought to make life easier.
Should I download the patches above or wait till it gets incorporated in the next version?
@drac, try the files I posted. Put dractouch in "c:\propgcc\propeller-loader\" and use the dractouch for our board... Try running the project and make sure your results are the same.
As for the problem, on my end see post http://forums.parallax.com/showthread.php?140010-Files&p=1099636&viewfull=1#post1099636
I was using an OLD SIDE file which obviously stripped the file. My error was patching.. hope your was too!
I was using an OLD SIDE file which obviously stripped the file. My error was patching.. hope your was too!
I was wondering if the file has been updated by any chance?
Ultimately the aim here would be to be able to take any board that has a SD card and by just changing the pin numbers in the .cfg file it will be possible to run huge C programs without having to worry about patching.
I've taken a look at the files on post #40 and at first glance they seem the same as the ones I have so I think the fix might have been somewhere a bit earlier in the discussion. Was it a patch applied somewhere to SIDE?
In any case, that zip was from the 21st May and looking at the GCC download page the last update seems to be the 14th May so I am not sure if the latest patch is included in that update.
Ultimately what I would like to do to test this is reformat the SD card, erase the GCC install from my computer, download again and test if it all works out of the box. Then write a tiny demo program that creates and opens a file "HELLO.TXT" on the SD card, writes "Hello World" to the file and then closes it.
This would be a very powerful demonstration as it should only be a few lines of code.
I was wondering if the file has been updated by any chance?
Ultimately the aim here would be to be able to take any board that has a SD card and by just changing the pin numbers in the .cfg file it will be possible to run huge C programs without having to worry about patching.
I've taken a look at the files on post #40 and at first glance they seem the same as the ones I have so I think the fix might have been somewhere a bit earlier in the discussion. Was it a patch applied somewhere to SIDE?
In any case, that zip was from the 21st May and looking at the GCC download page the last update seems to be the 14th May so I am not sure if the latest patch is included in that update.
Ultimately what I would like to do to test this is reformat the SD card, erase the GCC install from my computer, download again and test if it all works out of the box. Then write a tiny demo program that creates and opens a file "HELLO.TXT" on the SD card, writes "Hello World" to the file and then closes it.
This would be a very powerful demonstration as it should only be a few lines of code.
It is true that you can use the SD cache driver with any board that has an SD card slot by programming the SD SPI pins correctly. The same is true of the spi_flash_cache.dat if your board has a SPI flash chop on it and spi_sram_cache.dat driver if you have a SPI SRAM chip. There is also an sqi_flash_cache.dat driver that works with QuadSPI flash chips but there are at least two different types of those chips and it needs to be separately configured for each one at the moment. The eeprom_cache.dat driver doesn't even require pin setting changes since the EEPROM is always on 28/29.
There are lots of ways to get new boards working with PropGCC XMM modes!
Yes I'm stuck with some basics at the moment. averagejoe got it working and I'd just like to replicate his work. If I can get one file on and off an sd card like he has then I can start to think about porting over the graphics driver.
I've got .wav files playing on this board and I'm working on the essential building blocks for a GUI. eg to select which song to listen to you need a selectbox listing all the music on the sd card. See attached photo of the screen - this is very crude and I haven't even written the code yet to go through and auto highlight one of the items - it is handcoded at the moment, but it is a demo of the graphics and replicating what the Opera web browser looks like with this html
SDBMPtoRam(string("arrdn18.bmp")) ' down arrow 16x18
SelectBoxStart(x1,y1,x2,filenumber-1) 'x1,y1,x2 file number of the down arrow bitmap
SelectBoxItems(x1,y1,x2,4) ' 4 items in this box
f := Loadfont(string("Arial16.ifn")) ' file 9 black on white font
curx := x1 +3 ' position of text based on location of select box
cury := y1
TextT(f,string("File1.wav")) ' text
f2 := Loadfont(string("Arial16B.ifn")) ' file 10 white on dark blue for highlighted
curx := x1+3 ' position of text based on location of select box
cury := y1+20
Drawline(x1-1,y1+19,x2,y1+19+18,RGBtoWord(10,36,106)) ' dark blue background for arial16b font
TextT(f2,string("File1.wav")) ' text
curx := x1+3
cury +=18
TextT(f,string("File2.wav")) ' unhighlighted text
curx := x1+3
cury +=18
TextT(f,string("File3.wav"))
curx := x1+3
cury +=18
TextT(f,string("File4.wav"))
I know when the fundamentals are working that this is going to work better in C. It can be abstracted to code that is more like C# eg combobox.items.additem("file1.wav") - or to html code, and create a C object that behind the scenes can worry about font loading and arrow buttons.
Sorry to bump this thread again but I still have not managed to replicate averagejoe's work and get the program to open a file on an SD card.
Somewhere around post #36 on this thread someone did something which worked. About that time there were quite a number of attachments. I suspect one of these contains the answer, but there are a number of red herrings as well.
I think it was a patch that was applied to SimpleIDE. But I may be wrong there - maybe a.pex or a .cfg file got changed.
At the moment I'm coding in Spin and Catalina and can't really use PropGCC for anything very useful without the ability to access files on the SD card.
I think the answer might be in this
The "strip" flag "-s" was used at one point to get an estimate of how big the image was. That is no longer needed since we SimpleIDE precisely calculates the LMM memory requirement from the image. As David said, it can cause patching to fail.
A problem is that I removed the ability to change the strip flag from SimpleIDE, so it may be that a -s is hanging around in an old project file.
as I have a "-s" at the end of my compile as well.
Is there a link to the latest SimpleIDE? Actually, on that point, at the beginning of this alpha test forum are a couple of sticky threads. Any chance of a link in one of those stickies to 1) the PropGCC downloads and/or 2) the SimpleIDE download?
Any help here would be most appreciated as I'm bursting with cool ideas for a GUI operating system for the propeller!
All a bit confusing. Before we bundle it up in the next version, just a thought. I am using a file called Touch161.cfg. You I think called it Dractouch.cfg and I got a bit confused looking down the list as all the "Drac..." files are the Dracblade boards which use a completely different memory system.
But I am not really happy with Touch161 either.
So - thinking cap on, can we think of a name for this board? It can be the joeboard or something - I don't really care, as it was your design. So you get to name it
Once we have a name, we can tell jazzed what it is and he can include the .cfg file with that name.
Yes this has something to do with the cache driver. I'm a bit fuzzy on the exact details, but it's necessary to get xmmc working properly. The cache driver should work decently, although I think I have discovered a flaw. There is no bus locking mechanism in place which needs to be fixed!
Now, the bit about loading to ram, what does that mean? Is that something to do with the cache driver you have been working on?
The "load-target: ram" line is a bit mysterious. Normally, an xmmc program is loaded to flash memory so it uses different internal functions for writing to external memory since we treat flash as read-only at runtime. Setting the load target to "ram" tells the loader to use the normal runtime "write" function to write data rather than the special flash write function. By adding a little code to RAM-only cache drivers we could probably get rid of the need for this option but it is necessary as things stand now. Our philosophy up to this point has been to push as much complexity as possible into the loader so the code running on the Propeller can be as simple as possible.
Comments
I appreciate you guys trying to help very much!
A problem is that I removed the ability to change the strip flag from SimpleIDE, so it may be that a -s is hanging around in an old project file.
Use the attached project and change the board type to your board.
Thanks for your patience,
--Steve
*edit* the previous was LMM, here's XMMC *which works?*:
Looks like you used a different board type DRACBLADE for the failed LMM case. Try using DRACTOUCH with LMM.
*edit*
The attached zip contains the board config file *to be placed in "c:\propgcc\propeller-load\"* as well as the a.out and a.pex and autorun.pex!
What about LMM?
Thanks!
--Steve
Once again, you guys rock! Thanks for all your help and your patience!
What was the answer in the end?
To keep things really simple, all I'm doing is taking the standard download of SIDE and GCC, and then modifying the Board of Education config file for the 4 SD pin numbers. That is all. So if there is a change somewhere along the line the solution ought to work for the Board of Education as well (and indeed any Propeller board which has 4 prop pins directly connected to an SD card).
I'm finding that C programs fairly quickly run out of space with LMM. So LMM is useful for testing fragments of code and small programs, but for serious programs the generic solution would probably be XMMC, cache from the SD card, and all input and output for debugging is via the programming serial port to the terminal. ie - select XMMC and hit the download arrow. If this works quickly "out of the box" for any propeller board with an SD card, that is a pretty powerful demo that should be able to get lots of people running big C programs. And for the GCC developers, not having to worry about a myriad of external memory cache drivers ought to make life easier.
Should I download the patches above or wait till it gets incorporated in the next version?
As for the problem, on my end see post http://forums.parallax.com/showthread.php?140010-Files&p=1099636&viewfull=1#post1099636
I was using an OLD SIDE file which obviously stripped the file. My error was patching.. hope your was too!
I was wondering if the file has been updated by any chance?
Ultimately the aim here would be to be able to take any board that has a SD card and by just changing the pin numbers in the .cfg file it will be possible to run huge C programs without having to worry about patching.
I've taken a look at the files on post #40 and at first glance they seem the same as the ones I have so I think the fix might have been somewhere a bit earlier in the discussion. Was it a patch applied somewhere to SIDE?
In any case, that zip was from the 21st May and looking at the GCC download page the last update seems to be the 14th May so I am not sure if the latest patch is included in that update.
Ultimately what I would like to do to test this is reformat the SD card, erase the GCC install from my computer, download again and test if it all works out of the box. Then write a tiny demo program that creates and opens a file "HELLO.TXT" on the SD card, writes "Hello World" to the file and then closes it.
This would be a very powerful demonstration as it should only be a few lines of code.
There are lots of ways to get new boards working with PropGCC XMM modes!
Yes I'm stuck with some basics at the moment. averagejoe got it working and I'd just like to replicate his work. If I can get one file on and off an sd card like he has then I can start to think about porting over the graphics driver.
I've got .wav files playing on this board and I'm working on the essential building blocks for a GUI. eg to select which song to listen to you need a selectbox listing all the music on the sd card. See attached photo of the screen - this is very crude and I haven't even written the code yet to go through and auto highlight one of the items - it is handcoded at the moment, but it is a demo of the graphics and replicating what the Opera web browser looks like with this html
SDBMPtoRam(string("arrdn18.bmp")) ' down arrow 16x18 SelectBoxStart(x1,y1,x2,filenumber-1) 'x1,y1,x2 file number of the down arrow bitmap SelectBoxItems(x1,y1,x2,4) ' 4 items in this box f := Loadfont(string("Arial16.ifn")) ' file 9 black on white font curx := x1 +3 ' position of text based on location of select box cury := y1 TextT(f,string("File1.wav")) ' text f2 := Loadfont(string("Arial16B.ifn")) ' file 10 white on dark blue for highlighted curx := x1+3 ' position of text based on location of select box cury := y1+20 Drawline(x1-1,y1+19,x2,y1+19+18,RGBtoWord(10,36,106)) ' dark blue background for arial16b font TextT(f2,string("File1.wav")) ' text curx := x1+3 cury +=18 TextT(f,string("File2.wav")) ' unhighlighted text curx := x1+3 cury +=18 TextT(f,string("File3.wav")) curx := x1+3 cury +=18 TextT(f,string("File4.wav"))I know when the fundamentals are working that this is going to work better in C. It can be abstracted to code that is more like C# eg combobox.items.additem("file1.wav") - or to html code, and create a C object that behind the scenes can worry about font loading and arrow buttons.
Somewhere around post #36 on this thread someone did something which worked. About that time there were quite a number of attachments. I suspect one of these contains the answer, but there are a number of red herrings as well.
I think it was a patch that was applied to SimpleIDE. But I may be wrong there - maybe a.pex or a .cfg file got changed.
I have been going to back to the download page regularly http://code.google.com/p/propgcc/downloads/list but the files have not been updated since 14th May.
At the moment I'm coding in Spin and Catalina and can't really use PropGCC for anything very useful without the ability to access files on the SD card.
I think the answer might be in this
as I have a "-s" at the end of my compile as well. Is there a link to the latest SimpleIDE? Actually, on that point, at the beginning of this alpha test forum are a couple of sticky threads. Any chance of a link in one of those stickies to 1) the PropGCC downloads and/or 2) the SimpleIDE download?
Any help here would be most appreciated as I'm bursting with cool ideas for a GUI operating system for the propeller!
I think it was the files in #40. Plus #36?
All a bit confusing. Before we bundle it up in the next version, just a thought. I am using a file called Touch161.cfg. You I think called it Dractouch.cfg and I got a bit confused looking down the list as all the "Drac..." files are the Dracblade boards which use a completely different memory system.
But I am not really happy with Touch161 either.
So - thinking cap on, can we think of a name for this board? It can be the joeboard or something - I don't really care, as it was your design. So you get to name it
Once we have a name, we can tell jazzed what it is and he can include the .cfg file with that name.
Please note, if you're using my CFG file, you need to add : at the bottom of the file.
Very busy, sorry I'm not able to work on things right now. I'm hoping by next week things should calm down. Keep up the awesome work!
Sounds fine to me.
Now, the bit about loading to ram, what does that mean? Is that something to do with the cache driver you have been working on?