As far as I can tell, with compiling C code using FlexC, most built-ins like this are written in pre-compiled Spin. The above Spin source code is the only implimentation code I could find in Eric's files.
Just reading the patch notes ... and noted it says the Edge Board has same definition as Eval Board. The newest revision C Edge-EC Board will have one notable difference to the older revision B, and Eval Boards. On the Edge revC, the crystal has been swap for an external crystal oscillator module. Same frequency (20 MHz) but the two %CC bits will change from %10 (15 pF loading) to %01 (no loading).
@RossH
There are a couple things I couldn’t find in the docs:
Is there a way to set the P2 clock to an arbitrary value?
Is there a way to do in-line assembly? Think the answer is no, but want to make sure.
Think I found something in SpinC's readme: 5. Use the non-standard "PASM()" function to include PASM instructions inline in a C program.
This is not in the main manual, right? Does this only apply to P1?
Also, can you verify that native mode is the same as hubexec? I think it is but want to make sure. I also think this is the default. Please tell me if that’s wrong.
@RossH Trying to get VGA working...
The docs and the driver say the vga basepin is defined here: It is configured by setting the following values in Catalin_Plugins.inc (note typo in filename in Catalina_HMI_Plugin_VGA.spin2).
but, it actually looks like this is defined in Catalina_Platforms.inc
It's looking like the most straightforward way to include a P2 assembly driver is to use SpinC on it and then invoke with coginit.
Is this true? Is there an example on how to do this for P2?
The SpinC readme is a bit confusing as to what applies to P2 and what doesn't...
I see this line: "In particular, the SPIN demos are not currently supported on the Propeller 2."
And then this: "build_all P2_EVAL"
Not sure what this means...
Ok, finally got VGA working...
This was the main clue, from ex_vga.c: "catalina -p2 -lci -C P2_EVAL -C HIRES_VGA -C COLOR_8 test_vga.c "
But, this doesn't work as is because:
1. Looks like test_vga.c was renamed ex_vga.c
2. Got warning that need faster clock, so added -C MHZ_260 to command line
Now, having it working in Geany by making a new project with these settings:
You can either define your own macro or write your own function to do it, but I will add a version to Catalina's library. Is there a particular reason to use the "FLTL" instruction Spin seems to use, versus the "DIRL" instruction that the 8 port serial port driver uses? Ditto with DIRH and DRVH.
That is, should I change the 8 port serial driver version?
@Rayman said:
@RossH
There are a couple things I couldn’t find in the docs:
Is there a way to set the P2 clock to an arbitrary value?
Is there a way to do in-line assembly? Think the answer is no, but want to make sure.
Think I found something in SpinC's readme: 5. Use the non-standard "PASM()" function to include PASM instructions inline in a C program.
This is not in the main manual, right? Does this only apply to P1?
Also, can you verify that native mode is the same as hubexec? I think it is but want to make sure. I also think this is the default. Please tell me if that’s wrong.
Yes, the PASM() function can be used on the P2. See the README.TXT and examples in demos\inline_pasm.
And yes, NATIVE mode is the same as HubExec and is now the default on the Propeller 2.
There are no C function to set the clock mode or frequency (you can fetch them but not change them). You can only do this in Catalina_platforms.inc, and it happens at initialization time. The main reason for this is that changing the clock run time breaks too many things - e.g. nearly all the driver plugins, because they would not know about the clock change. However, it does occur to me that it might be useful to add this capability for deeply embedded applications that do not use any plugins.
I will think about including this in the next release.
@evanh said:
Just reading the patch notes ... and noted it says the Edge Board has same definition as Eval Board. The newest revision C Edge-EC Board will have one notable difference to the older revision B, and Eval Boards. On the Edge revC, the crystal has been swap for an external crystal oscillator module. Same frequency (20 MHz) but the two %CC bits will change from %10 (15 pF loading) to %01 (no loading).
Thanks. I will probably buy an EDGE board, but I thought the Rev C was not available yet. Someone who already has one might check how Catalina runs on it. Should be a simple matter of changing a couple of lines in Catalina_platforms.inc, but when I checked, I found I am already using the value %01 on all my P2 boards! ...
@Rayman said:
@RossH Trying to get VGA working...
The docs and the driver say the vga basepin is defined here: It is configured by setting the following values in Catalin_Plugins.inc (note typo in filename in Catalina_HMI_Plugin_VGA.spin2).
but, it actually looks like this is defined in Catalina_Platforms.inc
@Rayman said:
It's looking like the most straightforward way to include a P2 assembly driver is to use SpinC on it and then invoke with coginit.
Is this true? Is there an example on how to do this for P2?
The SpinC readme is a bit confusing as to what applies to P2 and what doesn't...
I see this line: "In particular, the SPIN demos are not currently supported on the Propeller 2."
And then this: "build_all P2_EVAL"
Not sure what this means...
None of the Spin examples are supported on the P2. There was no Spin compiler available for the P2 when Catalina was ported to it, and I have not had time to revisit this. The Makefile tells you this if you try and build the examples for the P2, but the message probably gets lost in the noise!
But coginit and its related functions are supported on the P2 (e.g. coginit_C, cogstart_C) and inline PASM is as well. This is the main reason I moved the inline PASM examples from the demos\spinc to a new directory (demos\inline_pasm). I will remove that reference to "build_all P2_EVAL" in demos\spinc - that whole directory is now only intended for the Propeller 1.
There are examples of using coginit (usually via coginit_C and cogstart_C) in various other demo program - e.g. see demos\multicog\dynamic_kernel.c. However, I just noticed there is an error in that program. It should be this ...
/***************************************************************************\
* *
* Dynamic Kernel Demo *
* *
* This program shows how to use the cog function coginit_C (or cogstart_C) *
* to start a dynamic kernel to run a C function. *
* *
\***************************************************************************/
/*
* include the definitions of some useful multi-cog utility functions:
*/
#include "utilities.h"
/*
* set USE_COGSTART to 1 to test _cogstart_C, rather than _coginit_C
*/
#define USE_COGSTART 0
/*
* define the pin to use for output (pin 1 is a LED on the Hybrid or Hydra)
*/
#if defined (__CATALINA_C3)
#define OUTPUT_MASK 0x00008000 // use VGA pin (and dira, outa) on C3
#define _dir _dira
#define _out _outa
#elif defined (__CATALINA_P2_EVAL)
#define OUTPUT_MASK 0x02000000 // use pin 57 (and dirb, outb) on P2_EVAL
#define _dir _dirb
#define _out _outb
#else
#define OUTPUT_MASK 0x00000001 // use pin 1 (and dira, outa) on other platforms
#define _dir _dira
#define _out _outa
#endif
/*
* define a C function to be executed by the dynamic kernel
* (cycles the output pin at a frequency of 1Hz).
*
*/
#if USE_COGSTART
void function(void *not_used) {
#else
void function(void) {
#endif
unsigned mask = OUTPUT_MASK;
unsigned on_off = OUTPUT_MASK;
_dir(mask, mask);
_out(mask, on_off);
while (1) {
_out(mask, on_off);
_waitcnt(_cnt() + _clockfreq()/2);
on_off ^= mask;
}
}
/*
* The main C program - loops forever, starting and stopping
* C function running in a dynamic kernel
*/
int main(void) {
int cog;
unsigned long stack[STACK_SIZE];
wait(1000);
while (1) {
t_string(1, "starting ...\n");
#if USE_COGSTART
cog = _cogstart_C(&function, 0, &stack, STACK_SIZE);
#else
cog = _coginit_C(&function, &stack[STACK_SIZE]);
#endif
if (cog < 0) {
t_string(1, "... failed\n");
}
else {
wait(5000);
t_string(1, "stopping ...\n");
_cogstop(cog);
}
wait(5000);
}
return 0;
}
How does one use a PASM driver?
For example, the VGA drivers? The code is here, right? Catalina_HMI_Plugin_VGA.spin2
How do you get something like that to be included in a C program?
Also, is there a macro to set the clock to arbitrary value? Or, do I need to do inline assembly for that maybe?
How does one use a PASM driver?
For example, the VGA drivers? The code is here, right? Catalina_HMI_Plugin_VGA.spin2
How do you get something like that to be included in a C program?
If your PASM program is a stand-alone driver (which Catalina calls a plugin) then you generally only load it at startup. This is done in Catalina_Plugins.inc for all the existing plugins. The PASM code is the easy part, and does not usually need modification - but you have to rewrite the SPIN code in C. I may look at adding Spin/C interoperability in a future release. It is a matter of finding enough time.
Note that the HMI plugins are not a good place to start - they tend to be more complicated than the other plugins for various historical reasons. The 8 port serial plugin might be a better place to start if you are really interested. Also, it is the one I did most recently, so I can answer questions more easily!
Also, is there a macro to set the clock to arbitrary value? Or, do I need to do inline assembly for that maybe?
There are no macros provided, but you could certainly write some and then use them in your inline PASM - but doing so is likely to break most of the existing plugins. If you tell me why you need to do this I may be able to offer an alternative.
@RossH said:
Thanks. I will probably buy an EDGE board, but I thought the Rev C was not available yet. Someone who already has one might check how Catalina runs on it. Should be a simple matter of changing a couple of lines in Catalina_platforms.inc, but when I checked, I found I am already using the value %01 on all my P2 boards! ...
@RossH said:
I will probably buy an EDGE board ...
Hmmm. Just checked the prices and I guess I won't be buying one after all. The P2 EDGE kit only costs $132.63 but the postage to Australia adds a whopping $181.08!
LOL, @RossH try Mouser instead of direct from Parallax. There is free shipping on orders over $60 AUD and both the P2-EC Edge and mini breakout are currently in stock (but be quick). I think I've just saved you around $300 AUD! You can pay me later. Admittedly it doesn't include a PropPlug and power adapter, cable etc, but I'm assuming you can obtain those locally and/or already have them yourself.
@rogloh said:
LOL, @RossH try Mouser instead of direct from Parallax. There is free shipping on orders over $60 AUD and both the P2-EC Edge and mini breakout are currently in stock (but be quick). I think I've just saved you around $300 AUD! You can pay me later. Admittedly it doesn't include a PropPlug and power adapter, cable etc, but I'm assuming you can obtain those locally and/or already have them yourself.
Thanks, but they only have the Rev B board. Still, I'll give you a free license for Catalina for your trouble!
@ersmith
That approach seemed to almost work for me. Had to add a --p2 option in there, but generated a .h and .c file from "VGA_Simple1a.spin2".
Included them both in a test .c file, "test_spin2cpp.c".
One problem I have is trying to use the structure VGA_Simple1a to pass to VGA_Simple1a_Start().
Catalina gives errors for every way I could think of to use it...
Created a duplicate in the main c code instead and that was accepted, when cast.
But, it doesn't actually work (the VGA output). Maybe need to try something simpler, like a VGA with fixed pin settings, or something even simpler.
However, the generated code is the right size, so maybe this approach can work.
@RossH
Couple things I noticed:
1. Compiling this fairly large code takes ~1 minute
2. Loading the program to P2 takes ~1 minute
Compiling time is one thing that maybe can't be helped, but can Catalina use a 2-stage loader to speed loading?
Another approach that can work is converting the PASM driver from Spin to C using "spin2cpp --ccode".
This looks like an interesting approach. Thanks for pointing it out. This would help enormously with the main part of the work, which is translating the Spin access functions to C. But the other part is that PASM drivers often make fairly arbitrary use of Hub RAM, which may have to be modified to work successfully with the language runtime and the other drivers. They also use various methods for communication between the driver and the main program, whereas Catalina tries to use a common method.
In the early Propeller 1 days I tried to get vrious Propeller users to adopt common standard for memory management and inter-cog communications to help solve such inter-operability issue, but I soon figured out that trying to get any two Propeller developers to agree on anything was worse than herding cats!
@RossH
Couple things I noticed:
1. Compiling this fairly large code takes ~1 minute
2. Loading the program to P2 takes ~1 minute
Compiling time is one thing that maybe can't be helped, but can Catalina use a 2-stage loader to speed loading?
I'll take a look, hopefully later today. One thing I have noticed is that Catalina takes a long time to compile programs under Windows. It is something like 10 times faster under Linux on the same machine. I investigated a little, and I know the problem is with the PASM assembler (p2asm) and not Catalina itself, but I have not investigated any further.
One suggestion is not to use the Optimizer while developing - the Optimizer assembles the program several times during the compilation, and under Windows this can be glacially slow.
For loading, if you don' need to use the serial interface as your HMI, try using a higher baud rate. You should be able to use payload with the option -b460800 with no issues.
@RossH said:
In the early Propeller 1 days I tried to get vrious Propeller users to adopt common standard for memory management and inter-cog communications to help solve such inter-operability issue, but I soon figured out that trying to get any two Propeller developers to agree on anything was worse than herding cats!
That's because we aren't thinking in terms of an OS.
I was recently struggling with finding a standardised way of run-time calculating a new sysclock frequency and mode when there is different crystal frequencies. All prior run-time coding practises just assumed a 20 MHz crystal is present, aka the Eval Boards.
I resolved it in the end by using what Chip has already defined in Spin2 docs. No new convention required. It basically came down to decoding the compiled clockmode_ symbol, combined with its associated clockfreq_ (note the trailing underscores) symbol, to decide on both the input frequency and whether it's a straight crystal or an external oscillator. - https://forums.parallax.com/discussion/comment/1529413/#Comment_1529413
PS: There is one known limitation: It'll go splat if there isn't any clock input on XI pin. That doesn't worry me at this stage. Programs built for running on the internal oscillators, RCFAST/RCSLOW, aren't likely to be using this.
@RossH said:
In the early Propeller 1 days I tried to get vrious Propeller users to adopt common standard for memory management and inter-cog communications to help solve such inter-operability issue, but I soon figured out that trying to get any two Propeller developers to agree on anything was worse than herding cats!
Ross.
Nothing's changed
IMO Flexprop has solved all the problems we had on the P1 with using the same driver for different languages. If you write your driver in Spin2 you can use it with PNUT, PropTool, flexSpin, flex-C and flexBasic.
Also it's no longer necessary to always start a new cog for assembly code, often inline assembly can run in the same cog. And the smartpins also are a kind of standard for drivers, because they are built in in hardware and accessible from all the cogs.
Comments
Found this in Eric's files:
And Chip's Spin2_interpreter.spin2 file:
' ' PINSTART(pins,mode,xval,yval) (8 longs) ' pins_ setq #4-1 'pop parameters, including new top of stack rdlong a,--ptra 'a=top of stack, b=pins, c=mode, d=xval, x=yval fltl b 'reset smart pin(s) wrpin c,b 'set smart pin(s) mode wxpin d,b 'set smart pin(s) x wypin x,b 'set smart pin(s) y drvl b 'enable smart pin(s) _ret_ mov x,a 'set top of stackAs far as I can tell, with compiling C code using FlexC, most built-ins like this are written in pre-compiled Spin. The above Spin source code is the only implimentation code I could find in Eric's files.
Catalina 4.9.1 has been released. See the first post in this thread.
FlexC has:
in its <propeller.h>. This matches Spin2's PINSTART function.
Just reading the patch notes ... and noted it says the Edge Board has same definition as Eval Board. The newest revision C Edge-EC Board will have one notable difference to the older revision B, and Eval Boards. On the Edge revC, the crystal has been swap for an external crystal oscillator module. Same frequency (20 MHz) but the two %CC bits will change from %10 (15 pF loading) to %01 (no loading).
@RossH
There are a couple things I couldn’t find in the docs:
Is there a way to set the P2 clock to an arbitrary value?
Is there a way to do in-line assembly? Think the answer is no, but want to make sure.
This is not in the main manual, right? Does this only apply to P1?
Also, can you verify that native mode is the same as hubexec? I think it is but want to make sure. I also think this is the default. Please tell me if that’s wrong.
@RossH Trying to get VGA working...
The docs and the driver say the vga basepin is defined here:
It is configured by setting the following values in Catalin_Plugins.inc(note typo in filename in Catalina_HMI_Plugin_VGA.spin2).but, it actually looks like this is defined in Catalina_Platforms.inc
It's looking like the most straightforward way to include a P2 assembly driver is to use SpinC on it and then invoke with coginit.
Is this true? Is there an example on how to do this for P2?
The SpinC readme is a bit confusing as to what applies to P2 and what doesn't...
I see this line: "In particular, the SPIN demos are not currently supported on the Propeller 2."
And then this: "build_all P2_EVAL"
Not sure what this means...
Ok, finally got VGA working...
This was the main clue, from ex_vga.c: "catalina -p2 -lci -C P2_EVAL -C HIRES_VGA -C COLOR_8 test_vga.c "
But, this doesn't work as is because:
1. Looks like test_vga.c was renamed ex_vga.c
2. Got warning that need faster clock, so added -C MHZ_260 to command line
Now, having it working in Geany by making a new project with these settings:
This is from the Spin2 interpreter:
fltl b 'reset smart pin(s) wrpin c,b 'set smart pin(s) mode wxpin d,b 'set smart pin(s) x wypin x,b 'set smart pin(s) y drvl b 'enable smart pin(s)Thanks all. First, on the PINSTART issue:
You can either define your own macro or write your own function to do it, but I will add a version to Catalina's library. Is there a particular reason to use the "FLTL" instruction Spin seems to use, versus the "DIRL" instruction that the 8 port serial port driver uses? Ditto with DIRH and DRVH.
That is, should I change the 8 port serial driver version?
Ross.
Thanks Rayman, I will update the example. I knew I would get into trouble renaming all those test programs!
Ross.
Yes, the PASM() function can be used on the P2. See the README.TXT and examples in demos\inline_pasm.
And yes, NATIVE mode is the same as HubExec and is now the default on the Propeller 2.
There are no C function to set the clock mode or frequency (you can fetch them but not change them). You can only do this in Catalina_platforms.inc, and it happens at initialization time. The main reason for this is that changing the clock run time breaks too many things - e.g. nearly all the driver plugins, because they would not know about the clock change. However, it does occur to me that it might be useful to add this capability for deeply embedded applications that do not use any plugins.
I will think about including this in the next release.
Ross.
Thanks. I will probably buy an EDGE board, but I thought the Rev C was not available yet. Someone who already has one might check how Catalina runs on it. Should be a simple matter of changing a couple of lines in Catalina_platforms.inc, but when I checked, I found I am already using the value %01 on all my P2 boards! ...
Can anyone who is more familiar with the clock modes tell me whether I should change this for the P2_EVAL?
Ross.
Yes, a typo. Sorry.
None of the Spin examples are supported on the P2. There was no Spin compiler available for the P2 when Catalina was ported to it, and I have not had time to revisit this. The Makefile tells you this if you try and build the examples for the P2, but the message probably gets lost in the noise!
But coginit and its related functions are supported on the P2 (e.g. coginit_C, cogstart_C) and inline PASM is as well. This is the main reason I moved the inline PASM examples from the demos\spinc to a new directory (demos\inline_pasm). I will remove that reference to "build_all P2_EVAL" in demos\spinc - that whole directory is now only intended for the Propeller 1.
There are examples of using coginit (usually via coginit_C and cogstart_C) in various other demo program - e.g. see demos\multicog\dynamic_kernel.c. However, I just noticed there is an error in that program. It should be this ...
/***************************************************************************\ * * * Dynamic Kernel Demo * * * * This program shows how to use the cog function coginit_C (or cogstart_C) * * to start a dynamic kernel to run a C function. * * * \***************************************************************************/ /* * include the definitions of some useful multi-cog utility functions: */ #include "utilities.h" /* * set USE_COGSTART to 1 to test _cogstart_C, rather than _coginit_C */ #define USE_COGSTART 0 /* * define the pin to use for output (pin 1 is a LED on the Hybrid or Hydra) */ #if defined (__CATALINA_C3) #define OUTPUT_MASK 0x00008000 // use VGA pin (and dira, outa) on C3 #define _dir _dira #define _out _outa #elif defined (__CATALINA_P2_EVAL) #define OUTPUT_MASK 0x02000000 // use pin 57 (and dirb, outb) on P2_EVAL #define _dir _dirb #define _out _outb #else #define OUTPUT_MASK 0x00000001 // use pin 1 (and dira, outa) on other platforms #define _dir _dira #define _out _outa #endif /* * define a C function to be executed by the dynamic kernel * (cycles the output pin at a frequency of 1Hz). * */ #if USE_COGSTART void function(void *not_used) { #else void function(void) { #endif unsigned mask = OUTPUT_MASK; unsigned on_off = OUTPUT_MASK; _dir(mask, mask); _out(mask, on_off); while (1) { _out(mask, on_off); _waitcnt(_cnt() + _clockfreq()/2); on_off ^= mask; } } /* * The main C program - loops forever, starting and stopping * C function running in a dynamic kernel */ int main(void) { int cog; unsigned long stack[STACK_SIZE]; wait(1000); while (1) { t_string(1, "starting ...\n"); #if USE_COGSTART cog = _cogstart_C(&function, 0, &stack, STACK_SIZE); #else cog = _coginit_C(&function, &stack[STACK_SIZE]); #endif if (cog < 0) { t_string(1, "... failed\n"); } else { wait(5000); t_string(1, "stopping ...\n"); _cogstop(cog); } wait(5000); } return 0; }Ross.
@RossH Thanks for your answers.
How does one use a PASM driver?
For example, the VGA drivers? The code is here, right? Catalina_HMI_Plugin_VGA.spin2
How do you get something like that to be included in a C program?
Also, is there a macro to set the clock to arbitrary value? Or, do I need to do inline assembly for that maybe?
If your PASM program is a stand-alone driver (which Catalina calls a plugin) then you generally only load it at startup. This is done in Catalina_Plugins.inc for all the existing plugins. The PASM code is the easy part, and does not usually need modification - but you have to rewrite the SPIN code in C. I may look at adding Spin/C interoperability in a future release. It is a matter of finding enough time.
Note that the HMI plugins are not a good place to start - they tend to be more complicated than the other plugins for various historical reasons. The 8 port serial plugin might be a better place to start if you are really interested. Also, it is the one I did most recently, so I can answer questions more easily!
There are no macros provided, but you could certainly write some and then use them in your inline PASM - but doing so is likely to break most of the existing plugins. If you tell me why you need to do this I may be able to offer an alternative.
Ross.
Yes, change it.
I think it affects the frequency, or maybe it's a stability issue. :shrug:
Hmmm. Just checked the prices and I guess I won't be buying one after all. The P2 EDGE kit only costs $132.63 but the postage to Australia adds a whopping $181.08!
LOL, @RossH try Mouser instead of direct from Parallax. There is free shipping on orders over $60 AUD and both the P2-EC Edge and mini breakout are currently in stock (but be quick). I think I've just saved you around $300 AUD! You can pay me later.
Admittedly it doesn't include a PropPlug and power adapter, cable etc, but I'm assuming you can obtain those locally and/or already have them yourself.
Thanks, but they only have the Rev B board. Still, I'll give you a free license for Catalina for your trouble!
Another approach that can work is converting the PASM driver from Spin to C using "spin2cpp --ccode".
@ersmith
That approach seemed to almost work for me. Had to add a --p2 option in there, but generated a .h and .c file from "VGA_Simple1a.spin2".
Included them both in a test .c file, "test_spin2cpp.c".
One problem I have is trying to use the structure VGA_Simple1a to pass to VGA_Simple1a_Start().
Catalina gives errors for every way I could think of to use it...
Created a duplicate in the main c code instead and that was accepted, when cast.
But, it doesn't actually work (the VGA output). Maybe need to try something simpler, like a VGA with fixed pin settings, or something even simpler.
However, the generated code is the right size, so maybe this approach can work.
@RossH
Couple things I noticed:
1. Compiling this fairly large code takes ~1 minute
2. Loading the program to P2 takes ~1 minute
Compiling time is one thing that maybe can't be helped, but can Catalina use a 2-stage loader to speed loading?
I've attached the files I was trying to use...
Tried out a much simpler .spin2 file and it worked with spin2cpp.
So, think there's hope for this approach...
This looks like an interesting approach. Thanks for pointing it out. This would help enormously with the main part of the work, which is translating the Spin access functions to C. But the other part is that PASM drivers often make fairly arbitrary use of Hub RAM, which may have to be modified to work successfully with the language runtime and the other drivers. They also use various methods for communication between the driver and the main program, whereas Catalina tries to use a common method.
In the early Propeller 1 days I tried to get vrious Propeller users to adopt common standard for memory management and inter-cog communications to help solve such inter-operability issue, but I soon figured out that trying to get any two Propeller developers to agree on anything was worse than herding cats!
Ross.
I'll take a look, hopefully later today. One thing I have noticed is that Catalina takes a long time to compile programs under Windows. It is something like 10 times faster under Linux on the same machine. I investigated a little, and I know the problem is with the PASM assembler (p2asm) and not Catalina itself, but I have not investigated any further.
One suggestion is not to use the Optimizer while developing - the Optimizer assembles the program several times during the compilation, and under Windows this can be glacially slow.
For loading, if you don' need to use the serial interface as your HMI, try using a higher baud rate. You should be able to use payload with the option -b460800 with no issues.
Ross.
Nothing's changed
That's because we aren't thinking in terms of an OS.
I was recently struggling with finding a standardised way of run-time calculating a new sysclock frequency and mode when there is different crystal frequencies. All prior run-time coding practises just assumed a 20 MHz crystal is present, aka the Eval Boards.
I resolved it in the end by using what Chip has already defined in Spin2 docs. No new convention required. It basically came down to decoding the compiled
clockmode_symbol, combined with its associatedclockfreq_(note the trailing underscores) symbol, to decide on both the input frequency and whether it's a straight crystal or an external oscillator. - https://forums.parallax.com/discussion/comment/1529413/#Comment_1529413PS: There is one known limitation: It'll go splat if there isn't any clock input on XI pin. That doesn't worry me at this stage. Programs built for running on the internal oscillators, RCFAST/RCSLOW, aren't likely to be using this.
IMO Flexprop has solved all the problems we had on the P1 with using the same driver for different languages. If you write your driver in Spin2 you can use it with PNUT, PropTool, flexSpin, flex-C and flexBasic.
Also it's no longer necessary to always start a new cog for assembly code, often inline assembly can run in the same cog. And the smartpins also are a kind of standard for drivers, because they are built in in hardware and accessible from all the cogs.
Andy