@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
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.
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:
This should be the same as with Spin2.
Andy
The ideal setting is:
This removes the XI/XO loading caps.
PS: Here's my boiler plate at top of every C program:
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().
Oh, what you could try is presetting the compile-time startup and then adjusting with _clkset() ...
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:
causes an "internal error: dereference of large object". While
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:
However, if I DO NOT set the enum values the compiler still generates code to set the clock BEFORE my main function gets called.
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.
[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.