FlexProp: a complete programming system for P2 (and P1)

ersmith

@Rayman said:
I'm probably doing something wrong, but the infinite loop blinks at ~200 ms, like it should, when placed before "fopen".
But, it's more like 2000 ms when placed after fopen.
Any idea why that is?

I can't see any reason why it should be, and it isn't on my system. Here's the complete program I'm using:

#include <stdio.h>
#include <propeller2.h>

enum {
    _clkfreq = 210_000_000,
};

int main() {
    int cf = _clockfreq();
    printf("clock freq= %d\n", cf);

    mount("/sd", _vfs_open_sdcard());

    FILE *f;
    f = fopen("/sd/test.dat", "w");
    for (;;) {
        _pinnot(57);
        _waitms(100);
    }
    fclose(f);
}

Rayman

Thanks. I spliced this into the start of a much larger program to troubleshoot something... I'll remove stuff until it behaves...

Rayman

Think I found the issue...
Add this to the end of main():

    for (;;)
    {
        char c = getchar();
        _pinnot(56);
        fputc(c, f);

    }

There is a warning I missed about redefining cf, whatever that's about...

ersmith

@Rayman said:
Think I found the issue...
Add this to the end of main():

  for (;;)
  {
      char c = getchar();
      _pinnot(56);
      fputc(c, f);
      
  }

What is the problem with that loop? Your original bug report was about pin blinking slowing down after fopen(). But clearly if that's the loop you're using, the _pinnot(56) is going to take a variable amount of time: (a) getchar() will wait for a character to be pressed, and (b) fputc() will periodically have to flush data to the SD card.

Is it possible for you to post a complete (compilable) program that shows your problem?

Rayman

Here it is:

ersmith

Thank you @Rayman. That was a very weird bug, and turned out to be a memory overflow caused by a change I made a while back to add an additional argument to _getvfsforfile. I thought I was being clever by adding a new parameter with a default value to the declaration, but in fact the compiler doesn't always notice this and as a result sometimes passes garbage for that parameter, which is then used for writing into memory . But the symptoms depend exactly on what else is in memory and what code is around the fopen(), which made it hard to track down.

It's a nasty bug and doesn't have a simple patch to existing flexspin installations. If you can compile from source you could build a new flexspin from github; that one should have the patch now. Otherwise I hope to have a new release in a few days.

Thanks again,

aaaaaaaargh

Concerning the FlexBasic Chain Function:
Could the CHAIN function somehow be modified or could something similar be done programmatically (in asm ?) to load a new binary from a SPI device (S/F/M/RAM or maybe even EEPROM, in my case an FM25V20 FRAM) instead of mounting an SD Card?
Something like this ChainSPI(pin,,,address, lenght)
Without the whole SD and FAT support this would save some program space, would be nice especially for the P1

Cheers!

Rayman

@ersmith Quick question about the code I posted that showed this bug...
Was I doing anything unusual there with the file system mounting?
Just got around to making the switch to this new way of mounting and wasn't sure if I was doing it right...

ersmith

@aaaaaaaargh said:
Concerning the FlexBasic Chain Function:
Could the CHAIN function somehow be modified or could something similar be done programmatically (in asm ?) to load a new binary from a SPI device (S/F/M/RAM or maybe even EEPROM, in my case an FM25V20 FRAM) instead of mounting an SD Card?

I'm adding a "CHAIN #n" directive which lets you chain from anything that has a file handle. If you have an SPI driver that's capable of reading 1 byte at a time with a "recvbyte" method you can do:

dim spi as class using("myspi.spin")
spi.init(whatever parameters it needs)
open SendRecvDevice(nil, @spi.recvbyte, nil) as #3
chain #3

I don't know if this will be practical on P1 (due to memory constraints), but it should work well on P2.

ersmith

@Rayman said:
@ersmith Quick question about the code I posted that showed this bug...
Was I doing anything unusual there with the file system mounting?
Just got around to making the switch to this new way of mounting and wasn't sure if I was doing it right...

It looked OK to me. I don't quite understand what you mean by the "new" way of mounting, though?

aaaaaaaargh

@ersmith said:

I'm adding a "CHAIN #n"

Cool!
That sounds fantastic!

Rayman

My old codes have:

