Here's a snap of my Zog Tv Half Height lib and test directories.
Thanks! Andre' wants me to port his tile graphics driver. I haven't looked very closely at it yet so I don't know how hard it will be. I've been spoiled by all of your drivers that you already ported to C! I just need to make a few minor tweaks to get around the fact that I haven't implemented huballoc/hubfree yet. Actually, the ICC keyboard driver was really easy to port. Pretty much all I did was add "HUB" in front of the declaration of the structure used to communicate with the PASM code. :-)
Funny you mention the build process .... I spent some time yesterday on Makefile dependencies Still have some work to do for auto-generating header dependecies. One can use a 2 step make depend with gcc -M or a single step sed script in Makefile. The sed scripting will take a little more time because I've forgotten what to do in the Makefile. I would really like to see a recursive build system invoked only as issuing a single and simple "make all" command.
I have a simple makefile that works but doesn't really understand all of the dependencies. I'm not talking about a better makefile as much as some sort of "binder" utility that would handle creating a custom Spin loader as well as link in all of the appropriate libraries and use the correct linker script to make a correct executable. It might also handle creating COG images from Spin source files as well. Finally, I'd like it to be able to download the resulting binary to the C3 (or whatever board).
I really wish I understood the need for a binder utility. If you mean specifying the drivers, etc like in Catalina, I won't use it and any dependencies on the binder methodology in the source would drive me far away from that particular source tree. I expect that everything can be done in the makefile and linker scripts.
Yes, everything can be done with the makefile but makefiles scare a lot of people. And, even people they don't scare find them a pain to write if they are at all complicated. For some reason I always end up having to read the manual to write a makefile. The details don't stick in my head for some reason. Of course, there is no *need* for a binder. It might make things a bit easier though. Anyway, my main problem now is that I have to edit debug_zog.spin to run a different program since the filename is built into the Spin code. I could modify debug_zog.spin to put up a menu on the TV or serial port to allow a program to be selected but that's kind of a pain too. I'd like to be able to do something like:
prop-cc hello.c -r
That would compile and link the hello.c program and download it into my board. Basically, I'm lazy....
I'm fine as long as there is no interdependency between the source and the binder, but I don't expect you would do anything like that.
I understand the debug_zog.spin editing problem :-) Solutions?
Easiest: program to load is always the same name. A script invokes the build and renames the file.
Alternatively: debug_zog.spin is a loader on the target that can take arguments.
My favorite problem is sending the program to the target without having to constantly modify the SDCARD using the "sneaker net" method. Something like Catalina's payload program would be helpful.
Currently I use Dave Hein's Spinix to download files with y-modem. This is slow and can be tedious. It would be better if a zog loader lived on the filesystem. Dave's Spinix utility programs can all take arguments, and it would not be too hard to make a zog loader for Spinix.
What method do you use for loading/running zog programs today?
What method do you use for loading/running zog programs today?
SneakerNet! :-)
It hasn't been that much of a problem so far because I've mostly been working on getting the cache memory driver working and other infrastructure stuff and so I mostly run the same program all of the time. It is a pain if you are actually doing C development. At one point I had a virtual filesystem driver that I wrote for one of my projects with Andre' where the code running on the MCU could open files on the PC across the serial connection. I guess I could try something like that again. Does anyone make a virtual SD card that will let you load it through a USB connection and have it appear as a normal SD card to the board it's plugged into?
Does anyone make a virtual SD card that will let you load it through a USB connection and have it appear as a normal SD card to the board it's plugged into?
I'm not sure. Tubular had discussed something like that using a PIC. A USB/SD dongle is a good idea for connecting a virtual file-system.
I've considered making a "breakout adapter" dongle for SD or uSD to allow communications via Ethernet or other devices. All one needs for the adapter would be a secure SD/uSD cable connection and some interface on the other end. The other end is harder, but Tubular may have something already - I'll check.
What size of fine needs to be transferred? Is it one big file or a variety of smaller ones?
The PIC approach holds promise, but the internal flash only holds about 100kB. I have run into difficulties sending 32kB EEPROM binaries across to the PIC. But 7kB spin files transfer fine. So perhaps a divide and conquer approach may work here.
A uSD approach might be more reliable. I've used a 4 pole relay to switch who has control of the uSD card (PC vs Micro). That works but you must keep the wires
very short on the "PC" side as it accesses the card at full speed. An overall system might make use of the prop's "reset" button, so the user holds down reset for a few seconds. When in "reset"
1. Control of the uSD card reverts to the PC
2. A utility on the PC detects this, and updates the files, and flushes the write cache. ** may need 5th relay pole to initiate card detect
3. Release of the reset button drops the relays back to control by Prop, and reboots the Prop which can then access the fresh new files.
My favorite problem is sending the program to the target without having to constantly modify the SDCARD using the "sneaker net" method. Something like Catalina's payload program would be helpful.
Currently I use Dave Hein's Spinix to download files with y-modem. This is slow and can be tedious. It would be better if a zog loader lived on the filesystem. Dave's Spinix utility programs can all take arguments, and it would not be too hard to make a zog loader for Spinix.
Has anyone written an open source C library for downloading the Propeller?
I like the idea of a remote file system on the PC accessed via serial from the Prop, Would be a treat when developing C for the Prop, saves having to manually transfer files to SD or one could work with no SD at all.
Does anyone know if the GNU linker does function level linking when resolving symbols from a library? I know it used to be recommended to put each library function in a separate file so that referencing one didn't drag in all of the rest. Is this still true or is the linker able to pull just one function out of a file and leave the rest unlinked? I'm making my Propeller extensions into a library and I want to avoid linking in any functions that aren't actually referenced by the user program.
In my recent experiments with building statically linked programs I was surprised to find that using one function from a module pulled in all other functions in that module. So I would say it is best to split them up as much as possible.
In my recent experiments with building statically linked programs I was surprised to find that using one function from a module pulled in all other functions in that module. So I would say it is best to split them up as much as possible.
I wonder if giving the functions the "weak" attribute would prevent them from being included if they aren't referenced?
void __attribute__ ((weak)) my_function()
{
// do something interesting
}
I guess "weak" just allows function overloads ... could have other meanings, but I wouldn't count on it.
I started working on refining the pload loader since I have most of the code already and am adding a "save to SD card" protocol to eliminate the need for using y-modem stuff.
I started working on refining the pload loader since I have most of the code already and am adding a "save to SD card" protocol to eliminate the need for using y-modem stuff.
I guess maybe I should wait for your pload work to be done before attempting anything of my own to avoid duplicating efforts. I'm planning something slightly different. Since I use a SPI flash chip for ZPU code on the C3 I think I'd like a loader that loads code directly into that flash chip rather than writing it to the SD card. I'm assuming your loader will work by first loading a "helper program" that knows how to write to the SD card. I guess I can just substitute a helper program that knows how to write to the C3 SPI flash chip. I think I saw something in your pload code that mentioned only being able to use single digit COM ports under Windows. Is that restriction still in effect? Unfortunately, I have plugged so many USB serial devices into my laptop that they all have very high COM port numbers.
The com port numbers is a Cygwin problem. Should be able to compile with VC++ for windows applications. If the C++ program that Heater points to is compilable using VC++ already, that is an advantage and might be pursued in parallel.
I'm very comfortable with the reliability of pload under linux. I haven't tried it on a 64 bit machine though.
You're right of course about a 2 step loader. As long as the transfer mechanism in the second part agrees with what is loaded in the first part, it doesn't matter much what happens.
The pc loader syntax I'm thinking to use is "pload port loader.binary [-s savefile -r]" where -s is savefile and -r is optional reset. It would be nice to not have to load the initial loader.binary each time for multiple files, so that may become optional or the number of files may increase. If I can get away with not having to program the EEPROM, I will
If I can get away with not having to program the EEPROM, I will
Hmmm... Looks like we have different goals. My plan is just the opposite. I want to program the EEPROM and the flash but don't want to write to the SD card. Maybe we'd better work in parallel. :-)
Hmmm... Looks like we have different goals. My plan is just the opposite. I want to program the EEPROM and the flash but don't want to write to the SD card. Maybe we'd better work in parallel. :-)
Probably so. I'm more interested in load speed and being able to preserve the contents of EEPROM for the user if possible. That would also allow a Spin O/S or some other non-volatile user information to remain on the EEPROM for example.
The main goal of course is to have something much less tedious than Y-modem for transferring applications to fixed media whether it the target is Flash or SD card for me is irrelevant, but obviously I'm more interested in SD since the SDRAM solution doesn't have Flash.
I'm getting ready to release an SDRAM ZOG source package soon. It is different from what you have now, but I expect there to be some merging over time. Having a the smallest possible ZOG footprint is a high priority and you have apparently made progress in that regard - but I don't know how much that is yet
mpark had a simple error detection protocol for downloading in Sphinx. Suggest you look at it. I too like the idea of being able to download straight to the SD card as I believe the flash should remain untouched - in fact I disable writes by default in hardware on the RamBlade because I do not want the SD bootloader to be able to be corrupted. All my new products will have microSD.
mpark had a simple error detection protocol for downloading in Sphinx. Suggest you look at it. I too like the idea of being able to download straight to the SD card as I believe the flash should remain untouched - in fact I disable writes by default in hardware on the RamBlade because I do not want the SD bootloader to be able to be corrupted. All my new products will have microSD.
The problem is that the C3 doesn't have enough SRAM to run a very large C program. The only alternatives are to either use its SPI flash or try to run code directly off of the SD card. I haven't tried the latter yet but I suppose it might work. It may be slower than running from the SPI flash though.
. If the C++ program that Heater points to is compilable using VC++ already
Perhaps, if you have the Qt libraries. I'd rather use the IDE that comes for free with Qt. http://qt.nokia.com/downloads Then you have cross platform development.
Anyway the idea was to convert that code from C++ to C and get rid of all the Qt dependencies.
I'm quite happy to build it with Qt into a non GUI command line only program.
I just thought it would be nice to have a straight C version that could then be used on other micros. Like, replace the Props EEPROM with a AVR/PIC or whatever that can boot the Prop , from an SD card say, and then provides services to the Prop, like USB.
Jazzed: Thanks for your pload code. I stole what I needed from PLoadLib.c and I now have a command line program that can download the C3 over the USB connection. I'm going to expand this to something that can download files either onto the SD card or directly to the C3 flash or SRAM. I suppose that everything except the part that downloads to flash could be used by your SDRAM module as well. Are they available yet through Gadget Gangster?
I could send you my loader if you want to test it on your board. It should work with any Propeller I guess. Also, it was compiled with Visual C++ Express so it can handle any port numbers.
I'm working on a loader program for the C3 and am having trouble with the serial port driver on Windows. I'm using jazzed's code for downloading a Spin helper program into hub memory. That part seems to be working fine (thanks jazzed!) but then when I try to follow that with using the same serial port to write my compiled ZPU code to either the SD card or the C3 SPI flash I get an error return from the Windows WriteFile API. The message that gets printed is "insufficient system resources" but that doesn't really make any sense to me since the hub memory download worked fine on the same port. The only thing I can think of is that the port gets reset on the Propeller side when the helper program is started. Is there anything special I need to do to maintain a serial connection over the starting of a Spin program? Does something have to be done on the Windows side to reset the port?
Edit: Sorry for the false alarm. I messed up one of the parameters to WriteFile and that was causing the error. My loader still isn't working but at least I'm getting closer!
Attached is the zsdram01.zip Linux release for the Propeller Platform & SDRAM module.
The enclosed README.linux file has instructions and other information.
The release includes source for a functional loader which happily uploads programs to SDCARD faster than Y-modem with a single command such as: ./load.sh test/Tv2Text/main.bin /dev/ttyUSB0 The upload to SDCARD uses erase and append - there is room for performance improvement.
I'll be adding a link to the zip and brief instructions on the SDRAM thread.
Comments
I understand the debug_zog.spin editing problem :-) Solutions?
Easiest: program to load is always the same name. A script invokes the build and renames the file.
Alternatively: debug_zog.spin is a loader on the target that can take arguments.
My favorite problem is sending the program to the target without having to constantly modify the SDCARD using the "sneaker net" method. Something like Catalina's payload program would be helpful.
Currently I use Dave Hein's Spinix to download files with y-modem. This is slow and can be tedious. It would be better if a zog loader lived on the filesystem. Dave's Spinix utility programs can all take arguments, and it would not be too hard to make a zog loader for Spinix.
What method do you use for loading/running zog programs today?
It hasn't been that much of a problem so far because I've mostly been working on getting the cache memory driver working and other infrastructure stuff and so I mostly run the same program all of the time. It is a pain if you are actually doing C development. At one point I had a virtual filesystem driver that I wrote for one of my projects with Andre' where the code running on the MCU could open files on the PC across the serial connection. I guess I could try something like that again. Does anyone make a virtual SD card that will let you load it through a USB connection and have it appear as a normal SD card to the board it's plugged into?
I've considered making a "breakout adapter" dongle for SD or uSD to allow communications via Ethernet or other devices. All one needs for the adapter would be a secure SD/uSD cable connection and some interface on the other end. The other end is harder, but Tubular may have something already - I'll check.
The PIC approach holds promise, but the internal flash only holds about 100kB. I have run into difficulties sending 32kB EEPROM binaries across to the PIC. But 7kB spin files transfer fine. So perhaps a divide and conquer approach may work here.
A uSD approach might be more reliable. I've used a 4 pole relay to switch who has control of the uSD card (PC vs Micro). That works but you must keep the wires
very short on the "PC" side as it accesses the card at full speed. An overall system might make use of the prop's "reset" button, so the user holds down reset for a few seconds. When in "reset"
1. Control of the uSD card reverts to the PC
2. A utility on the PC detects this, and updates the files, and flushes the write cache. ** may need 5th relay pole to initiate card detect
3. Release of the reset button drops the relays back to control by Prop, and reboots the Prop which can then access the fresh new files.
cheers
tubular
@tubular, is there any way to have a controller be a USB device and behave like an SDcard simultaneously?
There is a C++ propeller loader here http://forums.parallax.com/showthread.php?128018-Boot-Loader-for-an-ARM-Linux-System
It's easily convertible to C.
Or did you mean some other kind of loader?
I like the idea of a remote file system on the PC accessed via serial from the Prop, Would be a treat when developing C for the Prop, saves having to manually transfer files to SD or one could work with no SD at all.
void __attribute__ ((weak)) my_function() { // do something interesting }I started working on refining the pload loader since I have most of the code already and am adding a "save to SD card" protocol to eliminate the need for using y-modem stuff.
Thanks,
David
I'm very comfortable with the reliability of pload under linux. I haven't tried it on a 64 bit machine though.
You're right of course about a 2 step loader. As long as the transfer mechanism in the second part agrees with what is loaded in the first part, it doesn't matter much what happens.
The pc loader syntax I'm thinking to use is "pload port loader.binary [-s savefile -r]" where -s is savefile and -r is optional reset. It would be nice to not have to load the initial loader.binary each time for multiple files, so that may become optional or the number of files may increase. If I can get away with not having to program the EEPROM, I will
The main goal of course is to have something much less tedious than Y-modem for transferring applications to fixed media whether it the target is Flash or SD card for me is irrelevant, but obviously I'm more interested in SD since the SDRAM solution doesn't have Flash.
I'm getting ready to release an SDRAM ZOG source package soon. It is different from what you have now, but I expect there to be some merging over time. Having a the smallest possible ZOG footprint is a high priority and you have apparently made progress in that regard - but I don't know how much that is yet
mpark had a simple error detection protocol for downloading in Sphinx. Suggest you look at it. I too like the idea of being able to download straight to the SD card as I believe the flash should remain untouched - in fact I disable writes by default in hardware on the RamBlade because I do not want the SD bootloader to be able to be corrupted. All my new products will have microSD.
Perhaps, if you have the Qt libraries. I'd rather use the IDE that comes for free with Qt. http://qt.nokia.com/downloads Then you have cross platform development.
Anyway the idea was to convert that code from C++ to C and get rid of all the Qt dependencies.
I'm quite happy to build it with Qt into a non GUI command line only program.
I just thought it would be nice to have a straight C version that could then be used on other micros. Like, replace the Props EEPROM with a AVR/PIC or whatever that can boot the Prop , from an SD card say, and then provides services to the Prop, like USB.
Merry Christmas.
Edit: Sorry for the false alarm. I messed up one of the parameters to WriteFile and that was causing the error. My loader still isn't working but at least I'm getting closer!
Attached is the zsdram01.zip Linux release for the Propeller Platform & SDRAM module.
The enclosed README.linux file has instructions and other information.
The release includes source for a functional loader which happily uploads programs to SDCARD faster than Y-modem with a single command such as: ./load.sh test/Tv2Text/main.bin /dev/ttyUSB0 The upload to SDCARD uses erase and append - there is room for performance improvement.
I'll be adding a link to the zip and brief instructions on the SDRAM thread.