The second passes of each object are done in reverse order child to parent. So the child will not know it's final location during it's second pass. The only time you know any locations for and object in the whole tree is when the second pass is done on the top object. After the top object's second pass is done, it then appends the child objects to itself. All the tables are relative offsets.
I really have explored this quite a lot. Without changing things significantly, it's not feasible right now.
I have not looked at homespun's listing files. It may be possible to make it similar or the same. I think the main thing I want, is to show more information when possible. We'll see.
Brad's listings were very verbose and incredibly useful. He also added source line numbers and file names for stepping through code.
I never bothered with Homespun mostly because it uses that .net stuff that some key people on this forum simply despise (that metric is less important to me these days though).
I did reverse compile Homespun once after hearing that the source would never be released The code appeared to be nicely organized in spite of the author's self-deprecation.
It should mentioned that HomeSpun is now open sourced.
I put that up on github https://github.com/ZiCog/HomeSpun not that I have any intention of tweaking it. But I added some notes about it, how to build on Linux and running on the Raspi.
The .net stuff need not be despised so much now. HomeSpun is open source and it builds with Mono.
I must be doing something wrong. I couldn't get anything to execute correctly tonight.
I'll have a better look on the weekend.
Ross.
Did you try just unzipping the spinwrap zip file and typing "make runcatalina"? That should build and run the test program using Catalina. It expects a Quickstart board but it should run on pretty much any Propeller board. It just toggles pins 16-23 assuming they have LEDs on them but even without that you should get some console output showing that the return values are working correctly.
Did you try just unzipping the spinwrap zip file and typing "make runcatalina"? That should build and run the test program using Catalina. It expects a Quickstart board but it should run on pretty much any Propeller board. It just toggles pins 16-23 assuming they have LEDs on them but even without that you should get some console output showing that the return values are working correctly.
Yes I did. And I do have a QuickStart board. No toggling LEDs and no console output. Something odd is going on, no doubt my fault - I'll have a look on the weekend.
Yes I did. And I do have a QuickStart board. No toggling LEDs and no console output. Something odd is going on, no doubt my fault - I'll have a look on the weekend.
Ross.
Odd. Let me know if you find something I need to fix. The Makefile uses propeller-load to load the program. Any chance you have an old buggy version of that? Maybe you could replace that with payload for Catalina and see if that helps? Any Spin binary loader should do since I'm not using any of the XMM memory models on any of the platforms.
Odd. Let me know if you find something I need to fix. The Makefile uses propeller-load to load the program. Any chance you have an old buggy version of that? Maybe you could replace that with payload for Catalina and see if that helps? Any Spin binary loader should do since I'm not using any of the XMM memory models on any of the platforms.
I replaced propeller-load (which I don't have) with payload. Probably just something stupid I did (or didn't do) - too many gin-and-tonics tonight
Tomorrow is dry martini night, which I find is always better for problem solving .
RossH: I just tried using payload and got the following error message. I had a QuickStart board plugged into my computer when I tried this and had just loaded it using propeller-load so I know it works.
david-betzs-macbook-pro:spinwrap dbetz$ payload testcatalina.binary -i
No Propeller found on any port
Am I getting the payload command line wrong?
Edit: I tried explicitly specifying the port with a different result:
david-betzs-macbook-pro:spinwrap dbetz$ payload -p /dev/cu.usbserial-A601FCST testcatalina.binary -i
Using Propeller (version 1) on port /dev/cu.usbserial-A601FCST for download
Error: No response received
I think spin2cpp will usually be a better option but, as you say, spinwrap can be used in places where Spin execution timing must be maintained or when there are complex relationships between multiple Spin objects which cause problems when translated to C/C++ because of shared variables that need to be marked as "volatile" in the Spin code.
Are there still cases where "volatile" is needed? I made some changes a while back to mark memory as potentially changed inside loops, and I think that should fix most of these places. I'd be interested in seeing examples where volatile is still necessary so we can fix those .
RossH: I just tried using payload and got the following error message. I had a QuickStart board plugged into my computer when I tried this and had just loaded it using propeller-load so I know it works.
david-betzs-macbook-pro:spinwrap dbetz$ payload testcatalina.binary -i
No Propeller found on any port
Am I getting the payload command line wrong?
Edit: I tried explicitly specifying the port with a different result:
david-betzs-macbook-pro:spinwrap dbetz$ payload -p /dev/cu.usbserial-A601FCST testcatalina.binary -i
Using Propeller (version 1) on port /dev/cu.usbserial-A601FCST for download
Error: No response received
Hmmm. Payload works on my "hackintosh". Most likely a timing problem - try adding -t 1000. Alternatively, try using nice to up the priority. (not sure what the OSX equivalent to "nice" is).
Alternatively, for any non-XMM program, using any loader will work - payload does nothing special for plain old LMM or CMM programs.
Hmmm. Payload works on my "hackintosh". Most likely a timing problem - try adding -t 1000. Alternatively, try using nice to up the priority. (not sure what the OSX equivalent to "nice" is).
Alternatively, for any non-XMM program, using any loader will work - payload does nothing special for plain old LMM or CMM programs.
Ross.
I originally *did* use "any loader". I used propeller-load! :-)
What I was trying to do is update the Makefile to use payload for the runcatalina target so users who only had Catalina installed and not PropGCC would be able to run the demo. I'll try -t 1000.
I originally *did* use "any loader". I used propeller-load! :-)
What I was trying to do is update the Makefile to use payload for the runcatalina target so users who only had Catalina installed and not PropGCC would be able to run the demo. I'll try -t 1000.
Okay, -t 1000 was enough to get the LEDs blinking but I'm still not seeing the terminal output. Maybe the terminal emulator doesn't start quickly enough with -t 1000?
Okay, -t 1000 was enough to get the LEDs blinking but I'm still not seeing the terminal output. Maybe the terminal emulator doesn't start quickly enough with -t 1000?
No, that should be ok. But if you are expecting serial output, ensure the appropriate HMI option is selected by adding -C TTY to the compile command. Catalina's default HMI option for the QuickStart board is to use a TV output, since it assumes you have the human interface board installed - probably should changed that :frown:.
Also, how do I get auto port detection to work on the Mac?
Not sure. I don't know how to enumarate avaialble serial ports on a Mac. On a PC you can just iterate across the COMx ports, and on Linux you can just iterate across the /dev/ttyUSBx ports - but the Mac uses a port naming scheme known only to Apple disciples.
No, that should be ok. But if you are expecting serial output, ensure the appropriate HMI option is selected by adding -C TTY to the compile command. Catalina's default HMI option for the QuickStart board is to use a TV output, since it assumes you have the human interface board installed - probably should changed that :frown:.
Ross.
Should this be okay? I'm still not seeing the serial output. I'm assuming that the baud rate defaults to 115200 8N1.
Edit: The odd thing is that I got serial output when I loaded the program with propeller-load even without the -C TTY option and earlier without even the -C CR_ON_LF option. I added that last option because I was only seeing LF and no CR at the end of each line.
The line is broken at column 80 by payload's simpleminded terminal emulator - the screen size is fixed at 80 columns and 24 rows in payload.c.
I should probably make the screen size a command line parameter, or perhaps inherit it from the window payload is run in.
Ross.
I remembered that after I posted that message. Your "simpleminded terminal emulator" is less simple-minded than propeller-load's is! :-)
I've pushed the new Makefile to Google Code and will add it to the top post soon but since I couldn't get auto detect of serial ports working you have to invoke it like this:
That's fine, David - thanks. I'll try again tonight to get mine working.
By the way, does propeller-load do auto detect on OSX? If so, I might steal the code and add it to payload.
Ross.
Yes it does but it uses kind of a hacky way of doing it. It just loops through all of the devices in /dev that match "/dev/cu.usbserial*". How do you do it under Linux?
I've updated the top post to include the changes to use payload as the loader when using Catalina to build. I've also added the beginnings of a README.txt file that says something about how to use spinwrap.
Yes it does but it uses kind of a hacky way of doing it. It just loops through all of the devices in /dev that match "/dev/cu.usbserial*". How do you do it under Linux?
Under both Windows and Linux, the public domain code I use just iterates across a fixed list of likely candidate port names - because both OS's use standard naming. If the port is outside that list (which will only be if you have lots of USB serial ports) then you have to specify it manually.
I think Windows is fine the way it is - but I'll check the propeller-load code to see if I can use it for both OSX and Linux.
Found one of my problems from last night - it was (as I suspected) entirely my fault. When trying to return a variable from a Spin method I declared the method as:
PUB test(arg) | rslt
instead of:
PUB test(arg) : rslt
Spin doesn't warn you this is complete rubbish!
Still not sure why even the LEDs didn't work, but they do with the latest build, so I'll just assume I did something wrong there too.
This is a very useful addition to the Propeller's arsenal of tools - it provides a nice way of wrapping up and interacting with arbitrary Spin objects.
By the way - have you tried calling a Spin method from C programs running in multiple cogs?
Found one of my problems from last night - it was (as I suspected) entirely my fault. When trying to return a variable from a Spin method I declared the method as:
PUB test(arg) | rslt
instead of:
PUB test(arg) : rslt
Spin doesn't warn you this is complete rubbish!
Still not sure why even the LEDs didn't work, but they do with the latest build, so I'll just assume I did something wrong there too.
This is a very useful addition to the Propeller's arsenal of tools - it provides a nice way of wrapping up and interacting with arbitrary Spin objects.
By the way - have you tried calling a Spin method from C programs running in multiple cogs?
Ross.
Doing that will require locking that isn't present in the current code although it could easily be added. It should probably be controlled by a command line option since not all objects will need to be multi-COG-safe.
Comments
I really have explored this quite a lot. Without changing things significantly, it's not feasible right now.
That's ok - just concentrate on adding the listing capability!
Ross.
Brad's listings were very verbose and incredibly useful. He also added source line numbers and file names for stepping through code.
I never bothered with Homespun mostly because it uses that .net stuff that some key people on this forum simply despise (that metric is less important to me these days though).
I did reverse compile Homespun once after hearing that the source would never be released
Hi David,
I must be doing something wrong. I couldn't get anything to execute correctly tonight.
I'll have a better look on the weekend.
Ross.
It should mentioned that HomeSpun is now open sourced.
I put that up on github https://github.com/ZiCog/HomeSpun not that I have any intention of tweaking it. But I added some notes about it, how to build on Linux and running on the Raspi.
The .net stuff need not be despised so much now. HomeSpun is open source and it builds with Mono.
Yes I did. And I do have a QuickStart board. No toggling LEDs and no console output. Something odd is going on, no doubt my fault - I'll have a look on the weekend.
Ross.
I replaced propeller-load (which I don't have) with payload. Probably just something stupid I did (or didn't do) - too many gin-and-tonics tonight
Tomorrow is dry martini night, which I find is always better for problem solving
Ross.
Am I getting the payload command line wrong?
Edit: I tried explicitly specifying the port with a different result:
Are there still cases where "volatile" is needed? I made some changes a while back to mark memory as potentially changed inside loops, and I think that should fix most of these places. I'd be interested in seeing examples where volatile is still necessary so we can fix those
Do you have cookies?
Hmmm. Payload works on my "hackintosh". Most likely a timing problem - try adding -t 1000. Alternatively, try using nice to up the priority. (not sure what the OSX equivalent to "nice" is).
Alternatively, for any non-XMM program, using any loader will work - payload does nothing special for plain old LMM or CMM programs.
Ross.
What I was trying to do is update the Makefile to use payload for the runcatalina target so users who only had Catalina installed and not PropGCC would be able to run the demo. I'll try -t 1000.
No, that should be ok. But if you are expecting serial output, ensure the appropriate HMI option is selected by adding -C TTY to the compile command. Catalina's default HMI option for the QuickStart board is to use a TV output, since it assumes you have the human interface board installed - probably should changed that :frown:.
Ross.
Not sure. I don't know how to enumarate avaialble serial ports on a Mac. On a PC you can just iterate across the COMx ports, and on Linux you can just iterate across the /dev/ttyUSBx ports - but the Mac uses a port naming scheme known only to Apple disciples.
Ross.
Edit: The odd thing is that I got serial output when I loaded the program with propeller-load even without the -C TTY option and earlier without even the -C CR_ON_LF option. I added that last option because I was only seeing LF and no CR at the end of each line.
Not sure why the word "exit' is broken over two lines though.
The line is broken at column 80 by payload's simpleminded terminal emulator - the screen size is fixed at 80 columns and 24 rows in payload.c.
I should probably make the screen size a command line parameter, or perhaps inherit it from the window payload is run in.
Ross.
I've pushed the new Makefile to Google Code and will add it to the top post soon but since I couldn't get auto detect of serial ports working you have to invoke it like this:
That's fine, David - thanks. I'll try again tonight to get mine working.
By the way, does propeller-load do auto detect on OSX? If so, I might steal the code and add it to payload.
Ross.
Under both Windows and Linux, the public domain code I use just iterates across a fixed list of likely candidate port names - because both OS's use standard naming. If the port is outside that list (which will only be if you have lots of USB serial ports) then you have to specify it manually.
I think Windows is fine the way it is - but I'll check the propeller-load code to see if I can use it for both OSX and Linux.
Ross.
Found one of my problems from last night - it was (as I suspected) entirely my fault. When trying to return a variable from a Spin method I declared the method as: instead of: Spin doesn't warn you this is complete rubbish!
Still not sure why even the LEDs didn't work, but they do with the latest build, so I'll just assume I did something wrong there too.
This is a very useful addition to the Propeller's arsenal of tools - it provides a nice way of wrapping up and interacting with arbitrary Spin objects.
By the way - have you tried calling a Spin method from C programs running in multiple cogs?
Ross.
Doing that will require locking that isn't present in the current code although it could easily be added. It should probably be controlled by a command line option since not all objects will need to be multi-COG-safe.