@Wuerfel_21 : -std=gnu11 shouldn't be necessary; it is definitely my intention that flexspin should be able to build with any C99 conforming compiler, although so far I've only tried clang and gcc.
@ersmith said:
@Wuerfel_21 : -std=gnu11 shouldn't be necessary; it is definitely my intention that flexspin should be able to build with any C99 conforming compiler, although so far I've only tried clang and gcc.
Then set -std=c99 (truth be told, I have no idea what the difference between gnu99 and c99 modes even is)
Or if you click on the link in my signature https://github.com/totalspectrum/flexprop/releases you'll see a page describing the various releases available. At the end of the 5.9.20 description there's a section called "Assets" with 3 files listed. The first one, flexprop-5.9.20.zip, is the one you want; the other two are compressed versions of the source code.
I just downloaded and installed 5.9.20, thanks Eric. However I must be getting too old for this stuff, I cannot remember how to start flexprop from the linux command line.
Jim
@RS_Jim said:
I just downloaded and installed 5.9.20, thanks Eric. However I must be getting too old for this stuff, I cannot remember how to start flexprop from the linux command line.
Jim
There's no pre-built linux binary in the .zip file, unfortunately you'll have to build it yourself. The instructions are in the README. Starting it from the linux command line is just:
cd ~/flexprop # or wherever you installed
./flexprop
I have problems setting up the clock and baud rate on my custom P2 board. I have a 50MHz clock source connected to XI. This Spin program works perfectly
CON
_xtlfreq = 50_000_000 ' master clock vom Ethernet-Controller
_clkfreq = 200_000_000
pinLedG = 2 ' green LED (front panel)
pinLedR = 3 ' red LED (front panel)
PUB main ()
pinh (pinLedG)
debug ("Test OK")
repeat
I tried the same in C. sys/p2_clock.h doesn't know 50MHz but I've fixed that by providing the hardwired PLL setup on my own.
#define modePll 0b1_000000_0000000011_1111_01_11 // 200 = 50 * 4
#define _XTALFREQ 50_000_000
#define _CLOCKFREQ 200_000_000
#define P2_TARGET_MHZ 200
#define _XOSC 1
//#include <sys/p2_clock.h>
#define _BAUD 230400 // serial debug port
#include <propeller2.h>
#include <stdio.h>
#define pinLedG 2 // front LED green
#define pinLedR 3 // front LED red
int main (void)
{
_clkset (modePll, _CLOCKFREQ);
_setbaud(_BAUD);
_pinh (pinLedG);
printf ("Test OK");
while (1) {};
}
Unfortunatelly, this doesn't work at all. The LED does not light up and no output appears in the terminal window. Any idea what I did wrong?
works on the KISS board with a 25MHz crystal. I thought loadP2 doesn't like the 50MHz clock and overspeeds but why does it work with the Spin2 program and not with C? I use VSC and FlexC to compile and LoadP2 to download for both.
Thanks @Ariba and @evanh, now it works! But I still wonder why it doesn't with my previous clock setting. According to the docs both methods should be valid. And both methods actually work at 20 or 25MHz but at 50MHz the _setclk() or p2_clock.h doesn't. Strange
IMHO, _setclk() should internally handle the right sequence and delays to switch the clock source properly. So the clock should be stable immediately after returning from _setclk(). On the other hand _setbaud() of course does not work immediately if there are still some characters in the send buffer. If the baud rate is misadjusted there should be at least some garbled characters visible. And the LED must work at any clock frequency.
I have to check the generated assembler code to find out the difference. I guess that the enum{} method uses Chip's magic code to calculate the optimum PLL settings. The direct _setclk() method might have a bug where it first switches to what it thinks the old PLL ratio was, waits for the 10ms delay and then switches to the new settings. This would cause an intermediate clock frequency of 400MHz to be set which crashes the P2. Just speculations....
For sure _setclk() does do the correct sequence for reliable frequency change.
And yep, I guess it must be stable before returning. A quick test of your code adjusted to suit an Eval Board shows I get the message cleanly printed. So not sure why you've got an issue with setclk().
#include <stdio.h>
#define modePll 0b1_000000_0000000011_1111_10_11 // 200 = 50 * 4
#define _CLOCKFREQ 80_000_000
#define _BAUD 230400 // serial debug port
int main (void)
{
_clkset (modePll, _CLOCKFREQ);
_setbaud(_BAUD);
printf ("Test OK\n");
while (1) {};
}
compiles without problems. I thought both versions should be semantically identical. It would also be good if the "internal error" would at least give some hint where the error occured. It takes quite some time to find the cause by shotgun debugging if the source code is rather long.
Today is one of those days I'm out of luck. I spend more time debugging the compiler than my own code (which should have lots of bugs on it's own so I don't run out of work).
The following simple program should print "Text=Hello World len=11"
but instead it prints "Text= len=0". However, if I comment out the line struct __using(... it works as it should. I'm not calling or using any contents of net_protocol.spin2. I think the combination of C and Spin2 somehow messes up the allocation of memory, again.
(PS: please replace _xinfreq = 50_000_000 with _xtlfreq = 20_000_000 if you run it on a standard EVAL board)
OK, I've also spotted the reason why the _clkset() in the main function does not work in my case. The enum clock setting method compiles to this asssembler code which looks reasonable and works:
This is no problem if the defaults are just slightly off the reality such as 20 vs. 25MHz at the KISS board. But in this case a PLL factor of x8 means that the clock is actually set to 50*8=400MHz! This leads to a crash. So the advice is "do always use the enum method to set the clock if your XIN is way above 20MHz".
@ManAtWork said:
This is no problem if the defaults are just slightly off the reality such as 20 vs. 25MHz at the KISS board. But in this case a PLL factor of x8 means that the clock is actually set to 50*8=400MHz! This leads to a crash. So the advice is "do always use the enum method to set the clock if your XIN is way above 20MHz".
Yeah, figures. Compilers, as opposed to assemblers, want to have a known sysclock frequency. Without it specified the compilers will all assume a 20 MHz crystal is attached to XI/XO pins.
Binaries for FlexProp 5.9.21 are available now on github (they've been up on Patreon for a little while). Changes include:
- Automatically zero local Spin2 variables
- Fixed loop test for downwards loops with steps > 1.
- Fixed some problems with variable offsets in Spin
- Fixed an incorrect read/write optimization affecting assembly output
- Improved handling of two dimensional arrays in BASIC
- Improved handling of method pointers in Spin2
- Optimized ZEROX (thanks Ada)
- Optimize some "obvious" 64 bit shifts
- Restored generation of all public methods in spin2cpp C and C++ output
@ManAtWork said:
The following simple program should print "Text=Hello World len=11"
It does for me using FlexProp 5.9.21. Which version were you trying it with?
5.9.20 had the problem. Like you say, 5.9.21 works.
With 5.9.21, I'm getting some extraneous emitted text when -gbrk is specified. It looks like maybe the baud is wrong with presumably the [COG0] startup message is being emitted. I'm defining DEBUG_BAUD as 230400. Examples: d$TfDt4� $tgt$T� d4T&6$�
PS: I wasn't actually using any debug calls in my code.
@evanh said:
With 5.9.21, I'm getting some extraneous emitted text when -gbrk is specified. It looks like maybe the baud is wrong with presumably the [COG0] startup message is being emitted. I'm defining DEBUG_BAUD as 230400.
What language are you using? Do you have some sample cod you can share? It could be a case problem, if it's in C. If all else fails put -D_BAUD=230400 on the command line; that's the way FlexProp defines the baud and it always seems to work.
Comments
@Wuerfel_21 : -std=gnu11 shouldn't be necessary; it is definitely my intention that flexspin should be able to build with any C99 conforming compiler, although so far I've only tried clang and gcc.
Then set -std=c99 (truth be told, I have no idea what the difference between gnu99 and c99 modes even is)
@ersmith
Trying to download:FlexProp 5.9.20
from github. I do not see a download link. Github is a pain. Can you help.
Thank you in advance.
Martin
https://github.com/totalspectrum/flexprop/releases/tag/v5.9.20
Or if you click on the link in my signature https://github.com/totalspectrum/flexprop/releases you'll see a page describing the various releases available. At the end of the 5.9.20 description there's a section called "Assets" with 3 files listed. The first one, flexprop-5.9.20.zip, is the one you want; the other two are compressed versions of the source code.
I just downloaded and installed 5.9.20, thanks Eric. However I must be getting too old for this stuff, I cannot remember how to start flexprop from the linux command line.
Jim
There's no pre-built linux binary in the .zip file, unfortunately you'll have to build it yourself. The instructions are in the README. Starting it from the linux command line is just:
@ersmith
When I click on assets all I get are circles. Does not matter which version.
Sounds like a browser issue. I can see all of it on Firefox, Edge and IOS.
Try this one: https://github.com/totalspectrum/flexprop/releases/download/v5.9.20/flexprop-5.9.20.zip
@JRoark Thanks for the link. I was using waterfox. And as usual had to run the compatibility trouble shooter because of windows 10
@ersmith
Thanks Eric. I could not remember the ./flexprop. I guess it is time for a sticky note!
Jim
I have problems setting up the clock and baud rate on my custom P2 board. I have a 50MHz clock source connected to XI. This Spin program works perfectly
CON _xtlfreq = 50_000_000 ' master clock vom Ethernet-Controller _clkfreq = 200_000_000 pinLedG = 2 ' green LED (front panel) pinLedR = 3 ' red LED (front panel) PUB main () pinh (pinLedG) debug ("Test OK") repeatI tried the same in C. sys/p2_clock.h doesn't know 50MHz but I've fixed that by providing the hardwired PLL setup on my own.
#define modePll 0b1_000000_0000000011_1111_01_11 // 200 = 50 * 4 #define _XTALFREQ 50_000_000 #define _CLOCKFREQ 200_000_000 #define P2_TARGET_MHZ 200 #define _XOSC 1 //#include <sys/p2_clock.h> #define _BAUD 230400 // serial debug port #include <propeller2.h> #include <stdio.h> #define pinLedG 2 // front LED green #define pinLedR 3 // front LED red int main (void) { _clkset (modePll, _CLOCKFREQ); _setbaud(_BAUD); _pinh (pinLedG); printf ("Test OK"); while (1) {}; }Unfortunatelly, this doesn't work at all. The LED does not light up and no output appears in the terminal window. Any idea what I did wrong?
Nearly the same code but with
works on the KISS board with a 25MHz crystal. I thought loadP2 doesn't like the 50MHz clock and overspeeds but why does it work with the Spin2 program and not with C? I use VSC and FlexC to compile and LoadP2 to download for both.
Have you tried:
enum{ _xtlfreq = 50_000_000, _clkfreq = 200_000_000 };This should be the same as with Spin2.
Andy
The ideal setting is:
enum{ _xinfreq = 50_000_000, _clkfreq = 200_000_000 };This removes the XI/XO loading caps.
PS: Here's my boiler plate at top of every C program:
enum { // _xinfreq = 20_000_000, _xtlfreq = 20_000_000, _clkfreq = 100_000_000, DOWNLOAD_BAUD = 230_400, DEBUG_BAUD = DOWNLOAD_BAUD, };Thanks @Ariba and @evanh, now it works!
But I still wonder why it doesn't with my previous clock setting. According to the docs both methods should be valid. And both methods actually work at 20 or 25MHz but at 50MHz the _setclk() or p2_clock.h doesn't. Strange
The printf() is too soon for PLL to have adjusted. Recommended pause is something like 10 ms. The LED might be some other reason like inverted drive.
IMHO, _setclk() should internally handle the right sequence and delays to switch the clock source properly. So the clock should be stable immediately after returning from _setclk(). On the other hand _setbaud() of course does not work immediately if there are still some characters in the send buffer. If the baud rate is misadjusted there should be at least some garbled characters visible. And the LED must work at any clock frequency.
I have to check the generated assembler code to find out the difference. I guess that the enum{} method uses Chip's magic code to calculate the optimum PLL settings. The direct _setclk() method might have a bug where it first switches to what it thinks the old PLL ratio was, waits for the 10ms delay and then switches to the new settings. This would cause an intermediate clock frequency of 400MHz to be set which crashes the P2. Just speculations....
For sure
_setclk()does do the correct sequence for reliable frequency change.And yep, I guess it must be stable before returning. A quick test of your code adjusted to suit an Eval Board shows I get the message cleanly printed. So not sure why you've got an issue with setclk().
#include <stdio.h> #define modePll 0b1_000000_0000000011_1111_10_11 // 200 = 50 * 4 #define _CLOCKFREQ 80_000_000 #define _BAUD 230400 // serial debug port int main (void) { _clkset (modePll, _CLOCKFREQ); _setbaud(_BAUD); printf ("Test OK\n"); while (1) {}; }Oh, what you could try is presetting the compile-time startup and then adjusting with _clkset() ...
#include <stdio.h> #define modePll 0b1_000000_0000000011_1111_01_11 // 200 = 50 * 4 #define _CLOCKFREQ 200_000_000 #define _BAUD 230400 // serial debug port enum{ _xinfreq = 50_000_000, _clkfreq = 20_000_000 }; int main (void) { printf (" Test starting ... \n"); _waitms(100); _clkset (modePll, _CLOCKFREQ); _setbaud(_BAUD); printf ("Test OK\n"); while (1) {}; }Assuming that works, that'll offer reasonable confirmation of a compile-time/loader/defaults limitation.
@ersmith I've just found a minor bug related to 64 bit integer types:
uint64_t velSum; int idleCntP; ... bool IsMoving () { return velSum || idleCntP; }causes an "internal error: dereference of large object". While
bool IsMoving () { return (velSum != 0) || idleCntP; }compiles without problems. I thought both versions should be semantically identical. It would also be good if the "internal error" would at least give some hint where the error occured. It takes quite some time to find the cause by shotgun debugging if the source code is rather long.
Today is one of those days I'm out of luck. I spend more time debugging the compiler than my own code (which should have lots of bugs on it's own so I don't run out of work).
The following simple program should print "Text=Hello World len=11"
enum { _xinfreq = 50_000_000, _clkfreq = 200_000_000, DOWNLOAD_BAUD = 230_400, DEBUG_BAUD = DOWNLOAD_BAUD, }; #include <propeller2.h> #include <stdio.h> #include <string.h> struct __using("net_protocol.spin2") net; char* Text = "Hello World"; int main (void) { printf ("Text=%s len=%d\n", Text, strlen(Text)); }but instead it prints "Text= len=0".
However, if I comment out the line
struct __using(...it works as it should. I'm not calling or using any contents of net_protocol.spin2. I think the combination of C and Spin2 somehow messes up the allocation of memory, again.(PS: please replace
_xinfreq = 50_000_000with_xtlfreq = 20_000_000if you run it on a standard EVAL board)OK, I've also spotted the reason why the _clkset() in the main function does not work in my case. The enum clock setting method compiles to this asssembler code which looks reasonable and works:
00000 | con 00000 | _clkfreq = 200000000 00000 | _clkmode = 16778231 = %1_000000_0000000011_1111_01_11 00000 | dat 00000 000 00 00 00 00 | nop 00004 001 01 EC 63 FD | cogid pa 00008 002 02 00 00 FF 0000c 003 04 EC E7 FC | coginit pa,##$404 00010 | orgh $10 00010 00 00 00 00 | long 0 'reserved 00014 00 00 00 00 | long 0 ' clock frequency: will default to 200000000 00018 00 00 00 00 | long 0 ' clock mode: will default to $10003f7 0001c 00 00 00 00 ... 003f8 00 00 00 00 003fc 00 00 00 00 | orgh $400 00400 00 94 05 06 | _ret_ mov result1, #0 00404 000 | org 0 00404 000 | entry 00404 000 00 F0 0F F2 | cmp ptra, #0 wz 00408 001 0C 02 90 5D | if_ne jmp #spininit 0040c 002 C9 F0 03 F6 | mov ptra, ptr_stackspace_ 00410 003 14 EC 0F FB | rdlong pa, #20 wz 00414 004 EC 01 90 5D | if_ne jmp #skip_clock_set_ 00418 005 00 00 64 FD | hubset #0 0041c 006 01 80 80 FF 00420 007 00 E8 67 FD | hubset ##16778228 ' SS=00 RCFAST 00424 008 86 01 80 FF 00428 009 1F 80 66 FD | waitx ##200000 ' wait 10ms 0042c 00a 01 80 00 FF 00430 00b F7 ED 07 F6 | mov pa, ##16778231 ' SS=11 PLL 00434 00c 00 EC 63 FD | hubset pa 00438 00d 18 EC 67 FC | wrlong pa, #24 0043c 00e E1 F5 85 FF 00440 00f 14 00 6C FC | wrlong ##200000000, #20 00444 010 BC 01 90 FD | jmp #skip_clock_set_ 00448 011 00 00 00 00 ... 005fc 07e 00 00 00 00 00600 07f 00 00 00 00 | orgf 128 00604 080 | skip_clock_set_ 00604 080 34 07 A0 FD | call #_main 00608 081 | cogexitHowever, if I DO NOT set the enum values the compiler still generates code to set the clock BEFORE my main function gets called.
00010 | orgh $10 00010 00 00 00 00 | long 0 'reserved 00014 00 00 00 00 | long 0 ' clock frequency: will default to 160000000 00018 00 00 00 00 | long 0 ' clock mode: will default to $10007fb 0001c 00 00 00 00 ... 003f8 00 00 00 00 003fc 00 00 00 00 | orgh $400 00400 00 94 05 06 | _ret_ mov result1, #0 00404 000 | org 0 00404 000 | entry 00404 000 00 F0 0F F2 | cmp ptra, #0 wz 00408 001 0C 02 90 5D | if_ne jmp #spininit 0040c 002 C9 F0 03 F6 | mov ptra, ptr_stackspace_ 00410 003 14 EC 0F FB | rdlong pa, #20 wz 00414 004 EC 01 90 5D | if_ne jmp #skip_clock_set_ 00418 005 00 00 64 FD | hubset #0 0041c 006 03 80 80 FF 00420 007 00 F0 67 FD | hubset ##16779256 00424 008 86 01 80 FF 00428 009 1F 80 66 FD | waitx ##200000 0042c 00a 03 80 00 FF 00430 00b FB ED 07 F6 | mov pa, ##16779259 = %1_000000_0000000111_1111_10_11 00434 00c 00 EC 63 FD | hubset pa 00438 00d 18 EC 67 FC | wrlong pa, #24 0043c 00e B4 C4 84 FF 00440 00f 14 00 6C FC | wrlong ##160000000, #20 00444 010 BC 01 90 FD | jmp #skip_clock_set_ 00448 011 00 00 00 00 ... 005fc 07e 00 00 00 00 00600 07f 00 00 00 00 | orgf 128 00604 080 | skip_clock_set_ 00604 080 34 07 A0 FD | call #_main 00608 081 | cogexitThis is no problem if the defaults are just slightly off the reality such as 20 vs. 25MHz at the KISS board. But in this case a PLL factor of x8 means that the clock is actually set to 50*8=400MHz! This leads to a crash. So the advice is "do always use the enum method to set the clock if your XIN is way above 20MHz".
Yeah, figures. Compilers, as opposed to assemblers, want to have a known sysclock frequency. Without it specified the compilers will all assume a 20 MHz crystal is attached to XI/XO pins.
[ignore]
Thank you, that's fixed in the github sources now.
It does for me using FlexProp 5.9.21. Which version were you trying it with?
Binaries for FlexProp 5.9.21 are available now on github (they've been up on Patreon for a little while). Changes include:
5.9.20 had the problem. Like you say, 5.9.21 works.
With 5.9.21, I'm getting some extraneous emitted text when -gbrk is specified. It looks like maybe the baud is wrong with presumably the [COG0] startup message is being emitted. I'm defining DEBUG_BAUD as 230400. Examples:
d$TfDt4�$tgt$T�d4T&6$�PS: I wasn't actually using any debug calls in my code.
What language are you using? Do you have some sample cod you can share? It could be a case problem, if it's in C. If all else fails put -D_BAUD=230400 on the command line; that's the way FlexProp defines the baud and it always seems to work.