//Pick one or none of these to say where files might come from
#define USE_SD
//#define USE_HOST

To select between uSD and Plan9, a different mount statement, and a different way to specify other uSD pins.
But, the current way is much better.

Would like to add upper flash to the mount options though. I have some old code that uses it with FSRW. Shouldn't be all that hard to make it work with FatFS.

ersmith

I've put FlexProp version 5.9.5 (for Windows) in the usual places. This has the CHAIN #n feature, and the bug fixes mentioned earlier in the thread.

I'm still trying to figure out how to get the MacOS version working with new Mac OS releases. I hope to have a binary for that soon.

Wuerfel_21

@ersmith said:
I'm still trying to figure out how to get the MacOS version working with new Mac OS releases. I hope to have a binary for that soon.

I'll never understand how anyone is willing to put up with MacOS breaking itself every release.

Rayman

This compiles without error but doesn't actually work:

int basepin = 48;
int pTDO = basepin + 2;
int pTDI = basepin + 3;
int pTCK = basepin + 4;
int pTMS = basepin + 5;

Had to do: #define basepin 48
to make it work right....

iseries

@rayman,

I was on the fence when I saw this and thought this is not right.

So I gave it a try to see what code was generated.

int i = 10;
int j = i + 2;
int k = i + 3;

When I type this into Visual Studio Code it response with this error:
expression must have a constant value C/C++(28)

A define is handled by the preprocessor so all is good.

Mike

Rayman

I noticed this JTAG code has some automagical way of telling you which file and what line number a problem is on.
This seems to be how it does it:
#define LIBXSVF_HOST_REPORT_ERROR(_msg) h->report_error(h, __FILE__, __LINE__, _msg)

__FILE__ and __LINE__ must do some black magic...

Wuerfel_21

@Rayman said:
I noticed this JTAG code has some automagical way of telling you which file and what line number a problem is on.
This seems to be how it does it:
#define LIBXSVF_HOST_REPORT_ERROR(_msg) h->report_error(h, __FILE__, __LINE__, _msg)

__FILE__ and __LINE__ must do some black magic...

They just expand to the current file and line. That is, the current file and line where the final macro expansion occurs.

__deets__

I just upgraded to 5.9.5 and discovered that the following code written minutes earlier wouldn't compile anymore:

pub main() | earlier, later
  repeat
    earlier := getct()
    do_something()
    later := getct()
    debug("readblock:", udec(util.timediff(earlier, later)))

It complains in the debug statement about earlier and later being unknown. Now I worked around this by introducing a new local variable td, however I wonder if this is a regression or not?

ersmith

@Rayman said:
This compiles without error but doesn't actually work:

int basepin = 48;
int pTDO = basepin + 2;
int pTDI = basepin + 3;
int pTCK = basepin + 4;
int pTMS = basepin + 5;

Had to do: #define basepin 48
to make it work right....

If that's inside a function it should work fine. At top level it should have thrown an error, but I see it doesn't. I'll add an error for that case.

Rayman

@ersmith said:

@Rayman said:
This compiles without error but doesn't actually work:

int basepin = 48;
int pTDO = basepin + 2;
int pTDI = basepin + 3;
int pTCK = basepin + 4;
int pTMS = basepin + 5;

Had to do: #define basepin 48
to make it work right....

If that's inside a function it should work fine. At top level it should have thrown an error, but I see it doesn't. I'll add an error for that case.

Thanks. I guess I didn’t appreciate that distinction …. Between global and local assignments

ersmith

@deets said:
I just upgraded to 5.9.5 and discovered that the following code written minutes earlier wouldn't compile anymore:

pub main() | earlier, later
  repeat
    earlier := getct()
    do_something()
    later := getct()
    debug("readblock:", udec(util.timediff(earlier, later)))

It complains in the debug statement about earlier and later being unknown. Now I worked around this by introducing a new local variable td, however I wonder if this is a regression or not?

Yes, this is a regression, caused by some new code that tries to print out the string corresponding to the DEBUG expression. It isn't handling arguments inside function calls correctly. For now the work around is to avoid function calls inside DEBUG (e.g. with a temporary). The fix is checked into the github source code now.

Thanks for the bug report,

ersmith

