There was a missing compatibility define in <propeller.h> (we changed some things in propeller2.h, which had knock-on effects in the compatibility code). It should be fixed now in the current github.
There was a missing compatibility define in <propeller.h> (we changed some things in propeller2.h, which had knock-on effects in the compatibility code). It should be fixed now in the current github.
Now I get this:
/Users/dbetz/work/ebasic3/fastspin_stuff.c(15) error: unknown identifier _waitcnt used in function call
I added a #define _PROP1_COMPATIBLE to this file before including propeller.h.
There was a missing compatibility define in <propeller.h> (we changed some things in propeller2.h, which had knock-on effects in the compatibility code). It should be fixed now in the current github.
Now I get this:
/Users/dbetz/work/ebasic3/fastspin_stuff.c(15) error: unknown identifier _waitcnt used in function call
I added a #define _PROP1_COMPATIBLE to this file before including propeller.h.
I don't see that. Maybe try without the _PROP1_COMPATIBLE? Or you could just change the definition of sleep to:
There was a missing compatibility define in <propeller.h> (we changed some things in propeller2.h, which had knock-on effects in the compatibility code). It should be fixed now in the current github.
Now I get this:
/Users/dbetz/work/ebasic3/fastspin_stuff.c(15) error: unknown identifier _waitcnt used in function call
I added a #define _PROP1_COMPATIBLE to this file before including propeller.h.
I don't see that. Maybe try without the _PROP1_COMPATIBLE? Or you could just change the definition of sleep to:
void sleep(int secs) { _waitx(clockfreq*secs); }
using the new _waitx macro.
Okay, I'll make that change. I didn't commit the code that had the #define _PROP1_COMPATIBLE line in it. That's why you didn't see it. In any case, I should be moving away from using P1 stuff so I'll take your suggestion.
I actually had to change the definition of sleep to this because clockfreq also came out undefined but now it builds minus some warnings that I need to fix in my own code. I'll try to see if it runs tonight. Thanks for your help!
Okay, I'll make that change. I didn't commit the code that had the #define _PROP1_COMPATIBLE line in it. That's why you didn't see it. In any case, I should be moving away from using P1 stuff so I'll take your suggestion.
I just realized the error was probably because you had to rebuild fastspin (which has the _waitcnt definition baked in). The change I made wasn't just to the header file, I also added _waitcnt (which is mandated by propeller2.h but had been missing).
Okay, I'll make that change. I didn't commit the code that had the #define _PROP1_COMPATIBLE line in it. That's why you didn't see it. In any case, I should be moving away from using P1 stuff so I'll take your suggestion.
I just realized the error was probably because you had to rebuild fastspin (which has the _waitcnt definition baked in). The change I made wasn't just to the header file, I also added _waitcnt (which is mandated by propeller2.h but had been missing).
That might be. At first I just installed the new include directory. On a later attempt I updated fastspin as well. In any case, I have it working now and have pushed my changes to GitHub. Thanks for your help!
Has anyone had any luck compiling fastspin C programs and running them on a Mac? I did this quite a while ago but I can't get it working anymore. I can build the program but loadp2 won't load and run it. I have issues with loadp2 finding the P2 port and also with complaints about the default baud rates.
eric,
Noticed a bug in fastspin listing. If at the end of the file there is a label but no code, the listing ends without displaying those additional lines. I guess a comment such as the MIT license would also not be included in the listing.
"not an ELF file" is just informational. The file is then treated as a pure propeller binary image.
Try adding the -v option. It might reveal something.
I use -SINGLE option but I think it's the default anyway.
I wondered about whether that might just be informational. I see one of the LEDs flashing so maybe the download is actually happening but the program isn't running correctly.
Can someone post a simple C program that is known to work on the P2-Eval board? I tried a simple "Hello, world" program and that didn't display anything either. Should printf print to the serial port? Is 115200 the correct baud rate?
Well, I realized what one of my problems was. I was using /dev/tty.usbserial-P2EEQXU instead of /dev/cu.usbserial-P2EEQXU. That seems to have made the download succeed but I get garbage characters printed. What is the default serial baud rate for fastspin programs? I tried 115200 and 230400 and neither seemed to work.
Edit: Never mind. If I use both "-b 230400" and "-l 230400" everything seems to work with both my test program and ebasic3. Now I just have to figure out how to get loadp2 to use higher baud rates on the Mac.
"not an ELF file" is just informational. The file is then treated as a pure propeller binary image.
Whoops, yes, that's some debug code that I forgot to take out. Sorry about that, it's fixed in github now.
David, as you've figured out the default baud rate for P2 is 230400 and default clock speed is 160000000. Those default settings are still relatively new, it used to be that you had to explicitly set the clock for P2, and it's possible there are some edge cases where the explicit setting is still required.
If you can find out how to set higher clock speeds on the Mac I'd be delighted to put that into my version of loadp2.
eric,
Noticed a bug in fastspin listing. If at the end of the file there is a label but no code, the listing ends without displaying those additional lines. I guess a comment such as the MIT license would also not be included in the listing.
add x, #1 '10
ret
hub_test_end
'
Hmmm, interesting. Thanks for the bug report, I'll look into it.
I'm trying to extract debug data from fastspin .lst files and hit a problem.
In some situations the label is shown in the wrong address.
Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.
We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?
If you can find out how to set higher clock speeds on the Mac I'd be delighted to put that into my version of loadp2.
I assume you mean higher baud rates. I'll try to figure this out. Proploader certainly is able to use higher baud rates so I'll check to see how the code differs.
I'm trying to extract debug data from fastspin .lst files and hit a problem.
In some situations the label is shown in the wrong address.
Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.
We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?
Are you thinking like an xref listing?
An xref lists at the end of the standard asm list, each label in alpha order with the address and line number where declared, followed by the line numbers where the label is referenced.
It was very important way back when editors were quite primitive. These days, with fast computers and excellent searches, listings aren’t used anywhere near as often.
I'm trying to extract debug data from fastspin .lst files and hit a problem.
In some situations the label is shown in the wrong address.
Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.
We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?
Are you thinking like an xref listing?
An xref lists at the end of the standard asm list, each label in alpha order with the address and line number where declared, followed by the line numbers where the label is referenced.
No, I was thinking more of just a list of labels and their hub and COG addresses, in some form that would be easier to parse than a .lst file, something like:
I'm trying to extract debug data from fastspin .lst files and hit a problem.
In some situations the label is shown in the wrong address.
Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.
We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?
Are you thinking like an xref listing?
An xref lists at the end of the standard asm list, each label in alpha order with the address and line number where declared, followed by the line numbers where the label is referenced.
No, I was thinking more of just a list of labels and their hub and COG addresses, in some form that would be easier to parse than a .lst file, something like:
"not an ELF file" is just informational. The file is then treated as a pure propeller binary image.
Try adding the -v option. It might reveal something.
I use -SINGLE option but I think it's the default anyway.
I wondered about whether that might just be informational. I see one of the LEDs flashing so maybe the download is actually happening but the program isn't running correctly.
If it is informational, it should be a 'note', or smarter would be to say what file type it was actually using (/assuming), rather than what it is not....
Well, I realized what one of my problems was. I was using /dev/tty.usbserial-P2EEQXU instead of /dev/cu.usbserial-P2EEQXU. That seems to have made the download succeed but I get garbage characters printed. What is the default serial baud rate for fastspin programs? I tried 115200 and 230400 and neither seemed to work.
Edit: Never mind. If I use both "-b 230400" and "-l 230400" everything seems to work with both my test program and ebasic3. Now I just have to figure out how to get loadp2 to use higher baud rates on the Mac.
Can you post the command line that finally worked ok ?
I'm trying to extract debug data from fastspin .lst files and hit a problem.
In some situations the label is shown in the wrong address.
Hmmm, that's an interesting problem. I guess it's because I'm displaying the source code at the end of the hex output instead of the beginning of it. I'm not sure if I can switch that around or not, but I'll look into it.
We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?
Do you mean a separate debug file from the MAP file ?
I'm used to seeing 3+ files generated in other MCus
- The listing file : better tools include the source lines interspersed with the generated ASM lines
- The MAP file : Shows ALL vars, their memory segments, address, and name. Better tools here preserve case, and include a VAR Type tag, for watch.
This is column aligned, and can be large but modern editors do not really care.
- The debug file : can be binary, or ASCII. SDCC has quite a good ascii format debug file, that includes type tags. Better debug tools offer an endian choice.
- The HEX or BIN code file. Nothing but bytes.
In SiLabs Debug case, they read the OMF file, and download the binary info interspersed in there, and extract the Name.Type info for WATCH use.
I'm in two minds about that - I can see using one file is easier to specify & avoids creep, and it seems to work fine, but a minus is the file you send is not the HEX file you might use in production.
(I've never seen a difference, so maybe I worry too much )
If you can find out how to set higher clock speeds on the Mac I'd be delighted to put that into my version of loadp2.
I presume you mean Baud settings ?
DB: If I use both "-b 230400" and "-l 230400" everything seems to work
On that topic, I hope loadp2 has no issues with this "-b 3" and "-l 3" ?
To avoid driver issues, on the UB3 bridge, I've done a dual-baud plane design. Numbers under 366 are used as a 24MHz/N specifier, to allow any fast HW baud, that avoids driver-imposed ceilings.
Comments
I don't see that. Maybe try without the _PROP1_COMPATIBLE? Or you could just change the definition of sleep to:
void sleep(int secs) { _waitx(clockfreq*secs); }using the new _waitx macro.void sleep(int secs) { _waitx(_clockfreq() * secs); }I just realized the error was probably because you had to rebuild fastspin (which has the _waitcnt definition baked in). The change I made wasn't just to the header file, I also added _waitcnt (which is mandated by propeller2.h but had been missing).
Try adding the -v option. It might reveal something.
I use -SINGLE option but I think it's the default anyway.
Noticed a bug in fastspin listing. If at the end of the file there is a label but no code, the listing ends without displaying those additional lines. I guess a comment such as the MIT license would also not be included in the listing.
add x, #1 '10 ret hub_test_end 'I'm trying to extract debug data from fastspin .lst files and hit a problem.
In some situations the label is shown in the wrong address.
e.g. In the above example "copyx" should be on the previous line, the AUGS line.
The issue also appears in relation to "file" directives. Here the label "debug" is at the end of the data not the beginning.
This is the program that I tried:
#include <stdio.h> void main(void) { printf("Hello, world!\n"); for (;;) ; }I built and ran it like this:BTW Love the fact that it leaves the terminal up after the compile/download/run
#include <stdio.h> #include <propeller.h> void sleep(int secs) { _waitx(_clockfreq() * secs); } void main(void) { sleep(1); printf("Hello, world!\n"); for (;;) ; }Edit: Never mind. If I use both "-b 230400" and "-l 230400" everything seems to work with both my test program and ebasic3. Now I just have to figure out how to get loadp2 to use higher baud rates on the Mac.
David, as you've figured out the default baud rate for P2 is 230400 and default clock speed is 160000000. Those default settings are still relatively new, it used to be that you had to explicitly set the clock for P2, and it's possible there are some edge cases where the explicit setting is still required.
If you can find out how to set higher clock speeds on the Mac I'd be delighted to put that into my version of loadp2.
Hmmm, interesting. Thanks for the bug report, I'll look into it.
We could also provide a switch to explicitly dump labels (and any other debug information we can think of) into a file for the debugger. What format would be convenient for that?
An xref lists at the end of the standard asm list, each label in alpha order with the address and line number where declared, followed by the line numbers where the label is referenced.
It was very important way back when editors were quite primitive. These days, with fast computers and excellent searches, listings aren’t used anywhere near as often.
No, I was thinking more of just a list of labels and their hub and COG addresses, in some form that would be easier to parse than a .lst file, something like:
That would be easier although we can search the listing.
In the good (or bad) old days we only had the option to print to the line printer, or surpress the listing. No spooling.
I would expect any download program to say how many bytes it had downloaded, as a useful report back to the user.
Can you post the command line that finally worked ok ?
Do you mean a separate debug file from the MAP file ?
I'm used to seeing 3+ files generated in other MCus
- The listing file : better tools include the source lines interspersed with the generated ASM lines
- The MAP file : Shows ALL vars, their memory segments, address, and name. Better tools here preserve case, and include a VAR Type tag, for watch.
This is column aligned, and can be large but modern editors do not really care.
- The debug file : can be binary, or ASCII. SDCC has quite a good ascii format debug file, that includes type tags. Better debug tools offer an endian choice.
- The HEX or BIN code file. Nothing but bytes.
In SiLabs Debug case, they read the OMF file, and download the binary info interspersed in there, and extract the Name.Type info for WATCH use.
I'm in two minds about that - I can see using one file is easier to specify & avoids creep, and it seems to work fine, but a minus is the file you send is not the HEX file you might use in production.
(I've never seen a difference, so maybe I worry too much
I presume you mean Baud settings ?
DB: If I use both "-b 230400" and "-l 230400" everything seems to work
On that topic, I hope loadp2 has no issues with this "-b 3" and "-l 3" ?
To avoid driver issues, on the UB3 bridge, I've done a dual-baud plane design. Numbers under 366 are used as a 24MHz/N specifier, to allow any fast HW baud, that avoids driver-imposed ceilings.