What is the status of fastspin/C? It seems it works pretty well. I wrote and compiled a simple "Hello, world" program but it didn't run when I loaded it with loadp2. I suspect it has to do with the baud rate that is being used by printf. I told loadp2 to use 115200. Is there something I need to do to get the fastspin/C runtime library to use that baud rate? It seems that the Mac doesn't support 2000000.
You can explicitly set the clock speed and baud rate by adding code like the following to the start of main():
clkset(0x10c3f04, 160000000); // set clock to 160 MHz
_setbaud(115200); // set baud rate
The default baud is 2000000, which I guess doesn't work on the Mac? I didn't realize that. What baud rates does the Mac support?
@ersmith,
I realize that you are very busy and have a lot on your plate developing all the languages for fastspin. Also my primary interest is in your C and BASIC compilers. However, I would like to ask you to consider a modification to Spin2 at some point.
I like Spin for how it interacts with the micro, but I hate all that goes into printing to the terminal. I've written Spin programs where the largest number of program lines are for simply printing results. Trying to use print commands to debug a program is extremely frustrating. If it is possible, once you have more important tasks finished, I'd appreciate it if you could write a C-like print command/library.
There is a object in the OBEX called CLIB that I posted back in 2011 that supports printf plus several other C-like functions for Spin. It works on the P1, and probably on the P2 also.
There is a object in the OBEX called CLIB that I posted back in 2011 that supports printf plus several other C-like functions for Spin. It works on the P1, and probably on the P2 also.
Right, I'd forgotten about that. That's a good alternative for traditional Spin compilers. The fastspin PrintfSerial doesn't need printf1, printf2, etc. for different numbers of arguments, and doesn't need the string() wrapper around strings, but both of those features are due to fastspin extensions, so they may not be for everyone.
The fastspin method is much cleaner. I was just pointing out that there have been attempts at doing formatted prints before. I think there is another printf-like object in the OBEX, and a few other formatted print objects. I don't know why they didn't see more use, but most Spin code uses multiple tx, hex and str calls to print out a single line.
Is there an environment variable I can set to tell fastspin where to find its include files so I don't have to always specify -I on the command line?
No, but that sounds like a good suggestion As you already noticed it tries to look for argv[0]/../include, but that won't always work.
There is some ugly code in propeller-load that tries to figure out the path to the executable to use as the basis of forming an include path. It's in the file system.c.
Eric, what is the msvcrt.dll version that fastspin is linked with?
When trying to run it, I get some "_wfopen_s not found" message.
Tried to update to vc2017 redist, but I still get that.
The OS is XP 32bit.
I'm actually not sure which version of msvcrt.dll the code expects -- it's compiled with i686-w64-mingw32 on Linux. I'm sure it's very generic though. Looking at Microsoft's documentation for _wfopen_s at https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-s-wfopen-s?view=vs-2017 it does seem to say that _wfopen_s is available in "all versions of the C run-time libraries", which makes me think it should definitely be available in the vc2017 redist.
Perhaps something else on your PATH is overriding msvcrt.dll? Have you tried running it in a shell with PATH reset to just C:\Windows?
Then I searched for all msvcrt dlls in the system: there are two versions, also replicated in the system restore directory (if I erase or rename the one in system32, it magically reappears replaced with the latest version).
Thanks a lot anyway!
I'll try later with the larger PC (win7), then maybe recompiling on another mini laptop with linux.
Just FYI: I always build with static library so don't have to deal with this type of dll stuff...
Don't know if you have this option with mingw32 or not...
Just FYI: I always build with static library so don't have to deal with this type of dll stuff...
Don't know if you have this option with mingw32 or not...
I think so. That's the way we build propeller-load and proploader.
I've been looking some more at the "_wfopen_s" error and I'm even more puzzled. Thinking about it, I don't recall Windows ever being kind enough to give a specific missing function error when I've tried to run a program in the past -- usually it just silently crashes the program. Now, maybe Microsoft has fixed that since I last looked, or maybe it was working in W95 and broken in later versions. But I wonder if the error message is a red herring or badly worded and it's not a DLL issue but something else.
Does fastspin work if you just run it with no arguments? (It should print a usage message).
Could you post a screenshot of the exact error message please? Maybe it's coming from fastspin itself and I have a bug in its error reporting.
I've been looking some more at the "_wfopen_s" error and I'm even more puzzled. Thinking about it, I don't recall Windows ever being kind enough to give a specific missing function error when I've tried to run a program in the past -- usually it just silently crashes the program. Now, maybe Microsoft has fixed that since I last looked, or maybe it was working in W95 and broken in later versions. But I wonder if the error message is a red herring or badly worded and it's not a DLL issue but something else.
Does fastspin work if you just run it with no arguments? (It should print a usage message).
Could you post a screenshot of the exact error message please? Maybe it's coming from fastspin itself and I have a bug in its error reporting.
No, just running it alone, even from CLI, produces the error message (a requester window) before it really starts. I will post a screenshot later today.
But please, don't lose too much time on this, because I have multiple options to solve the problem.
Meanwhile I tried fastspin (and spin2gui) on my workplace PC (Win7 x86_64) and it seems to work flawlessly (no prop board to test, but it compiles, produces listings, etc).
I have a PC with similar configuration at home, and only used the other "relic" for convenience.
It looks like fastspin is not initializing RESULT to zero.
In opposite to all other local variables RESULT should be initialized to zero.
In general, fastspin does initialize RESULT to 0. For example,
PUB demo
OUTB := result
result := result + 1
compiles to:
_demo
mov outb, #0
mov result1, #1
_demo_ret
ret
It sounds like you're run across a case where this isn't happening, which is entirely believable (the RESULT handling in fastspin is a bit tricky). Could you post the failing code, please?
@AntoineDoinel
Does fastspin work if you just run it with no arguments? (It should print a usage message).
Could you post a screenshot of the exact error message please? Maybe it's coming from fastspin itself and I have a bug in its error reporting.
No, just running it alone, even from CLI, produces the error message (a requester window) before it really starts. I will post a screenshot later today.
But please, don't lose too much time on this, because I have multiple options to solve the problem.
Interesting. I guess Microsoft's documentation is wrong about _wfopen_s being available in "all versions" of msvcrt. It's only used in one place, I'll try to see if there's an easy way to replace it.
It looks like fastspin is not initializing RESULT to zero.
In opposite to all other local variables RESULT should be initialized to zero.
In general, fastspin does initialize RESULT to 0. For example,
PUB demo
OUTB := result
result := result + 1
compiles to:
_demo
mov outb, #0
mov result1, #1
_demo_ret
ret
It sounds like you're run across a case where this isn't happening, which is entirely believable (the RESULT handling in fastspin is a bit tricky). Could you post the failing code, please?
Thanks,
Eric
OK, I can guess why my code is confusing for your compiler.
'
' receive a byte (waits until done)
' returns received byte
'
PUB rx(port = 0)
RESULT := 0 'result not zero on entry?
rxread(@RESULT, 1, port)
'
' receive a block from serial to memory of given size in bytes (waits until done)
'
PUB rxread(hubaddress, size, port = 0)
rxread_async(hubaddress, size, port)
wait_rxready(port)
@AntoineDoinel : I removed the call to _wfopen_s and just used fopen. This may cause some problems with file names that are encoded in UTF-8 which don't fit in the current Windows code page, but I don't think that's a big issue.
@msrobots : I fixed the RESULT problem you were having. That was a nice bug -- if RESULT was never set in the function, but was passed to a function with a pointer and set there, it wasn't being initialized to 0.
There are a bunch of improvements to the fastspin C compiler as well, although it still isn't quite production ready (I can compile proplisp with it, for example, but it does not run correctly). It's certainly more usable than the last release though.
yes, thank you, the new version solved my RESULT problem.
Now have another one. Is the terminal used by spin2gui part of fastspin or is it part of the loader?
Because it looks like the terminal is just half-duplex, while receiving characters it does not send any back.
That did cost me hours of ripping my source apart, replacing locals by globals, putting in waits, wading thru your LST files (thank you for them, very helpful) until I finally realized that I can't get a char while the terminal is busy outputting text.
Now I have to put everything together again, since I need to stress test my full-duplex serial driver.
One other thing you got me with is changing the terminal baud rate from 2_000_000 to 230_400.
Comments
You can explicitly set the clock speed and baud rate by adding code like the following to the start of main():
The default baud is 2000000, which I guess doesn't work on the Mac? I didn't realize that. What baud rates does the Mac support?
I realize that you are very busy and have a lot on your plate developing all the languages for fastspin. Also my primary interest is in your C and BASIC compilers. However, I would like to ask you to consider a modification to Spin2 at some point.
I like Spin for how it interacts with the micro, but I hate all that goes into printing to the terminal. I've written Spin programs where the largest number of program lines are for simply printing results. Trying to use print commands to debug a program is extremely frustrating. If it is possible, once you have more important tasks finished, I'd appreciate it if you could write a C-like print command/library.
Thanks
Tom
Well, it does require some fastspin extensions, so it won't work on regular Spin.
Dave, I'll try CLIB on some Spin programs I need to finish.
Again, thanks to both of you for your efforts.
Tom
Right, I'd forgotten about that. That's a good alternative for traditional Spin compilers. The fastspin PrintfSerial doesn't need printf1, printf2, etc. for different numbers of arguments, and doesn't need the string() wrapper around strings, but both of those features are due to fastspin extensions, so they may not be for everyone.
Can afford more luxury with P2:)
Edit: Or maybe it could be found at a location relative to where the fastspin executable is found?
Edit2: I see fastspin.c already tries to do this. Unfortunately, argv[0] on the Mac is not the full path to the executable.
No, but that sounds like a good suggestion
Eric, what is the msvcrt.dll version that fastspin is linked with?
When trying to run it, I get some "_wfopen_s not found" message.
Tried to update to vc2017 redist, but I still get that.
The OS is XP 32bit.
I'm actually not sure which version of msvcrt.dll the code expects -- it's compiled with i686-w64-mingw32 on Linux. I'm sure it's very generic though. Looking at Microsoft's documentation for _wfopen_s at https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-s-wfopen-s?view=vs-2017 it does seem to say that _wfopen_s is available in "all versions of the C run-time libraries", which makes me think it should definitely be available in the vc2017 redist.
Perhaps something else on your PATH is overriding msvcrt.dll? Have you tried running it in a shell with PATH reset to just C:\Windows?
Then I searched for all msvcrt dlls in the system: there are two versions, also replicated in the system restore directory (if I erase or rename the one in system32, it magically reappears replaced with the latest version).
Thanks a lot anyway!
I'll try later with the larger PC (win7), then maybe recompiling on another mini laptop with linux.
Enjoy!
Mike
Don't know if you have this option with mingw32 or not...
I've been looking some more at the "_wfopen_s" error and I'm even more puzzled. Thinking about it, I don't recall Windows ever being kind enough to give a specific missing function error when I've tried to run a program in the past -- usually it just silently crashes the program. Now, maybe Microsoft has fixed that since I last looked, or maybe it was working in W95 and broken in later versions. But I wonder if the error message is a red herring or badly worded and it's not a DLL issue but something else.
Does fastspin work if you just run it with no arguments? (It should print a usage message).
Could you post a screenshot of the exact error message please? Maybe it's coming from fastspin itself and I have a bug in its error reporting.
In opposite to all other local variables RESULT should be initialized to zero.
Enjoy!
Mike
No, just running it alone, even from CLI, produces the error message (a requester window) before it really starts. I will post a screenshot later today.
But please, don't lose too much time on this, because I have multiple options to solve the problem.
Meanwhile I tried fastspin (and spin2gui) on my workplace PC (Win7 x86_64) and it seems to work flawlessly (no prop board to test, but it compiles, produces listings, etc).
I have a PC with similar configuration at home, and only used the other "relic" for convenience.
In general, fastspin does initialize RESULT to 0. For example, compiles to:
_demo mov outb, #0 mov result1, #1 _demo_ret retIt sounds like you're run across a case where this isn't happening, which is entirely believable (the RESULT handling in fastspin is a bit tricky). Could you post the failing code, please?
Thanks,
Eric
Interesting. I guess Microsoft's documentation is wrong about _wfopen_s being available in "all versions" of msvcrt. It's only used in one place, I'll try to see if there's an easy way to replace it.
Thanks,
Eric
here's the screenshot, it reads:
"It's impossible to find the entry point of the _wfopen_s procedure in the dynamical link library msvcrt.dll"
Just got it installed in a "borrowed"
OK, I can guess why my code is confusing for your compiler.
Enjoy!
Mike
@AntoineDoinel : I removed the call to _wfopen_s and just used fopen. This may cause some problems with file names that are encoded in UTF-8 which don't fit in the current Windows code page, but I don't think that's a big issue.
@msrobots : I fixed the RESULT problem you were having. That was a nice bug -- if RESULT was never set in the function, but was passed to a function with a pointer and set there, it wasn't being initialized to 0.
There are a bunch of improvements to the fastspin C compiler as well, although it still isn't quite production ready (I can compile proplisp with it, for example, but it does not run correctly). It's certainly more usable than the last release though.
yes, thank you, the new version solved my RESULT problem.
Now have another one. Is the terminal used by spin2gui part of fastspin or is it part of the loader?
Because it looks like the terminal is just half-duplex, while receiving characters it does not send any back.
That did cost me hours of ripping my source apart, replacing locals by globals, putting in waits, wading thru your LST files (thank you for them, very helpful) until I finally realized that I can't get a char while the terminal is busy outputting text.
Now I have to put everything together again, since I need to stress test my full-duplex serial driver.
One other thing you got me with is changing the terminal baud rate from 2_000_000 to 230_400.
Enjoy!
Mike