FlexProp 5.9.6 is available now in the usual places. It has a bunch of bug fixes in the compiler (including some significant ones for C struct parsing, and a nasty bug in Spin1 parsing where the compiler would incorrectly handle (a := b) inside another expression if "b" was a function call.

There's also an updated version of the P1 PropLoader tool which supports the Plan9 file system. This is still a bit experimental, and may not be terribly useful except in bytecode mode (since the file system code takes up a lot of space) but it's a step on the way towards making PropLoader support enough of loadp2's feature that we can eventually combine the two programs.

Wuerfel_21

@ersmith said:
There's also an updated version of the P1 PropLoader tool which supports the Plan9 file system. This is still a bit experimental, and may not be terribly useful except in bytecode mode (since the file system code takes up a lot of space) but it's a step on the way towards making PropLoader support enough of loadp2's feature that we can eventually combine the two programs.

Cool plan. Hope proploader's file transfer feature ends up in the combined version. But, like rewritten to not suck ;3 (As-is, it is not really usable for me...)

Rayman

Can things like _pinr() use addpins to read multiple pins at once?
I tried making this line faster:

nib = (_pinr(basepin + 7) << 3) + (_pinr(basepin + 6) << 2) + (_pinr(basepin + 5) << 1) + (_pinr(basepin + 4) << 0);

with this:

nib = _pinr(basepin + 4 + (3 << 6));

But, it doesn't seem to work....

ersmith

@Rayman said:
Can things like _pinr() use addpins to read multiple pins at once?
I tried making this line faster:

nib = (_pinr(basepin + 7) << 3) + (_pinr(basepin + 6) << 2) + (_pinr(basepin + 5) << 1) + (_pinr(basepin + 4) << 0);

with this:

nib = _pinr(basepin + 4 + (3 << 6));

But, it doesn't seem to work....

Try _pinread() instead of _pinr(). _pinr() only works on one pin, _pinread() works with pin fields (but is slower). I probably should rename _pinr() to something like _pinr_single().

AndyProp

A couple of P2 flexbasic questions:

Not sure how to go about these in Basic or even if even if it is possible:

I want to store 2048 bytes as an array called values that is accessible by other cogs:

created by cog zero, all values start as 128, so Values(1..2048 ) ="128"

Then each cog will have a small application running to read from the cog zero created array
cog 1 ThisValue = values(1-100)
cog 2 ThisValue = values(101-200)
cog 3 ThisValue = values(201-300)

These 100s are just a guide as each cog will access a range that will change at runtime.

next
Anyone has a small example of calling an ASM subroutine from a main loop that will toggle a pin 200 times.

ersmith

@AndyProp said:
I want to store 2048 bytes as an array called values that is accessible by other cogs:

created by cog zero, all values start as 128, so Values(1..2048 ) ="128"

You'd do that with:

' declare the array
dim shared as byte values(2048)
' initialize it
for i = 1 to 2048
  values(i) = 128
next i

(You could also statically initialize the array with 128's, but that's a lot of typing ).

Anyone has a small example of calling an ASM subroutine from a main loop that will toggle a pin 200 times.

There are several blinking pin examples in the "samples" subdirectory of FlexProp, including blink1.bas, blink2.bas, and led_server .bas.

pik33

Yes, of course it is possible, while I don't know now how to write it in FlexBasic, it is very easy using Spin.

AndyProp

@ersmith said:

@AndyProp said:
I want to store 2048 bytes as an array called values that is accessible by other cogs:

created by cog zero, all values start as 128, so Values(1..2048 ) ="128"

You'd do that with:

' declare the array
dim shared as byte values(2048)
' initialize it
for i = 1 to 2048
  values(i) = 128
next i

(You could also statically initialize the array with 128's, but that's a lot of typing ).

Anyone has a small example of calling an ASM subroutine from a main loop that will toggle a pin 200 times.

There are several blinking pin examples in the "samples" subdirectory of FlexProp, including blink1.bas, blink2.bas, and led_server .bas.

Hi Eric

I see, so the shared is allowing other cogs to read from the array, I noticed you wrote in the "' initialize it" 1 to 2048, should that need to have also "Option base 1" and ubyte my values being 0 to 255

option base 1

dim shared Values(2048) as ubyte

I had looked at the Led server example with the messages, very useful.

Thank you for your help.