Is there any chance that an official Macintosh release will be posted along with the Windows and Linux versions?
I don't think there are enough Mac users to warrant a separate Macintosh release. For those who do want to use Catalina on OS X, the Linux sources can be compiled on a Mac quite readily. I have done this on OS X running in a virtual machine, and everything works except for the serial ports. I suspect this is because I don't actually have a physical Macintosh with real serial ports.
I have posted requests several times for someone who owns a real Macintosh to try and get the serial code working. You don't need any Catalina knowledge to do this - the source code Catalina uses for serial ports is filtched straight off the internet - it is available here.
Ross, I just got a Mac (airbook) to play around with porting applications to Mac...
I'm willing to try anything you have...
Hi Rayman - that would be great!
You don't need anything from me - the rs232 code available here should work on a Mac with some minor modifications - it is fairly simple code that uses fairly standard Unix library calls, and OS X is a Unix variant that does provides all the appropriate libraries.
I got it to compile under OS X fairly easily with gcc, but I could not even get simple demo programs (like the ones given on the same site) to work. From memory, the things I needed to change were the port names (I don't think OS X uses names like "/dev/ttyXX" or "/dev/ttyUSBXX") and some of the tcsetattr() attributes - but nothing ever seemed to quite work as it should have. I don't think I could even get the ports to open successfully, which is what made me think it was due to my use of a virtual machine that didn't support OS X serial ports properly.
Or there's may be something else you need to do on OS X that only a Mac user with some experience using Mac serial ports would know.
Hmm, well unfortunately I have very little Mac experience...
I thought you had an executable for me to try...
Not sure I know how to compile with GCC on a Mac yet...
Hmm, well unfortunately I have very little Mac experience...
I thought you had an executable for me to try...
Not sure I know how to compile with GCC on a Mac yet...
Apple don't make it easy to use open source software tools on their computers (no money in it for them!) but it is possible.
But, I seriously doubt that serial port code will work on a Mac... Still, if you have a modified version, I'd be willing to try it.
Why not? It's very simple code, all the functions are present in the gcc libraries, and it can be made compile quite easily on OS X (this is from memory - I can't recall all the mods I made - but I do remember there weren't many, and they were all fairly obvious - more to do with OS X being a different "flavor" of Unix than anything fundamental).
I was actually a bit surprised that it didn't simply work first time. At the time, I put it down to me running OS X in a virtual, not because the code itself was broken..
Have you thought about using Qt for this? I'm a novice, but I think Qt will let you develop a loader that will work on most platforms...
You may be right. If you want to try it, you may be better off starting with the Propeller Hub loader written in python - available here. That's what I started with.
David's propeller-gcc propeller-load program works fine on Mac without any Qt code. Qt4.x serial is a big pain. Looking forward to the Qt5 solution.
Good - so the rs232.c code should easily be able to made to work on a Mac. It just requires someone with a Mac, a bit of Unix knowledge, and a few hours to spare. I have the latter two, but not the former.
Well, I've got the former, and probably not the latter two... But, if you make something, I can try it for you...
Hi Rayman,
I guess I don't seem to be making myself clear. You don't need anything from me. The code I need to get working is here (as I described earlier). There is also a demo program on that page to try it out (save this as main.c).
If someone can get that program working on a Mac, then we're done. But this needs someone access to a physical Mac, and I guess you will need some experience with Unix and serial I/O.
I just downloaded the code again on my virtual OS X and compiled it using the following command:
I only needed to comment out lines 107 - 116 of rs232.c - these lines refer to baud rates that my version of OS X apparently doesn't support. But the compiler will tell you if this is the case.
I've done a bit more testing on my virtual Mac, and have found and fixed at least one problem with payload on OS X.
Still doesn't actually work though :frown:
I have attached a zip file with the latest sources - if you have gcc installed, all you need to do is unzip them to a directory on your Mac, and then build and test them using the commands:
make payload
payload test -p1
You may need to adjust the parameter to the -p option (1 means /dev/ttys0, 2 means /dev/ttys1 etc). If you leave out the -p option altogether then payload will try and autodetect what port is connected to the Propeller, but I'm not sure this is working yet either.
Note that you need to do this as a suitably authorized user (e.g. root).
Ross, I just tried it... Took me a while because had to figure out some things.
make worked, but gave a warning: "In function PollComport" "comparison is always false".
But, it doesn't seem to work. When I run it I get: "unable to open comport: no such file or directory"
BTW: I installed SimpleIDE to make sure comms are working, and they are. Tried to install Brad's spin tool first, but couldn't find it anymore on Parallax web site...
Ross, I just tried it... Took me a while because had to figure out some things.
make worked, but gave a warning: "In function PollComport" "comparison is always false".
But, it doesn't seem to work. When I run it I get: "unable to open comport: no such file or directory"
Mod the Make file to a a define of __STRICT_ANSI__ to remove the warning:
Change the line that looks like:
CC=gcc
to:
CC=gcc -D=__STRICT_ANSI__
But, as you've seen, it still gives the error on execution :blank: Firstly Mac OS X does not use the same port naming as Linux. Where rs232.c (linux-based) uses something like: "/dev/ttyS0", Mac OS X uses something like "/dev/tty.usbserial-XnnnnXXX" OR "/dev/cu.usbserial-XnnnnXXX" (X = alpha, n = numeric). I've changed rs232.c to use Mac OS X naming of ports, but I still get the error you are seeing. Ran out of time to fully debug and fix, but here's a clue to how it "can" work on Mac OS X...
Patrick Kane wrote ppoke.c, which is an initial utility to work with getting the PropScope to work with an open source application. ppoke.c talks to the PropScope via USB serial and is a good example of how to get serial communications working on Mac OS X and probably Linux as well. The only problem is that every Propeller board or USB adapter will have a different port name. In ppoke.c that name is hard coded currently and a way to select the port or give the port name as an input parameter is really needed.
But, poke.c as an example should show how to get communications going.
I've attached a version of ppoke.c with a dummy port name that you'll need to update with the port name of your test prop board. When your prop board is plugged into your Mac, type "ls /dev" into the Terminal app and you'll get a list of devices, one of which will be your prop board USB serial device (actually, one each of "cu" & "tty" devices will show up for each prop board you have plugged in). Just remember to use a full pathname (i.e. /dev/tty.usbserial-A1013PDN).
It sounds like we are close - I looked at ppoke.c and this code is quite standard and straightforward other than the port name - this makes me think we are close, and that perhaps it just a matter of getting the port names right. It's annoying that OS X doesn't use standard port names, and that there is apparently no way to predict in advance what they will be.
For the moment, I'd suggest just hardcoding the port names in rs232.c - if we can get that working then I'll add a command-line option to override the hardcoded names with something you can specify on the command line.
It sounds like we are close - I looked at ppoke.c and this code is quite standard and straightforward other than the port name - this makes me think we are close, and that perhaps it just a matter of getting the port names right. It's annoying that OS X doesn't use standard port names, and that there is apparently no way to predict in advance what they will be.
For the moment, I'd suggest just hardcoding the port names in rs232.c - if we can get that working then I'll add a command-line option to override the hardcoded names with something you can specify on the command line.
Ross.
Yeah, odd that. But, once you get a port name for a particular board (normally it's FTDI chip's port name) it will stay the same. Notice that in propgcc and it's utilities, most line commands will accept the port name via a "-p" parameter (i.e. propeller-load -p /dev/tty.usbserial-XnnnnXXX). So, it's customary to send the port name to the line command from an IDE or the Terminal window...
... Notice that in propgcc and it's utilities, most line commands will accept the port name via a "-p" parameter (i.e. propeller-load -p /dev/tty.usbserial-XnnnnXXX). ...
Yes, I will do something similar when someone can confirm payload is actually working on OSX.
Note that I have just recompiled Catalina under OSX to make sure everything else is working, and it is. However, a few minor errors have crept into some of the makefiles and scripts:
The makefile in source/lcc needs to have -static removed from the CFLAGS.
The build_all script in source/openspin needs to have the first line (source use_lcc) removed.
The SetLinuxPermissions script in bin needs to be modified to make -R The first parameter in each chmod command.
I will fix these in the next release.
Building Catalina for OS X only takes a few minutes, except for Code::Blocks. I may put a prebuilt binary of Code::Blocks up on SourceForge if anyone is interested. Or at least the compiler plugin - the rest can be downloaded as a binary from the CodeBlocks web site (be sure to get version 10.05).
Yes, I will do something similar when someone can confirm payload is actually working on OSX.
Note that I have just recompiled Catalina under OSX to make sure everything else is working, and it is. However, a few minor errors have crept into some of the makefiles and scripts:
The makefile in source/lcc needs to have -static removed from the CFLAGS.
The build_all script in source/openspin needs to have the first line (source use_lcc) removed.
The SetLinuxPermissions script in bin needs to be modified to make -R The first parameter in each chmod command.
I will fix these in the next release.
Building Catalina for OS X only takes a few minutes, except for Code::Blocks. I may put a prebuilt binary of Code::Blocks up on SourceForge if anyone is interested. Or at least the compiler plugin - the rest can be downloaded as a binary from the CodeBlocks web site (be sure to get version 10.05).
Ross.
On step 1, removing "-static-libgcc" from the line "LDFLAGS=-g -static-libgcc" is also needed, at least on my MacBook Pro running 10.8.4...
After those mods, I'm able to build catalina and install it. When I do a simple compile of the hello_world.c example, I get a file that looks to be a .spin type file with PASM code inside. Is that correct? (i.e. "catalina -c hello_world.c" with no other options)... Apparently, that gets assembled by bstc, homespin or openspin, correct?
When I add "-as" I get a failure to run openspin unless I point to a version of openspin that I built myself from Roy's sources. So, I'm still working on that aspect. Do I need to do a rebuild of openspin inside catalina's source tree seperately? I take that there is no overall Makefile for all of catalina?
I'll also take a look at building payload for Mac OS X within the next few days, as time permits.
On step 1, removing "-static-libgcc" from the line "LDFLAGS=-g -static-libgcc" is also needed, at least on my MacBook Pro running 10.8.4...
After those mods, I'm able to build catalina and install it. When I do a simple compile of the hello_world.c example, I get a file that looks to be a .spin type file with PASM code inside. Is that correct? (i.e. "catalina -c hello_world.c" with no other options)... Apparently, that gets assembled by bstc, homespin or openspin, correct?
When I add "-as" I get a failure to run openspin unless I point to a version of openspin that I built myself from Roy's sources. So, I'm still working on that aspect. Do I need to do a rebuild of openspin inside catalina's source tree seperately? I take that there is no overall Makefile for all of catalina?
I'll also take a look at building payload for Mac OS X within the next few days, as time permits.
dgately
Thanks - the "-static-libgcc" worked for me, but I'll remove that as well.
Yes, you need to build openspin separately. There is no overall makefile. Generally, just use the build_all scripts in each source subdirectory, since they also copy binaries to the bin directory.
By using the -c option for Catalina, you have told it to compile only (i.e. not assemble). This will give you an "obj" file (with Catalina, an obj file is an assembler file). Just leave off the -c and add -lc instead (to specify the standard C library) and Catalina will invoke openspin to generate a binary file:
All,
Mac OS X version of payload now working! Catalina is now 100% functional on OS X!
As I suspected, the amended payload code I posted above was fine - it was just a matter of using the right port name (you have to use the names of the form /dev/cu.usbserial.XXXXXXXX).
I'll post an amended version of payload tomorrow that allows you to specify the serial port as a command line parameter, so you don't have to hardcode it and then recompile payload every time it changes.
I've updated the Errata file (available on SourceForge, or in the second post in this thread) to add the new OS X-friendly version of payload, and also to include various minor changes to scripts and makefiles required to build Catalina under OS X.
Note that there are no OS X binaries - you will have to build Catalina from source (use either of the Linux distributions).
Actually, I'm not even sure if I could generate OS X binaries that would be usable by others - the version of OS X I use in my "virtual" Mac is fairly old. If anyone else wants to volunteer to package up a binary version of Catalina for OS X, feel free!
I've updated the Errata file (available on SourceForge, or in the second post in this thread) to add the new OS X-friendly version of payload, and also to include various minor changes to scripts and makefiles required to build Catalina under OS X.
Note that there are no OS X binaries - you will have to build Catalina from source (use either of the Linux distributions).
Actually, I'm not even sure if I could generate OS X binaries that would be usable by others - the version of OS X I use in my "virtual" Mac is fairly old. If anyone else wants to volunteer to package up a binary version of Catalina for OS X, feel free!
Ross.
Thanks for resolving the Mac OS X payload issue! It's nice to know it's possible to use Catalina on a Mac.
As I suspected, the amended payload code I posted above was fine - it was just a matter of using the right port name (you have to use the names of the form /dev/cu.usbserial.XXXXXXXX).
Ross.
Note: should be "/dev/cu.usbserial-XXXXXXXX". (i.e. a dash "-" between usbserial and XXXXXXXX).
I've rebuilt payload and catalina on Mac OS X 10.8.4. Catalina seems to work, but payload is not quite working for me. It might be my unfamiliarity with catalina/payload. I compiled the demos via build_all and used the following to try to load my Quickstart board:
$ payload hello_world.binary -p /dev/tty.usbserial-A1013PDN
it just hangs there...
Tried:
$ payload hello_world.binary -d -d -p /dev/tty.usbserial-A1013PDN
Catalina Payload 3.11.1
diagnostic level 1
arg: -d
switch: -d
diagnostic level 2
arg: -p
switch: -p
setting port name /dev/tty.usbserial-A1013PDN
using port /dev/tty.usbserial-A1013PDN
executable name = payload
Loading Propeller binary hello_world.binary
File size = 12672
baudrate = 115200
timeout = 250
sync timeout = 100
reset delay = 0
interfile delay = 100
it hangs there again...
There's no indication on the QuickStart that any I/O is taking place from USBSerial (no flashing LEDs).
Do you need other info for debugging?
I'll attach a .zip of my Mac OS X compiled catalina in my next post...
Note: should be "/dev/cu.usbserial-XXXXXXXX". (i.e. a dash "-" between usbserial and XXXXXXXX).
I've rebuilt payload and catalina on Mac OS X 10.8.4. Catalina seems to work, but payload is not quite working for me. It might be my unfamiliarity with catalina/payload.
Arg! make that "my unfamiliarity" with fully testing with all inputs...
I was using "/dev/tty.usbserial-XXXXXXXX" and NOT "/dev/cu.usbserial-XXXXXXXX"... Although you can generally use either, in this case you must use the "cu"-named device. Now, it seems to upload to the QuickStart board!
Still working out some compile issues as my 10.8.4-built catalina would not work on Mac OS X 10.7.5. I'm re-building on 10.7.5 and will test on both systems before I upload a version to this thread for others to test.
Anyone with Mac OS X 10.7.5 or 10.8.n want to try my compiled catalina binaries? These are 64-bit binaries and "might" run on earlier 64-bit systems, as well.
Got Catalina compiled on Mac OS X 10.7.5, which should also work on 10.8 versions... I've attached bin.zip, which includes the Mac OS X-compiled binaries for "most" of what comes with the Catalina download. You'll need to copy the extracted /bin directory over an installed linux-64 catalina download. Catalina should be installed in the path "/usr/local/lib/", then the attached /bin directory should be copied into "/usr/local/lib/catalina/", replacing any bin directory that came with the distribution. You'll want Ross' Errata download as well if you want to re-compile any of the catalina toolset.
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica]Catalina wants to run from within the directory: /usr/local/lib/catalina/bin on Mac OS X and Linux.
These instructions should help in getting this pre-compiled Mac OS X version to run. Look in the
/usr/local/lib/catalina/documents/ directory for "Getting Started with Catalina.pdf" for help.
The following steps describe installation and setup for the most part.[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica]1. Download the attached "bin.zip" to your Downloads directory/folder & prepare it for use[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica] If not automatically decompressed double-clicking the .zip file will extract everything[/FONT]
[FONT=Helvetica] to a "bin" directory within your Downloads folder.[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica]2. Using the Terminal application, copy the bin directory to the "/usr/local/lib/catalina" directory[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica] $ cd ~/Downloads[/FONT]
[FONT=Helvetica] $ sudo cp -R bin /usr/local/lib/catalina[/FONT]
[FONT=Helvetica] $ cd /usr/local/lib/catalina[/FONT]
[FONT=Helvetica] $ source use_catalina[/FONT]
[FONT=Helvetica]
[/FONT] [FONT=Helvetica](Note: requires admin authorization, so use "sudo" and provide password when requested)[/FONT]
[FONT=Helvetica] (Note: you may want to change the ownership of the entire catalina directory tree to your user if you have problems sourcing the use_catalina file)
[/FONT]
[FONT=Helvetica]3. You'll need to set catalina's executables in your PATH system variable or the system will not easily find catalina's tools.
Add the following 2 lines to an existing ".profile" file within your home directory:[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica] # Set PATH to catalina compiler[/FONT]
[FONT=Helvetica] export PATH=/usr/local/lib/catalina:/usr/local/lib/catalina/bin:$PATH[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica] (Note: use the following to edit .profile. This will create a new .profile if one does not exist)[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica] $ cd $home[/FONT]
[FONT=Helvetica] $ nano .profile[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica]4. After saving changes to the .profile file, use the following to reset the $PATH environment var[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica] $ source .profile[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica]5. Go to the /usr/local/lib/catalina/demos directory and try the following:[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica] $ sudo ./build_all
$ payload -i -p /dev/cu..usbserial-XnnnnXXX hello_world -r 2000 -t 2000 -u 2000 [/FONT]
[FONT=Helvetica]
(Note: my Mac required each of the 2000 millisecond options in order to upload the binary to a QuickStart, your mileage may vary...)[/FONT]
Anyone with Mac OS X 10.7.5 or 10.8.n want to try my compiled catalina binaries? These are 64-bit binaries and "might" run on earlier 64-bit systems, as well.
Good work - thanks!
I'm a bit surprised that you need to add 2000 ms to each of the payload timeouts on OS X, although I do know that on Linux this can be a bit unpredictable. For instance, on the same hardware talking to the same Propeller using the same port, 64 bit Linux requires -t 1000 whereas 32 bit Linux doesn't.
You may find you do not need the timeouts if you instead use nice to up the priority of payload. If this doesn't work, I will increase the defaults for OS X.
I'm a bit surprised that you need to add 2000 ms to each of the payload timeouts on OS X, although I do know that on Linux this can be a bit unpredictable. For instance, on the same hardware talking to the same Propeller using the same port, 64 bit Linux requires -t 1000 whereas 32 bit Linux doesn't.
You may find you do not need the timeouts if you instead use nice to up the priority of payload. If this doesn't work, I will increase the defaults for OS X.
Ross.
Yeah, it may not need a full 2 seconds for those options. I had used -r 500 -t 500 -u 500 and had success for a small percentage of tests, so I bumped to 1000, 1500 then 2000 until all tests succeeded. It may just be one of those options that needs > 500 or 1000... I wouldn't change the defaults until further testing is completed.
Let's see if any other Mac users can run the binaries. I'm not sure if just the bin directory is enough, but I was unable to attach any more of the catalina directory tree because of size issues.
Comments
I don't think there are enough Mac users to warrant a separate Macintosh release. For those who do want to use Catalina on OS X, the Linux sources can be compiled on a Mac quite readily. I have done this on OS X running in a virtual machine, and everything works except for the serial ports. I suspect this is because I don't actually have a physical Macintosh with real serial ports.
I have posted requests several times for someone who owns a real Macintosh to try and get the serial code working. You don't need any Catalina knowledge to do this - the source code Catalina uses for serial ports is filtched straight off the internet - it is available here.
Ross.
I'm willing to try anything you have...
Hi Rayman - that would be great!
You don't need anything from me - the rs232 code available here should work on a Mac with some minor modifications - it is fairly simple code that uses fairly standard Unix library calls, and OS X is a Unix variant that does provides all the appropriate libraries.
I got it to compile under OS X fairly easily with gcc, but I could not even get simple demo programs (like the ones given on the same site) to work. From memory, the things I needed to change were the port names (I don't think OS X uses names like "/dev/ttyXX" or "/dev/ttyUSBXX") and some of the tcsetattr() attributes - but nothing ever seemed to quite work as it should have. I don't think I could even get the ports to open successfully, which is what made me think it was due to my use of a virtual machine that didn't support OS X serial ports properly.
Or there's may be something else you need to do on OS X that only a Mac user with some experience using Mac serial ports would know.
Ross.
I thought you had an executable for me to try...
Not sure I know how to compile with GCC on a Mac yet...
Apple don't make it easy to use open source software tools on their computers (no money in it for them!) but it is possible.
Look here for instructions.
Ross.
But, I seriously doubt that serial port code will work on a Mac... Still, if you have a modified version, I'd be willing to try it.
Have you thought about using Qt for this? I'm a novice, but I think Qt will let you develop a loader that will work on most platforms...
Great!
Why not? It's very simple code, all the functions are present in the gcc libraries, and it can be made compile quite easily on OS X (this is from memory - I can't recall all the mods I made - but I do remember there weren't many, and they were all fairly obvious - more to do with OS X being a different "flavor" of Unix than anything fundamental).
I was actually a bit surprised that it didn't simply work first time. At the time, I put it down to me running OS X in a virtual, not because the code itself was broken..
You may be right. If you want to try it, you may be better off starting with the Propeller Hub loader written in python - available here. That's what I started with.
Good - so the rs232.c code should easily be able to made to work on a Mac. It just requires someone with a Mac, a bit of Unix knowledge, and a few hours to spare. I have the latter two, but not the former.
Ross.
Hi Rayman,
I guess I don't seem to be making myself clear. You don't need anything from me. The code I need to get working is here (as I described earlier). There is also a demo program on that page to try it out (save this as main.c).
If someone can get that program working on a Mac, then we're done. But this needs someone access to a physical Mac, and I guess you will need some experience with Unix and serial I/O.
I just downloaded the code again on my virtual OS X and compiled it using the following command:
I only needed to comment out lines 107 - 116 of rs232.c - these lines refer to baud rates that my version of OS X apparently doesn't support. But the compiler will tell you if this is the case.
Ross.
I've done a bit more testing on my virtual Mac, and have found and fixed at least one problem with payload on OS X.
Still doesn't actually work though :frown:
I have attached a zip file with the latest sources - if you have gcc installed, all you need to do is unzip them to a directory on your Mac, and then build and test them using the commands:
You may need to adjust the parameter to the -p option (1 means /dev/ttys0, 2 means /dev/ttys1 etc). If you leave out the -p option altogether then payload will try and autodetect what port is connected to the Propeller, but I'm not sure this is working yet either.
Note that you need to do this as a suitably authorized user (e.g. root).
Ross.
make worked, but gave a warning: "In function PollComport" "comparison is always false".
But, it doesn't seem to work. When I run it I get: "unable to open comport: no such file or directory"
BTW: I installed SimpleIDE to make sure comms are working, and they are. Tried to install Brad's spin tool first, but couldn't find it anymore on Parallax web site...
Mod the Make file to a a define of __STRICT_ANSI__ to remove the warning:
Change the line that looks like: CC=gcc to: CC=gcc -D=__STRICT_ANSI__But, as you've seen, it still gives the error on execution :blank: Firstly Mac OS X does not use the same port naming as Linux. Where rs232.c (linux-based) uses something like: "/dev/ttyS0", Mac OS X uses something like "/dev/tty.usbserial-XnnnnXXX" OR "/dev/cu.usbserial-XnnnnXXX" (X = alpha, n = numeric). I've changed rs232.c to use Mac OS X naming of ports, but I still get the error you are seeing. Ran out of time to fully debug and fix, but here's a clue to how it "can" work on Mac OS X...
Patrick Kane wrote ppoke.c, which is an initial utility to work with getting the PropScope to work with an open source application. ppoke.c talks to the PropScope via USB serial and is a good example of how to get serial communications working on Mac OS X and probably Linux as well. The only problem is that every Propeller board or USB adapter will have a different port name. In ppoke.c that name is hard coded currently and a way to select the port or give the port name as an input parameter is really needed.
But, poke.c as an example should show how to get communications going.
I've attached a version of ppoke.c with a dummy port name that you'll need to update with the port name of your test prop board. When your prop board is plugged into your Mac, type "ls /dev" into the Terminal app and you'll get a list of devices, one of which will be your prop board USB serial device (actually, one each of "cu" & "tty" devices will show up for each prop board you have plugged in). Just remember to use a full pathname (i.e. /dev/tty.usbserial-A1013PDN).
dgately
SimpleIde shows it as "/dev/cu.usbserial-A4007WPv"
I suspect that, to make it even more difficult, Mac has decided to call inbound ports /cu and outputbound ports /tty (or vice versa)...
Actually, I looked it up and it appears that the "tty" version uses flow control where "cu" doesn't. (or something like that).
It sounds like we are close - I looked at ppoke.c and this code is quite standard and straightforward other than the port name - this makes me think we are close, and that perhaps it just a matter of getting the port names right. It's annoying that OS X doesn't use standard port names, and that there is apparently no way to predict in advance what they will be.
For the moment, I'd suggest just hardcoding the port names in rs232.c - if we can get that working then I'll add a command-line option to override the hardcoded names with something you can specify on the command line.
Ross.
Yeah, odd that. But, once you get a port name for a particular board (normally it's FTDI chip's port name) it will stay the same. Notice that in propgcc and it's utilities, most line commands will accept the port name via a "-p" parameter (i.e. propeller-load -p /dev/tty.usbserial-XnnnnXXX). So, it's customary to send the port name to the line command from an IDE or the Terminal window...
dgately
Yes, I will do something similar when someone can confirm payload is actually working on OSX.
Note that I have just recompiled Catalina under OSX to make sure everything else is working, and it is. However, a few minor errors have crept into some of the makefiles and scripts:
- The makefile in source/lcc needs to have -static removed from the CFLAGS.
- The build_all script in source/openspin needs to have the first line (source use_lcc) removed.
- The SetLinuxPermissions script in bin needs to be modified to make -R The first parameter in each chmod command.
I will fix these in the next release.Building Catalina for OS X only takes a few minutes, except for Code::Blocks. I may put a prebuilt binary of Code::Blocks up on SourceForge if anyone is interested. Or at least the compiler plugin - the rest can be downloaded as a binary from the CodeBlocks web site (be sure to get version 10.05).
Ross.
On step 1, removing "-static-libgcc" from the line "LDFLAGS=-g -static-libgcc" is also needed, at least on my MacBook Pro running 10.8.4...
After those mods, I'm able to build catalina and install it. When I do a simple compile of the hello_world.c example, I get a file that looks to be a .spin type file with PASM code inside. Is that correct? (i.e. "catalina -c hello_world.c" with no other options)... Apparently, that gets assembled by bstc, homespin or openspin, correct?
When I add "-as" I get a failure to run openspin unless I point to a version of openspin that I built myself from Roy's sources. So, I'm still working on that aspect. Do I need to do a rebuild of openspin inside catalina's source tree seperately? I take that there is no overall Makefile for all of catalina?
I'll also take a look at building payload for Mac OS X within the next few days, as time permits.
dgately
Thanks - the "-static-libgcc" worked for me, but I'll remove that as well.
Yes, you need to build openspin separately. There is no overall makefile. Generally, just use the build_all scripts in each source subdirectory, since they also copy binaries to the bin directory.
By using the -c option for Catalina, you have told it to compile only (i.e. not assemble). This will give you an "obj" file (with Catalina, an obj file is an assembler file). Just leave off the -c and add -lc instead (to specify the standard C library) and Catalina will invoke openspin to generate a binary file:
Ross.
Mac OS X version of payload now working! Catalina is now 100% functional on OS X!
As I suspected, the amended payload code I posted above was fine - it was just a matter of using the right port name (you have to use the names of the form /dev/cu.usbserial.XXXXXXXX).
I'll post an amended version of payload tomorrow that allows you to specify the serial port as a command line parameter, so you don't have to hardcode it and then recompile payload every time it changes.
Ross.
I've updated the Errata file (available on SourceForge, or in the second post in this thread) to add the new OS X-friendly version of payload, and also to include various minor changes to scripts and makefiles required to build Catalina under OS X.
Note that there are no OS X binaries - you will have to build Catalina from source (use either of the Linux distributions).
Actually, I'm not even sure if I could generate OS X binaries that would be usable by others - the version of OS X I use in my "virtual" Mac is fairly old. If anyone else wants to volunteer to package up a binary version of Catalina for OS X, feel free!
Ross.
Note: should be "/dev/cu.usbserial-XXXXXXXX". (i.e. a dash "-" between usbserial and XXXXXXXX).
I've rebuilt payload and catalina on Mac OS X 10.8.4. Catalina seems to work, but payload is not quite working for me. It might be my unfamiliarity with catalina/payload. I compiled the demos via build_all and used the following to try to load my Quickstart board:
There's no indication on the QuickStart that any I/O is taking place from USBSerial (no flashing LEDs).
Do you need other info for debugging?
I'll attach a .zip of my Mac OS X compiled catalina in my next post...
dgately
This is probably another manifestation of the Quickstart design decision to leave the pull-up off P30.
Arg! make that "my unfamiliarity" with fully testing with all inputs...
I was using "/dev/tty.usbserial-XXXXXXXX" and NOT "/dev/cu.usbserial-XXXXXXXX"... Although you can generally use either, in this case you must use the "cu"-named device. Now, it seems to upload to the QuickStart board!
Still working out some compile issues as my 10.8.4-built catalina would not work on Mac OS X 10.7.5. I'm re-building on 10.7.5 and will test on both systems before I upload a version to this thread for others to test.
Thanks for your patience!
dgately
Got Catalina compiled on Mac OS X 10.7.5, which should also work on 10.8 versions... I've attached bin.zip, which includes the Mac OS X-compiled binaries for "most" of what comes with the Catalina download. You'll need to copy the extracted /bin directory over an installed linux-64 catalina download. Catalina should be installed in the path "/usr/local/lib/", then the attached /bin directory should be copied into "/usr/local/lib/catalina/", replacing any bin directory that came with the distribution. You'll want Ross' Errata download as well if you want to re-compile any of the catalina toolset.
bin.zip
dgately
Good work - thanks!
I'm a bit surprised that you need to add 2000 ms to each of the payload timeouts on OS X, although I do know that on Linux this can be a bit unpredictable. For instance, on the same hardware talking to the same Propeller using the same port, 64 bit Linux requires -t 1000 whereas 32 bit Linux doesn't.
You may find you do not need the timeouts if you instead use nice to up the priority of payload. If this doesn't work, I will increase the defaults for OS X.
Ross.
Yeah, it may not need a full 2 seconds for those options. I had used -r 500 -t 500 -u 500 and had success for a small percentage of tests, so I bumped to 1000, 1500 then 2000 until all tests succeeded. It may just be one of those options that needs > 500 or 1000... I wouldn't change the defaults until further testing is completed.
Let's see if any other Mac users can run the binaries. I'm not sure if just the bin directory is enough, but I was unable to attach any more of the catalina directory tree because of size issues.
Thanks Ross!
dgately
First problem was that there is no "local" folder, so using "/usr/lib/catalina" instead. Is that going to be a problem?
Next, "source use_catalina" doesn't work. There doesn't seem to be a "use_catalina" file...