rogloh, can you try running loadp2 without any parameters and look at what it prints out. It should show version 0.010 and a default loader baud rate of 921600. Is that what you see?
Can you try running the following commands to see which ones work, and which ones don't.
No problem Dave... firstly the latest version of loadp2 seems to be 0.011.
RLs-MacBook-Pro:p2gcc roger$ loadp2
loadp2 - a loader for the propeller 2 - version 0.011, 2019-01-29
usage: loadp2
[ -p port ] serial port
[ -b baud ] user baud rate (default is 115200)
[ -l baud ] loader baud rate (default is 921600)
[ -f clkfreq ] clock frequency (default is 80000000)
[ -m clkmode ] clock mode in hex (default is ffffffff)
[ -s address ] starting address in hex (default is 0)
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
[ -v ] enable verbose mode
[ -k ] wait for user input before exit
[ -? ] display a usage message and exit
[ -CHIP ] set load mode for CHIP
[ -FPGA ] set load mode for FPGA
[ -SINGLE ] set load mode for single stage
[ -PATCH ] patch in clock frequency and serial parms
file file to load
Here's the output for the remaining commands... I assume it is meant to auto-detect the P2, but it doesn't work unless I manually specify the USB port it uses.
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out
Could not find a P2
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out
Could not find a P2
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -SINGLE
Could not find a P2
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -CHIP
Could not find a P2
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -SINGLE
Could not find a P2
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -CHIP
Could not find a P2
When I specify the USB port I get these errors... it doesn't like the default higher baud rate.
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -p /dev/cu.usbserial-P23HPBP6
Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -p /dev/cu.usbserial-P23HPBP6
Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -SINGLE -p /dev/cu.usbserial-P23HPBP6
Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t -l 921600 a.out -CHIP -p /dev/cu.usbserial-P23HPBP6
Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -SINGLE -p /dev/cu.usbserial-P23HPBP6
Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
RLs-MacBook-Pro:p2gcc roger$ loadp2 -t a.out -CHIP -p /dev/cu.usbserial-P23HPBP6
Unsupported baudrate 921600. Use 230400, 115200, 57600, 38400, 19200, or 9600
When I both override the baud rate to 115200 AND specify the USB port I get this output... and all three variants downloaded the application to the P2 board and ran it.
Roger, that helps a lot. I looked back at some of the previous posts in this thread, and David Betz said that 921600 works with proploader. Mark_T said that 230400 is the highest that he got to work with p2gcc. Can you try "-l 230400" to see if that works for you? Please also try "-l 230400 -b 230400".
Thanks.
I don't have a Mac, so I can't do a Mac build. I have a Linux system, but I've never posted binaries for Linux. Once in a while I do post Windows binaries along with the source in this thread, but that doesn't happen very often. The best place to get binaries is from David Zemon's site.
How does David Zemon do the Mac builds? Does he use a cross compiler? If so, I'd be interested in knowing where to get it.
Roger, that helps a lot. I looked back at some of the previous posts in this thread, and David Betz said that 921600 works with proploader. Mark_T said that 230400 is the highest that he got to work with p2gcc. Can you try "-l 230400" to see if that works for you? Please also try "-l 230400 -b 230400".
Thanks.
Will try that soon, but right now have been hacking with your osint_linux.c file and managed to get a 2000000 baud download working on the MAC and it works with Ahle's SIDCOG code. For higher baud rates above 230400 you need to bypass the cfsetspeed call and do IOCTL directly instead according to some online information I found. The basic problem is that MACOS X has not defined any higher speeds than 230400 bps in its termios.h file (in OS X 10.10.5 anyway), so regular terminal control API code won't let the higher baud rates work, but it will change the baud rate if you do the IOCTL. Limitation is that the termio stuff then gets out of sync and won't report the raw driver baud rate correctly.
Here's some snippets of what I am trying...
....
#include <limits.h>
#include <signal.h>
#ifdef MACOSX
#include <IOKit/serial/ioss.h>
#endif
#include "osint.h"
....
int serial_baud(unsigned long baud)
{
struct termios sparm;
int tbaud = 0;
#ifdef MACOSX
speed_t speed = 0;
#endif
static unsigned long last_baud = -1;
....
case 19200:
tbaud = B19200;
break;
case 9600:
tbaud = B9600;
break;
default:
#ifdef MACOSX
speed = baud;
tbaud = baud;
if (ioctl(hSerial, IOSSIOSPEED, &speed) == 0) // if IOCTL succeeds continue
break;
#endif
printf("Unsupported baudrate %lu. Use ", baud);
#ifdef B921600
printf("921600, ");
#endif
....
/* get the current options */
chk("tcgetattr", tcgetattr(hSerial, &sparm));
/* set raw input */
#ifdef MACOSX
printf("speed = %d\n", (int)speed);
if (speed == 0) // only if baud was not directly set using IOCTL
chk("cfsetspeed", cfsetspeed(&sparm, tbaud));
#else
chk("cfsetispeed", cfsetispeed(&sparm, tbaud));
chk("cfsetospeed", cfsetospeed(&sparm, tbaud));
#endif
I still get some warnings printed for accessing tcsetattr which I'm trying to clean up... not sure why if I skip that cfsetspeed ... ?
Also just tried "-l 230400" and "-l 230400 -b 230400" and it works. I was using my modified variant but the code I put in skips my changes if I select a supported baud rate in the original case statement, so it should still be valid for your original code too.
UPDATE: I was only testing the download with a non-interactive program. Since then I have found that actual serial data being printed in programs using stdio get messed up if the baud rate is not set to -b 115200. Still investigating that to see if it relates to my own changes...
I don't have a Mac, so I can't do a Mac build. I have a Linux system, but I've never posted binaries for Linux. Once in a while I do post Windows binaries along with the source in this thread, but that doesn't happen very often. The best place to get binaries is from David Zemon's site.
How does David Zemon do the Mac builds? Does he use a cross compiler? If so, I'd be interested in knowing where to get it.
He uses an old machine sitting in @dgately's house running a second TeamCity slave
@"Dave Hein", I can eliminate these tcsetattr errors by just moving the serial baud rate code to be called after putting the terminal device into raw mode etc when the port is first opened, and skipping out of the baud rate update code if the IOCTL method was called. Whether or not this creates any detrimental side effects I am not sure...but I will keep playing with it as is. I've attached the osint_linux.c file so you can diff it to see my entire changes to date. I'm not saying this is the proper way to do it, but I found it worked on my system so perhaps it's something useful.
It would be nice to get the auto P2 port detection working. That seems to be broken on the Mac platform.
Dammit. Noticing weird behaviour with the terminal and p2gcc sample applications using STDIO with my modified p2load. When I choose a supported lower baud rate the test application like fibo.c seems to print out okay, but it will otherwise freeze up on the first printed line if I use a special higher baud rate like 1000000 etc even though the download works. Think it might be related to switching back into terminal modes after using that ioctl, not sure yet...
Roger, thanks for looking into this. I'll have to look at the P1 loader programs to see how they handle higher baud rates. The P1 loaders also have a way of automatically finding the P1 serial port. I believe they look at the entries in the /dev directory.
Also just tried "-l 230400" and "-l 230400 -b 230400" and it works. I was using my modified variant but the code I put in skips my changes if I select a supported baud rate in the original case statement, so it should still be valid for your original code too.
UPDATE: I was only testing the download with a non-interactive program. Since then I have found that actual serial data being printed in programs using stdio get messed up if the baud rate is not set to -b 115200. Still investigating that to see if it relates to my own changes...
Has loadp2 changed recently? This worked fine for me several weeks ago when I tried:
I've made a few changes to loadp2 during the past few weeks, but the only thing specific to the Mac is that I changed the default loader rate from 2000000 to 921600. In theory you should be able to run the same command, but without specifying "-l 921500". I'm not sure why this doesn't work on some Macs.
I just tried the latest loadp2 binary from Zemon's website with the command David Betz's command line and it seems to work.
Well, there might be some issue. Loading up the VGA_640_x_480_8bpp example, the bottom six or so lines of the image is messed up. Like it didn't fully load...
I tried it again, this time without the "-t" and it worked. But, that isn't really proof of anything...
With the native Mac version, seems I don't need the -CHIP.
For some reason, I get an error message: "Unsupported baud rate. Use tcsetattr failed".
But, it works anyway.
Seems I do need the "-l baud" though.
Otherwise, it hangs like the PC version does under Wine with large files...
Gives me an extra "tcsetattr failed" message.
The binary on David Zemon's site was built on January 28, which is the day before I made the default loader rate 921600 for the Mac. This means that without specifying the -l option you were loading at 2000000. That might explain the flakiness.
@"Dave Hein" , one simple question I have is: does the serial console rate (-b option) need to be set to 115200 (or left at its default) for the interactive test programs to work properly at the default clock speed when no special P2 clock parameters are given? If so that could probably explain at least some of what I am seeing. I was seeing data character corruption when this rate is halved or doubled etc, which looked somewhat like the wrong baud rate, though I really need to measure it on the logic analyzer / scope to see what it is really sending into the PC.
E.g.
With loadstr="loadp2 -l 2000000 -b 115200 -CHIP"
RLs-MacBook-Pro:p2gcc roger$ p2gcc hello.c -r -t -p /dev/cu.usbserial-P23HPBP6
ioctl succeeded
Setting baudrate to 115200
( Entering terminal mode. Press Ctrl-] to exit. )
Hello World - 1
Hello World - 2
Hello World - 3
Hello World - 4
Hello World - 5
Hello World - 6
Hello World - 7
Really? You got 2000000 working on the Mac? I wasn't able to use anything higher than 921600. I think the Mac just passes the numeric baud rate to the driver and accepts whatever the driver accepts. Maybe I have an older FTDI driver installed on my machine.
Really? You got 2000000 working on the Mac? I wasn't able to use anything higher than 921600. I think the Mac just passes the numeric baud rate to the driver and accepts whatever the driver accepts. Maybe I have an older FTDI driver installed on my machine.
Yes really. I just needed to mod the osint_linux.c file that opens serial ports and sets baud rates using an IOCTL call for the higher baud rates, it's attached above. Still playing with it to see how stable it is.
@"Dave Hein" , one simple question I have is: does the serial console rate (-b option) need to be set to 115200 (or left at its default) for the interactive test programs to work properly at the default clock speed when no special P2 clock parameters are given? If so that could probably explain at least some of what I am seeing. I was seeing data character corruption when this rate is halved or doubled etc, which looked somewhat like the wrong baud rate, though I really need to measure it on the logic analyzer / scope to see what it is really sending into the PC.
The serial drivers in the p2gcc C library normally run at 115200. With loadp2 it is possible to change the clock frequency and baud rate by using the -PATCH option. -PATCH will cause loadp2 to copy the frequency and baud rate parameters at location starting at $400.
I'm currently in the process of changing the system parm location from $400 to $14 so that it will be consistent with spin2gui. Once I do that I will make -PATCH the default mode, and add a -nopatch option to disable it.
Really? You got 2000000 working on the Mac? I wasn't able to use anything higher than 921600. I think the Mac just passes the numeric baud rate to the driver and accepts whatever the driver accepts. Maybe I have an older FTDI driver installed on my machine.
Yes really. I just needed to mod the osint_linux.c file that opens serial ports and sets baud rates using an IOCTL call for the higher baud rates, it's attached above. Still playing with it to see how stable it is.
Really? You got 2000000 working on the Mac? I wasn't able to use anything higher than 921600. I think the Mac just passes the numeric baud rate to the driver and accepts whatever the driver accepts. Maybe I have an older FTDI driver installed on my machine.
Yes really. I just needed to mod the osint_linux.c file that opens serial ports and sets baud rates using an IOCTL call for the higher baud rates, it's attached above. Still playing with it to see how stable it is.
I looked at your code and your early return if the ioctl succeeds skips over the following code. Will that cause any problems?
/* set the options */
chk("tcflush", tcflush(hSerial, TCIFLUSH));
chk("tcsetattr", tcsetattr(hSerial, TCSANOW, &sparm));
spin2gui question.
What is the baud rate for the serial terminal. I suddenly have problems seeing the terminal.
You should ask that question on the fastspin thread. That combination of clock frequency and baud rate works fine on p2gcc. Maybe it's a limitation of the object your using. Are you using a Mac? There are issues with running loadp2 at 2000000 on a Mac.
[
I looked at your code and your early return if the ioctl succeeds skips over the following code. Will that cause any problems?
/* set the options */
chk("tcflush", tcflush(hSerial, TCIFLUSH));
chk("tcsetattr", tcsetattr(hSerial, TCSANOW, &sparm));
My stuff is experimental so right now it's just a hack. I am still playing around to see if there are problems. I've seen some strange things during interactive P2 app startup, but lately it seems more stable. So I am wondering if the flushes are happening at the right time/place etc during baud rate changes if the app has started outputting to the terminal like reading some partially buffered data at the wrong baud rate etc. I need to study the entire sequence further when I have more time.
Another recent change I put in does the IOCTL and that flush then returns immediately without touching tcsetattr and tcgetattr etc. I found that last extra tcsetattr() caused an error (which is ignored) when you try to write back the just read terminal settings (from tcgetattr()) over the top of whatever the IOCTL did even if I skip setting the higher baud rate with cfsetspeed(). Not sure why. To remedy I just use this simpler form now..
case 9600:
tbaud = B9600;
break;
default:
#ifdef MACOSX
speed = baud;
if (ioctl(hSerial, IOSSIOSPEED, &speed) == 0) // if IOCTL succeeds continue
{
chk("tcflush", tcflush(hSerial, TCIFLUSH));
return 1;
}
#endif
printf("Unsupported baudrate %lu. Use ", baud);
tbaud = baud;
The serial drivers in the p2gcc C library normally run at 115200. With loadp2 it is possible to change the clock frequency and baud rate by using the -PATCH option. -PATCH will cause loadp2 to copy the frequency and baud rate parameters at location starting at $400.
I'm currently in the process of changing the system parm location from $400 to $14 so that it will be consistent with spin2gui. Once I do that I will make -PATCH the default mode, and add a -nopatch option to disable it.
Using windows 7. All was working but all of sudden issues. Ran a program that simply printed then I got gobbydegook as if the baud rate was wrong. Pnut no problem.
I've attached a zipfile with the latest p2gcc source and Windows binaries. The following changes have been made since the last update.
- Many bug fixes
- Added 32-bit floating point support
- Added the ability to start new C cogs using cogstart
- Added the ability to change the clock frequency and maintain a constant baud rate
The current version numbers for each utility are:
0.005 p2gcc
0.012 loadp2
0.008 p2asm
0.003 p2dump
0.003 p2dumpobj
0.005 p2link
0.006 s2pasm
Comments
No problem Dave... firstly the latest version of loadp2 seems to be 0.011.
RLs-MacBook-Pro:p2gcc roger$ loadp2 loadp2 - a loader for the propeller 2 - version 0.011, 2019-01-29 usage: loadp2 [ -p port ] serial port [ -b baud ] user baud rate (default is 115200) [ -l baud ] loader baud rate (default is 921600) [ -f clkfreq ] clock frequency (default is 80000000) [ -m clkmode ] clock mode in hex (default is ffffffff) [ -s address ] starting address in hex (default is 0) [ -t ] enter terminal mode after running the program [ -T ] enter PST-compatible terminal mode [ -v ] enable verbose mode [ -k ] wait for user input before exit [ -? ] display a usage message and exit [ -CHIP ] set load mode for CHIP [ -FPGA ] set load mode for FPGA [ -SINGLE ] set load mode for single stage [ -PATCH ] patch in clock frequency and serial parms file file to loadHere's the output for the remaining commands... I assume it is meant to auto-detect the P2, but it doesn't work unless I manually specify the USB port it uses.
When I specify the USB port I get these errors... it doesn't like the default higher baud rate.
When I both override the baud rate to 115200 AND specify the USB port I get this output... and all three variants downloaded the application to the P2 board and ran it.
Hope this helps!
Cheers,
Roger.
Thanks.
Will try that soon, but right now have been hacking with your osint_linux.c file and managed to get a 2000000 baud download working on the MAC and it works with Ahle's SIDCOG code. For higher baud rates above 230400 you need to bypass the cfsetspeed call and do IOCTL directly instead according to some online information I found. The basic problem is that MACOS X has not defined any higher speeds than 230400 bps in its termios.h file (in OS X 10.10.5 anyway), so regular terminal control API code won't let the higher baud rates work, but it will change the baud rate if you do the IOCTL. Limitation is that the termio stuff then gets out of sync and won't report the raw driver baud rate correctly.
Here's some snippets of what I am trying...
.... #include <limits.h> #include <signal.h> #ifdef MACOSX #include <IOKit/serial/ioss.h> #endif #include "osint.h" .... int serial_baud(unsigned long baud) { struct termios sparm; int tbaud = 0; #ifdef MACOSX speed_t speed = 0; #endif static unsigned long last_baud = -1; .... case 19200: tbaud = B19200; break; case 9600: tbaud = B9600; break; default: #ifdef MACOSX speed = baud; tbaud = baud; if (ioctl(hSerial, IOSSIOSPEED, &speed) == 0) // if IOCTL succeeds continue break; #endif printf("Unsupported baudrate %lu. Use ", baud); #ifdef B921600 printf("921600, "); #endif .... /* get the current options */ chk("tcgetattr", tcgetattr(hSerial, &sparm)); /* set raw input */ #ifdef MACOSX printf("speed = %d\n", (int)speed); if (speed == 0) // only if baud was not directly set using IOCTL chk("cfsetspeed", cfsetspeed(&sparm, tbaud)); #else chk("cfsetispeed", cfsetispeed(&sparm, tbaud)); chk("cfsetospeed", cfsetospeed(&sparm, tbaud)); #endifI still get some warnings printed for accessing tcsetattr which I'm trying to clean up... not sure why if I skip that cfsetspeed ... ?
UPDATE: I was only testing the download with a non-interactive program. Since then I have found that actual serial data being printed in programs using stdio get messed up if the baud rate is not set to -b 115200. Still investigating that to see if it relates to my own changes...
He uses an old machine sitting in @dgately's house running a second TeamCity slave
It would be nice to get the auto P2 port detection working. That seems to be broken on the Mac platform.
Well, there might be some issue. Loading up the VGA_640_x_480_8bpp example, the bottom six or so lines of the image is messed up. Like it didn't fully load...
I tried it again, this time without the "-t" and it worked. But, that isn't really proof of anything...
For some reason, I get an error message: "Unsupported baud rate. Use tcsetattr failed".
But, it works anyway.
Seems I do need the "-l baud" though.
Otherwise, it hangs like the PC version does under Wine with large files...
Gives me an extra "tcsetattr failed" message.
Nice thing about this way is that if I forget the -l baud part, I can terminate the window and recover the serial port without having to reboot...
I'll just ignore that "Unsupported baud rate. Use tcsetattr failed." message.
E.g.
With loadstr="loadp2 -l 2000000 -b 115200 -CHIP"
With loadstr="loadp2 -l 2000000 -b 57600 -CHIP"
I'm currently in the process of changing the system parm location from $400 to $14 so that it will be consistent with spin2gui. Once I do that I will make -PATCH the default mode, and add a -nopatch option to disable it.
Ugh. So ioctl works but cfsetspeed doesn't?
What is the baud rate for the serial terminal. I suddenly have problems seeing the terminal.
/* set the options */ chk("tcflush", tcflush(hSerial, TCIFLUSH)); chk("tcsetattr", tcsetattr(hSerial, TCSANOW, &sparm));Yes, for any baud rates higher than 230400.
My stuff is experimental so right now it's just a hack. I am still playing around to see if there are problems. I've seen some strange things during interactive P2 app startup, but lately it seems more stable. So I am wondering if the flushes are happening at the right time/place etc during baud rate changes if the app has started outputting to the terminal like reading some partially buffered data at the wrong baud rate etc. I need to study the entire sequence further when I have more time.
Another recent change I put in does the IOCTL and that flush then returns immediately without touching tcsetattr and tcgetattr etc. I found that last extra tcsetattr() caused an error (which is ignored) when you try to write back the just read terminal settings (from tcgetattr()) over the top of whatever the IOCTL did even if I skip setting the higher baud rate with cfsetspeed(). Not sure why. To remedy I just use this simpler form now..
case 9600: tbaud = B9600; break; default: #ifdef MACOSX speed = baud; if (ioctl(hSerial, IOSSIOSPEED, &speed) == 0) // if IOCTL succeeds continue { chk("tcflush", tcflush(hSerial, TCIFLUSH)); return 1; } #endif printf("Unsupported baudrate %lu. Use ", baud); tbaud = baud;Thanks for this information Dave.
The terminal speed changed from 200000 to 230400
Mike
- Many bug fixes
- Added 32-bit floating point support
- Added the ability to start new C cogs using cogstart
- Added the ability to change the clock frequency and maintain a constant baud rate
The current version numbers for each utility are:
0.005 p2gcc
0.012 loadp2
0.008 p2asm
0.003 p2dump
0.003 p2dumpobj
0.005 p2link
0.006 s2pasm