p2asm looks very promising, and combined with loadp2 it should make compiler work much easier. It's definitely much faster to be able to automate things in a script and/or run from a command line then to have to open PNut and recompile and redownload after every change. Thanks for working on these!
(A Linux version of loadp2 would really be gravy, but if nobody else tackles it I could take a look at porting it from Cygwin.)
Thanks,
Eric
I just downloaded the zip file and typed "cc -o p2asm *.c -lm" and it built fine with four warnings.
I see the problem with some of the warnings. The code casts pointers to ints but under 64 bit Linux it seems int is 4 bytes and int* is 8 bytes.
p2asm looks very promising, and combined with loadp2 it should make compiler work much easier. It's definitely much faster to be able to automate things in a script and/or run from a command line then to have to open PNut and recompile and redownload after every change. Thanks for working on these!
(A Linux version of loadp2 would really be gravy, but if nobody else tackles it I could take a look at porting it from Cygwin.)
Thanks,
Eric
I just downloaded the zip file and typed "cc -o p2asm *.c -lm" and it built fine with four warnings.
I see the problem with some of the warnings. The code casts pointers to ints but under 64 bit Linux it seems int is 4 bytes and int* is 8 bytes.
There are a few other issues that stdarg.h can probably take care of. I'll update the sources and upload them in a few minutes.
Here is a version of p2asm that will compile on the Mac or Linux using the following command:
cc -Wall -o p2asm *.c -lm
I ended up changing the logic a bit in the function ReadString in strstubs.c. The fgets function returns a pointer to the output buffer not the character count at least with most C libraries. I'm surprised this is different with Cygwin.
P2 loader looks very simple compared to P1... was just looking at P1 loader and it's way, way over complicated ...
But I guess there is some magic in the p2 loader string...
I think that was the idea. The ASCII loader protocol makes things a lot simpler. However they are probably slower too. That's why the first step is to load a second-stage loader that runs off the crystal and loads at a much higher baud rate.
I think that was the idea. The ASCII loader protocol makes things a lot simpler. However they are probably slower too. That's why the first step is to load a second-stage loader that runs off the crystal and loads at a much higher baud rate.
I'm not sure they are 'slower' on P2 ?
The 64b encode is much faster than the older P1 design, and I think Chip has made the RC Osc 20MHz Min spec, which meant he was able to get close to 2Mbd, without having to work-backwards from some crystal value.
I think that was the idea. The ASCII loader protocol makes things a lot simpler. However they are probably slower too. That's why the first step is to load a second-stage loader that runs off the crystal and loads at a much higher baud rate.
I'm not sure they are 'slower' on P2 ?
The 64b encode is much faster than the older P1 design, and I think Chip has made the RC Osc 20MHz Min spec, which meant he was able to get close to 2Mbd, without having to work-backwards from some crystal value.
That may well be true. However, loading a full 512K of hub memory will be much faster using the higher baud rates achievable by using the crystal.
@jmg, it's easier for now to stick with 115200, but I'll probably change it later on. It would require setting the baud rate 3 times to do it. The initial baud rate should probably be around 100,000 to load MainLoader. We'll get bit errors if it is too high. The secondary loader could run at 2M like Chip said. And then a third baud rate setting would need to be done to match the user's desired rate.
@ersmith, I've been working on the Linux version of loadp2 for a few hours, and I got the loader portion working. I'm still trying to get the terminal emulator to work. I've tried using the routines that work under Cygwin to disable buffering, echoing and waiting on stdin, but it doesn't work under Linux for some reason. I just realized that the console I/O code I use in spinsim works on Linux, so I'll give that code a try.
@David, I don't get any warnings when I compile the 002 code under Linux or Cygwin. Are you compiling on a Mac? Can you post the 4 warnings that you get? BTW, I looked at the p2load source code, and it's very impressive. It would be great if you could get that working with the latest version of the FPGA. However, I understand why you might want to wait until the chip design if finalized.
@David, I don't get any warnings when I compile the 002 code under Linux or Cygwin. Are you compiling on a Mac? Can you post the 4 warnings that you get? BTW, I looked at the p2load source code, and it's very impressive. It would be great if you could get that working with the latest version of the FPGA. However, I understand why you might want to wait until the chip design if finalized.
I compiled under both the Mac and Ubuntu 16.04. Ubuntu generated more warnings but the Mac generated some as well. The sources I posted fix all of the warnings and also fix what I believe is a bug in a call to fgets.
I'm not waiting for the P2 silicon. I'm waiting for my schedule to free up! I was dumb enough to accept three contract programming jobs at the same time and I haven't had much spare time lately. Maybe I should rethink whether it is time to retire and spend all of my newfound free time working on Propeller tools! :-)
@jmg, it's easier for now to stick with 115200, but I'll probably change it later on. It would require setting the baud rate 3 times to do it. The initial baud rate should probably be around 100,000 to load MainLoader. We'll get bit errors if it is too high. The secondary loader could run at 2M like Chip said. And then a third baud rate setting would need to be done to match the user's desired rate.
Chip's P2 DOCs say this, you seem to be thinking of he P1 loader ?
P2 Autobauds, and uses the fractional baud ability, & 64b encode, to run a much faster stage 1 loader than P1 managed.
To support this, you just need to make the baud rate a user parameter ?
"SERIAL LOADING PROTOCOL
The built-in serial loader allows Propeller 2 chips to be loaded via 8-N-1 asynchronous serial into P63, where START=low and STOP=high, at any rate the sender uses, between 1,200 baud and 2M baud. The loader automatically adapts to the sender’s baud rate from every “>” character ($3E) it receives. It is necessary to initially send “> “ ($3E, $20) before the first command, and then use “>” characters periodically throughout your data to keep the baud rate tightly calibrated to the internal RC oscillator that the loader uses during boot ROM execution. Received “>” characters are not passed to the command parser, so they can be placed anywhere."
A stage 2 loader should be able to go even faster, of course.
@David, thanks for posting the fixed source code. I'll incorporate your changes into my code. BTW, I posted my previous message without reading all of your comments. I basically read to the end of page 1 of this thread, and entirely missed the messages that were on page 2.
@jmg, I might be able to run at a higher rate, but even at 115200 I had to insert several ">" characters just to load a few dozen bytes. I'm not sure how Chip implemented the RC clock in the FPGA. I'm wondering how stable it is. Of course, Chip's the expert on this, so if he says that the boot loader works at 2Mbaud, then I'm sure it does.
I got a little further on the Linux version of loadp2. It looks like the console I/O was OK all along, and the problem is with the serial rx() function. For some reason it is blocking waiting for data to come in on the serial port. Hopefully I can figure out what the problem is in the morning.
@jmg, I might be able to run at a higher rate, but even at 115200 I had to insert several ">" characters just to load a few dozen bytes. I'm not sure how Chip implemented the RC clock in the FPGA. I'm wondering how stable it is. Of course, Chip's the expert on this, so if he says that the boot loader works at 2Mbaud, then I'm sure it does.
I've been loading 600k+ Prop_txt files @ 2M on the P123-A9 board Ok.
I can even send the file with no extra ">" characters.
I'll try it on some other FPGA boards and see if they differ.
Here is a version of p2asm that will compile on the Mac or Linux using the following command:
cc -Wall -o p2asm *.c -lm
I ended up changing the logic a bit in the function ReadString in strstubs.c. The fgets function returns a pointer to the output buffer not the character count at least with most C libraries. I'm surprised this is different with Cygwin.
on macOS (Sierra) there is still 1 warning:
$ cc -Wall -o p2asm *.c -lm
p2asm.c:1111:78: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
if ((srcval&3) == 0 && srcval < (255 << 2) && srcval > (-256 << 2) && !is_loc)
~~~~ ^
1 warning generated.
@jmg, I might be able to run at a higher rate, but even at 115200 I had to insert several ">" characters just to load a few dozen bytes. I'm not sure how Chip implemented the RC clock in the FPGA. I'm wondering how stable it is. Of course, Chip's the expert on this, so if he says that the boot loader works at 2Mbaud, then I'm sure it does.
It's a while ago now, but I think Chip moved the RC Osc design to be 20MHz Min, to give enough SysCLKs to allow ~ 2MBd target speeds.
I've been loading 600k+ Prop_txt files @ 2M on the P123-A9 board Ok.
I can even send the file with no extra ">" characters.
I'll try it on some other FPGA boards and see if they differ.
Hmm, some variance there ? The latter is more expected.
I'd expect the FPGA to have a crystal derived 'virtual RC clock', and so be better in drift performance than any actual RC osc device.
(ie a single ">" may be ok on FPGA, but it might be a good idea to sprinkle sparse ">" in any loader, ready for the RC Osc)
I can confirm that ALL FPGA boards load successfully @ 2Mbaud using the txt loader.
Good to hear.
The 2MBd may be optimistic for a RC osc, which is why I suggest a user baud parameter, to allow easy experiment.
Most USB-UARTS have a virtual baud clock of either
12MHz which allows 2Mbd,1.714Mbd, 1.5Mbd,1.333MBd etc
or
24MHz, which allows 2MBd, 1.846MBd,1.714Mbd, 1.6MBd, 1.5Mbd,1.412MBd ,1.333MBd etc
As the baud drops the granularity error of AutoBaud extract, and Baud-Set improve.
Do your FPGAs also load at 1.714Mbd, 1.5Mbd, 1.333MBd ?
Do your FPGAs also load at 1.714Mbd, 1.5Mbd, 1.333MBd ?
Yes on DE2-115,P123-A9. Didn't try others.
Thanks, seems to confirm the Autobaud range.
Does anyone know if the Boot-Load time SysCLK is always 80MHz (ie unchanged) or dropped to 20MHz in the FPGAs (to better emulate real parts) ?
A 80MHz syslk may give an optimistic ability indication.
I see the problem with some of the warnings. The code casts pointers to ints but under 64 bit Linux it seems int is 4 bytes and int* is 8 bytes.
On Linux (and really every platform out there except Windows, for some insane reason) pointers should not be cast to int, they should be cast to long. On said platforms 'long' is always the size of a pointer. And 'int' is 32 bits and won't hold a pointer on 64-bit platforms.
I see the problem with some of the warnings. The code casts pointers to ints but under 64 bit Linux it seems int is 4 bytes and int* is 8 bytes.
On Linux (and really every platform out there except Windows, for some insane reason) pointers should not be cast to int, they should be cast to long. On said platforms 'long' is always the size of a pointer. And 'int' is 32 bits and won't hold a pointer on 64-bit platforms.
C99 provides 'intptr_t' as 'the integer that's the same size as a pointer' in <stdint.h>.
Here is a version of p2asm that will compile on the Mac or Linux using the following command:
cc -Wall -o p2asm *.c -lm
I ended up changing the logic a bit in the function ReadString in strstubs.c. The fgets function returns a pointer to the output buffer not the character count at least with most C libraries. I'm surprised this is different with Cygwin.
on macOS (Sierra) there is still 1 warning:
$ cc -Wall -o p2asm *.c -lm
p2asm.c:1111:78: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
if ((srcval&3) == 0 && srcval < (255 << 2) && srcval > (-256 << 2) && !is_loc)
~~~~ ^
1 warning generated.
dgately
You know, I saw that warning too the first time I compiled the sources but I don't seem to see it now. In any case, it doesn't seem like it will hurt anything.
I see the problem with some of the warnings. The code casts pointers to ints but under 64 bit Linux it seems int is 4 bytes and int* is 8 bytes.
On Linux (and really every platform out there except Windows, for some insane reason) pointers should not be cast to int, they should be cast to long. On said platforms 'long' is always the size of a pointer. And 'int' is 32 bits and won't hold a pointer on 64-bit platforms.
C99 provides 'intptr_t' as 'the integer that's the same size as a pointer' in <stdint.h>.
Eric
It turns out that those casts of pointers to ints were not really needed so I just removed them. They were used to subtract two char* pointers which works fine without any casts.
C99 provides 'intptr_t' as 'the integer that's the same size as a pointer' in <stdint.h>.
Yep, but intptr_t is extremely rare in the wild, still. On the other hand using the 'ILP32' model on 32-bit systems and 'LP64' model on 64-bit systems is much older, and still holds. Also with C89. char 8 bits, short 16 bits, int 32 bits, long 32 bits on 32-bit systems, 64 bits on 64-bits systems, and pointer 32 bits on 32-bit systems, 64 bits on 64-bit systems. So a pointer will always fit in a long, but a pointer only fits in an int on 32-bit systems.
Windows breaks this of course, just to be different.
Thanks for all the suggestions. I'll clean up the code to eliminate the warnings. The one about (-256 << 2) is surprising. I'll replace it with (-256 * 42). I'm basically testing to see if the value is within the range of -256 to 255 with an offset of 2 bits to determine whether the long version of CALLD is needed. I added this test to match the binary output from PNut. Previously the long version was always used if the destination register was in the rant of $1f6 to $1f9.
I'll do some more testing with Prop_Hex and Prop_Ascii to see if I can figure out why it's not reliable for me. I suspect there may have been other issues when I was developing the code, and I stopped looking at it once I got something that worked using the secondary loader. I believe at some point I was able to load a large binary using Prop_Hex.
The 64-bit pointer thing always gets me. I currently don't have a machine that uses 64-bit pointers, so I never see those warnings. To me it seems like 64 bits is somewhat wasteful. It's rare that someone really needs more than 32 bits. Just thinking of all those 32 most significant bits that are identical, and never changing makes me wonder why we waste the sand to create the extra silicon that is unused.
.. but on 64-bit systems the pointer *must* be 64 bits. Just as on a 16-bit CPU the pointer must be 16 bits. But yes, it takes more space. Which is why SGI introduced the n32 ABI model, with 64-bit registers and 64-bit instructions, but addresses (pointers) were restricted to 32 bits (and thus could address only 4GB). In any case, if you use 'long' if you for some reason need to hold a pointer outside of a pointer, you'll be portable. And space efficient too, on 32-bit architectures.
Thanks for all the suggestions. I'll clean up the code to eliminate the warnings. The one about (-256 << 2) is surprising. I'll replace it with (-256 * 2).
David, I looked at the code you posted, and the changes look great. I replaced the (-256 << 2) with (-256 * 4), and that should fix all the warnings. The fgets thing in ReadString worked because the count was really only used as a logical value, and fgets returns a null pointer when the read fails. However, your change does make it look cleaner. Thanks
Comments
But I guess there is some magic in the p2 loader string...
The 64b encode is much faster than the older P1 design, and I think Chip has made the RC Osc 20MHz Min spec, which meant he was able to get close to 2Mbd, without having to work-backwards from some crystal value.
@ersmith, I've been working on the Linux version of loadp2 for a few hours, and I got the loader portion working. I'm still trying to get the terminal emulator to work. I've tried using the routines that work under Cygwin to disable buffering, echoing and waiting on stdin, but it doesn't work under Linux for some reason. I just realized that the console I/O code I use in spinsim works on Linux, so I'll give that code a try.
@David, I don't get any warnings when I compile the 002 code under Linux or Cygwin. Are you compiling on a Mac? Can you post the 4 warnings that you get? BTW, I looked at the p2load source code, and it's very impressive. It would be great if you could get that working with the latest version of the FPGA. However, I understand why you might want to wait until the chip design if finalized.
I'm not waiting for the P2 silicon. I'm waiting for my schedule to free up! I was dumb enough to accept three contract programming jobs at the same time and I haven't had much spare time lately. Maybe I should rethink whether it is time to retire and spend all of my newfound free time working on Propeller tools! :-)
Chip's P2 DOCs say this, you seem to be thinking of he P1 loader ?
P2 Autobauds, and uses the fractional baud ability, & 64b encode, to run a much faster stage 1 loader than P1 managed.
To support this, you just need to make the baud rate a user parameter ?
"SERIAL LOADING PROTOCOL
The built-in serial loader allows Propeller 2 chips to be loaded via 8-N-1 asynchronous serial into P63, where START=low and STOP=high, at any rate the sender uses, between 1,200 baud and 2M baud. The loader automatically adapts to the sender’s baud rate from every “>” character ($3E) it receives. It is necessary to initially send “> “ ($3E, $20) before the first command, and then use “>” characters periodically throughout your data to keep the baud rate tightly calibrated to the internal RC oscillator that the loader uses during boot ROM execution. Received “>” characters are not passed to the command parser, so they can be placed anywhere."
A stage 2 loader should be able to go even faster, of course.
@jmg, I might be able to run at a higher rate, but even at 115200 I had to insert several ">" characters just to load a few dozen bytes. I'm not sure how Chip implemented the RC clock in the FPGA. I'm wondering how stable it is. Of course, Chip's the expert on this, so if he says that the boot loader works at 2Mbaud, then I'm sure it does.
I got a little further on the Linux version of loadp2. It looks like the console I/O was OK all along, and the problem is with the serial rx() function. For some reason it is blocking waiting for data to come in on the serial port. Hopefully I can figure out what the problem is in the morning.
If you are reasonably secure... we are only here one time man. Have some fun!
I got contracts too. Been an ugly haul, startup mixed in there. I did get to write some P2 code last week though. Whew!
I'm no where near retirement, but you bet I'm gonna do some time carve outs. Go too long, and it saps the soul.
I can even send the file with no extra ">" characters.
I'll try it on some other FPGA boards and see if they differ.
on macOS (Sierra) there is still 1 warning:
$ cc -Wall -o p2asm *.c -lm p2asm.c:1111:78: warning: shifting a negative signed value is undefined [-Wshift-negative-value] if ((srcval&3) == 0 && srcval < (255 << 2) && srcval > (-256 << 2) && !is_loc) ~~~~ ^ 1 warning generated.dgately
Hmm, some variance there ? The latter is more expected.
I'd expect the FPGA to have a crystal derived 'virtual RC clock', and so be better in drift performance than any actual RC osc device.
(ie a single ">" may be ok on FPGA, but it might be a good idea to sprinkle sparse ">" in any loader, ready for the RC Osc)
The 600K+ I was referring to was the file size not baud rate,
I can confirm that ALL FPGA boards load successfully @ 2Mbaud using the txt loader.
Good to hear.
The 2MBd may be optimistic for a RC osc, which is why I suggest a user baud parameter, to allow easy experiment.
Most USB-UARTS have a virtual baud clock of either
12MHz which allows 2Mbd,1.714Mbd, 1.5Mbd,1.333MBd etc
or
24MHz, which allows 2MBd, 1.846MBd,1.714Mbd, 1.6MBd, 1.5Mbd,1.412MBd ,1.333MBd etc
As the baud drops the granularity error of AutoBaud extract, and Baud-Set improve.
Do your FPGAs also load at 1.714Mbd, 1.5Mbd, 1.333MBd ?
Does anyone know if the Boot-Load time SysCLK is always 80MHz (ie unchanged) or dropped to 20MHz in the FPGAs (to better emulate real parts) ?
A 80MHz syslk may give an optimistic ability indication.
C99 provides 'intptr_t' as 'the integer that's the same size as a pointer' in <stdint.h>.
Eric
Windows breaks this of course, just to be different.
Generally if you find yourself converting pointers to integers it's a sign you are doing something wrong.
I'll do some more testing with Prop_Hex and Prop_Ascii to see if I can figure out why it's not reliable for me. I suspect there may have been other issues when I was developing the code, and I stopped looking at it once I got something that worked using the secondary loader. I believe at some point I was able to load a large binary using Prop_Hex.
The 64-bit pointer thing always gets me. I currently don't have a machine that uses 64-bit pointers, so I never see those warnings. To me it seems like 64 bits is somewhat wasteful. It's rare that someone really needs more than 32 bits. Just thinking of all those 32 most significant bits that are identical, and never changing makes me wonder why we waste the sand to create the extra silicon that is unused.