Also if I comment out the code on line 32 it runs but of course no data as that is the line I need to get the data. The object ping.spin2 is in the same file as the testing program.
Would someone please tell me why I get this error. I am attempting to port over the simple ping demo from spin to spin2 and I get the following error:
"C:/Users/mm/Desktop/spin2gui 1.3.5/spin2gui/spin2gui/bin/fastspin" -2 -l -O1 -L "./lib" "C:/Users/mm/Desktop/spin2works/ping test .spin2"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 3.9.16 Compiled on: Jan 29 2019
child killed: segmentation violation
$ fastspin -2 ping.spin2
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 3.9.18-beta- Compiled on: Feb 8 2019
ping.spin2
error: Symbol waitpne is of a type not handled by PASM output yet
Segmentation fault: 11
The error "error: Symbol waitpne is of a type not handled by PASM output yet" is coming from ping.spin2... Looks like a fastspin problem, not handling waitpne yet??
The Segmentation Fault: 11 is possibly a side-effect of that error, but probably needs a look at as well.
You've found a bug in fastspin's error handling -- instead of crashing it should be complaining that waitpne is not defined. The waitpne function is not provided for P2.
I'd prefer it if the high level P2 languages would use those names and generate the equivalent P2ASM code. But I'm not sure what the authors of those languages want.
It's tricky to reproduce that instruction exactly:
There is a more complicated equivalent but there is two caveats that come with it. One is it consumes a specific shared hardware resource - an event compare register. The other is that all WAITxxx instructions block interrupts. Neither caveat may be of concern but the compiler isn't going to easily know if they are.
The alternative approach is do a tight two instruction loop testing the specified pin with TESTP instruction. This eliminates both above potential concerns and is very easy to understand but introduces a tiny amount of jitter that wouldn't have been present in the original prop1 code.
Dave Hein,
I ran the batch file for p2gcc what is supposed to happen. I did not see anything. Is there something else I need to do go get it to run??
Thanks
Martin
I'm not sure how you ran it, but I guessing you double-clicked on the p2gcc.bat file. If that's what you did you will see a momentary flash, where the window starts up and then immediately closes. What you need to do is run a "Command Prompt" window. If you have an icon for that, then click on that. Otherwise, you will need to go the start menu, which is the small Windows icon on the lower left of your screen. On Windows 10 it is under "Windows System". On Windows 7 it may be located somewhere else, such as in "Windows Accessories".
Once you've opened a command prompt window use the cd command to change to the p2gcc directory. Within that directory type p2gcc, and it will list the options that you can use. You will need to add the bin directory to your path and define a P2GCC_LIBDIR environment variable that points to your lib directory. On my system I issue the two following commands:
set PATH=%PATH%;C:\Users\Dave\Desktop\p2gcc\bin
set P2GCC_LIBDIR=C:\Users\Dave\Desktop\p2gcc\lib
After you do this you can build and load C programs. You can run the hello program by typing
p2gcc -r -t hello.c
There are a few other sample programs in the p2gcc directory.
For most instructions ptra is a register with an address of $1f8. For instructions, such as rdlong, wrbyte and others that access memory ptra is a memory pointer, and in that case it uses the pointer encoding.
I am wanting to looking for the C programs can I get a fullduplexserial in C so I can get incoming asynchronous data. For my project in the p2
thanks.
The serial routines in the p2gcc library transmit and receive serial data only when they are called, so I don't think they will serve your purpose. However, I do have some code that runs in a separate cog that will receive serial data and buffer while the main code is running in cog 0, which may work for you. You can use the kbhit() function to determine if a character has been received, and then call getch() to receive the character. You first have to start the rx serial cog by calling start_rx_cog(). Use putch() to send characters without any processing. If you use putchar() it will convert linefeeds into carriage-return followed by a linefeed.
Question?
I have been attempting to start CogSerial.spin2 in a second cog and get this error. Wanting to use the serial program in two different cogs simultaneously. Was able to do it in P1 but seem not to be able to do it easily in P2.
Dave: Where are you getting your library code from? If I'm going to try to contribute I'd like to use the same source. I've been looking at Eric's proplib repository that contains the code used in PropGCC.
Up to now I've been writing my own library functions. At some point I plan on porting the P1 PropGCC library code. So you could either write them from scratch, or you might want to copy them over from PropGCC. The PropGCC setjmp and longjmp may have tentacles in system code, so it might be better to do them from scratch. They just need to tie into the jmp_buf struct.
Up to now I've been writing my own library functions. At some point I plan on porting the P1 PropGCC library code. So you could either write them from scratch, or you might want to copy them over from PropGCC. The PropGCC setjmp and longjmp may have tentacles in system code, so it might be better to do them from scratch. They just need to tie into the jmp_buf struct.
I think the P1 setjmp/longjmp should work for your P2 compiler if you use the same calling conventions. It just saves and restores registers. They are written in assembler but they mostly just do wrlong and rdlong to save and restore the registers.
I think overall it makes sense for us to port the P1 PropGCC library over to P2. With appropriate #ifdefs I think we can make it work for both p2gcc and fastspin, and I think that would be worthwhile. I've started work on this for fastspin, but I haven't had time to try it out with p2gcc yet.
The one place where I don't like the PropGCC library is the way it handles fopen() and FILEs. We introduced what I think in retrospect was a complicated driver mechanism so that the user could always use fopen("driver:somestring", "mode") to open a file. That's fine if there's an existing driver, but writing the device driver is another hoop to jump through. I think that was a mistake. I'd be inclined to save fopen("file", "r") and the like for accessing the SD card, and provide a new fopen_device function that looks something like:
fopen_device(putc_func, getc_func, mode)
Then you can quickly hook up any device you have a putchar and getchar for to the C library.
I think overall it makes sense for us to port the P1 PropGCC library over to P2. With appropriate #ifdefs I think we can make it work for both p2gcc and fastspin, and I think that would be worthwhile. I've started work on this for fastspin, but I haven't had time to try it out with p2gcc yet.
The one place where I don't like the PropGCC library is the way it handles fopen() and FILEs. We introduced what I think in retrospect was a complicated driver mechanism so that the user could always use fopen("driver:somestring", "mode") to open a file. That's fine if there's an existing driver, but writing the device driver is another hoop to jump through. I think that was a mistake. I'd be inclined to save fopen("file", "r") and the like for accessing the SD card, and provide a new fopen_device function that looks something like:
fopen_device(putc_func, getc_func, mode)
Then you can quickly hook up any device you have a putchar and getchar for to the C library.
Thoughts?
Will we even have a standard interface to drivers on P2? I remember trying to define one for P1 and we could never get consensus.
Anyway, I think getting your proplib to work for both fastspin and p2gcc would be a good idea. I'm in the process of moving a couple of functions over so I can compile ebasic3 under p2gcc. I guess I could just keep going to see how far I can get. That is, unless one or both of you are already doing this.
I'd be inclined to save fopen("file", "r") and the like for accessing the SD card, and provide a new fopen_device function that looks something like:
fopen_device(putc_func, getc_func, mode)
Then you can quickly hook up any device you have a putchar and getchar for to the C library.
Thoughts?
Will we even have a standard interface to drives on P2? I remember trying to define one for P1 and we could never get consensus.
Anyway, I think getting your proplib to work for both fastspin and p2gcc would be a good idea. I'm in the process of moving a couple of functions over so I can compile ebasic3 under p2gcc. I guess I could just keep going to see how far I can get. That is, unless one or both of you are already doing this.
The more people who can work on this stuff the better. And the more we can share across projects the better too. So thanks for helping out!
The more people who can work on this stuff the better. And the more we can share across projects the better too. So thanks for helping out!
Okay, so what's the best way to do this? Maybe I should make a proplib2 project in GitHub and start populating it from your proplib project for P1? I guess another question should be whether this new library should target P1 as well as fastspin and p2gcc?
I think it would be good to use the library source for both P1 and P2. As far as the file system, the P1 system seem to work OK. However, it would be good to look at other methods.
Eric: Do you intend to keep using the _IMPL method of associating function prototypes with the files containing their implementation? If so, I will have to add those clauses to all of the header files I move over from proplib. You've already done that for the ones you've moved over.
Comments
The error "error: Symbol waitpne is of a type not handled by PASM output yet" is coming from ping.spin2... Looks like a fastspin problem, not handling waitpne yet??
The Segmentation Fault: 11 is possibly a side-effect of that error, but probably needs a look at as well.
dgately
I'd prefer it if the high level P2 languages would use those names and generate the equivalent P2ASM code. But I'm not sure what the authors of those languages want.
Tom
There is a more complicated equivalent but there is two caveats that come with it. One is it consumes a specific shared hardware resource - an event compare register. The other is that all WAITxxx instructions block interrupts. Neither caveat may be of concern but the compiler isn't going to easily know if they are.
The alternative approach is do a tight two instruction loop testing the specified pin with TESTP instruction. This eliminates both above potential concerns and is very easy to understand but introduces a tiny amount of jitter that wouldn't have been present in the original prop1 code.
I ran the batch file for p2gcc what is supposed to happen. I did not see anything. Is there something else I need to do go get it to run??
Thanks
Martin
Once you've opened a command prompt window use the cd command to change to the p2gcc directory. Within that directory type p2gcc, and it will list the options that you can use. You will need to add the bin directory to your path and define a P2GCC_LIBDIR environment variable that points to your lib directory. On my system I issue the two following commands:
set PATH=%PATH%;C:\Users\Dave\Desktop\p2gcc\bin
set P2GCC_LIBDIR=C:\Users\Dave\Desktop\p2gcc\lib
After you do this you can build and load C programs. You can run the hello program by typing
p2gcc -r -t hello.c
There are a few other sample programs in the p2gcc directory.
In it I see this compiled code:
shouldn't and
Mike
Mike
Never mind. I figured it out. MOV SP, [PTRA].
So please excuse me.
I am wanting to looking for the C programs can I get a fullduplexserial in C so I can get incoming asynchronous data. For my project in the p2
thanks.
btw I am an old coder from the fortran days. Old FORTRAN
let me know.
nice toys to interface with
Wat four
It's easy to do telemetry inline. The hardware is at your disposal. Are you sure you need it as background?
Thanks for the assist. I am having a hard time finding the directory. It has been ages since I have delt with dos files.
I have been attempting to start CogSerial.spin2 in a second cog and get this error. Wanting to use the serial program in two different cogs simultaneously. Was able to do it in P1 but seem not to be able to do it easily in P2.
The one place where I don't like the PropGCC library is the way it handles fopen() and FILEs. We introduced what I think in retrospect was a complicated driver mechanism so that the user could always use fopen("driver:somestring", "mode") to open a file. That's fine if there's an existing driver, but writing the device driver is another hoop to jump through. I think that was a mistake. I'd be inclined to save fopen("file", "r") and the like for accessing the SD card, and provide a new fopen_device function that looks something like: Then you can quickly hook up any device you have a putchar and getchar for to the C library.
Thoughts?
Anyway, I think getting your proplib to work for both fastspin and p2gcc would be a good idea. I'm in the process of moving a couple of functions over so I can compile ebasic3 under p2gcc. I guess I could just keep going to see how far I can get. That is, unless one or both of you are already doing this.
The more people who can work on this stuff the better. And the more we can share across projects the better too. So thanks for helping out!
I mean lines like this from string.h:
char * strchr(const char *, int) _IMPL("libc/string/strchr.c");