The tab setting change appears to have fixed the problem in FlexProp.
I do have a question with the Proptool 2.6.2
I am trying to receive data asynchronous from a gps. I did it fine in Prop C on the P1. Trying in P2 Spin but I cannot get the rx to work with the jmfullduplexserial. Attempting to use simple serial in a second cog for receiving and pass the data as my next move. But for simplicity launching FDS twice with two different nick names should work. The rx in the jm version does not seem to work.
Any suggestions.
Thanks
Martin
This isn't a good place to ask questions about Proptool, as it's focused specifically on Flexprop and the people who know the most about Proptool may not be reading. I'd start a different thread to ask about your serial problems. Include as much detail as you can (ideally the code)! Saying "I cannot get the rx to work" is kind of like saying "I can't get my airplane to take off"; there's not nearly enough information there to diagnose the problem. What kind of airplane is it? Does the engine start? Are there warning lights of any sort? Can the plane taxi? There are so many questions... ideally you would take us out to the plane and show us the problem (i.e. share the code) so we can see exactly what you're trying.
So my suggestion is: start a new thread, post your code there and what you're seeing (any messages from the compiler, behavior when you try to run, etc.).
There's some strange coding style giving me trouble, converting code from Arduino..
void SetHeight(int height) {
height = height;
}
So, there's a global variable called height and local variable with same name.
I don't know how the Arduino compiler figures out which one to use but FlexProp C doesn't seem to get it the same way...
@Rayman said:
There's some strange coding style giving me trouble, converting code from Arduino..
void SetHeight(int height) {
height = height;
}
So, there's a global variable called height and local variable with same name.
I don't know how the Arduino compiler figures out which one to use but FlexProp C doesn't seem to get it the same way...
I think that's just... Not a thing that actually works? Like, you sure the code is good to begin with?
@Wuerfel_21 It's from Seeed Studio Github for 2.7" E-Ink display. I'm pretty sure it works (somehow).
@ersmith Maybe you don't have time for this, but this code is doing something I don't understand...
I'm telling it the height and width variable settings with Paint() and also SetWidth() and SetHeight() in the Demo() function in 3Color_EInk.c.
But, it seems to be just ignoring that and somehow getting the value of the full screen resolution (176x264).
This code is using a smaller than full screen buffer because the Arduino doesn't have enough ram for full screen buffer (1 bit per pixel).
By making the buffer bigger, I made it not crash and it actually works, but not how it's supposed to.
Anyway, next job is to actually ask for full screen buffer, so maybe it doesn't matter.
But, it's some really strange behavior...
Update: Okay, turns out it wasn't actually making a new binary when all the .c files were on the build line.
Moved them back as #include and now it works...
Ok, figured out it wasn't actually making a new binary, even though it said it was...
This is the command line:
C:\FlexProp\bin\flexspin.exe -2 -L C:\FlexProp\include epdif.c epd2in7b.c epdpaint.c 3Color_EInk.c
I was previously using #include on the other .c files, guess I'll switch back to that...
Ok, maybe this was operator error... I just noticed there's an epdif.binary.
Guess the first file decides the output filename... Thought it was the last one...
@Rayman said:
Ok, maybe this was operator error... I just noticed there's an epdif.binary.
Guess the first file decides the output filename... Thought it was the last one...
It is the first one. But if you want to be sure, you can add "-o SomeOutputFileName.binary" to the command line to explicitly specify what output name you want.
Is everything else sorted out? I kind of lost track of the comments above.
@pik33 said:
Is it possible - in Linux environment - to prevent running more than one copy of Flexprop at once?
I don't think there's any easy way to do that. Actually it might be useful to run multiple copies, if you have multiple propellers (e.g. one for the P2 and one for the P1).
mount(), like most disk functions, returns 0 on success and a negative number on failure. In the latter case more detail on the error is put in "errno"; the file <errno.h> has a list of defines for error conditions.
I've released FlexProp 5.9.8. This has some major changes, particularly in the GUI, and so it probably has a few rough edges. But the benefits are substantial too, I think. The new GUI features include:
An option to use a default built in terminal (either ANSI or PST compatible) instead of the external terminal (which is still an option, but the internal ANSI terminal is the default).
Preliminary support for the Spin2 TERM and PLOT windows. BITMAP and SCOPE will be coming soon, I hope, with the rest of the DEBUG windows to follow eventually.
Support for programming P2s over WiFi, based on the proploader changes made by @VonSzarvas This does mean that proploader is now the default terminal program, rather than loadp2, which again is a pretty big change (although loadp2 is still included in the distribution, so it's possible to switch back to it).
Default tab width is now 8 rather than 4, for backwards compatibility with Spin programs
The config file for this release is called ".flexprop6.config" rather than ".flexprop.config", so it can co-exist with older releases; but it means that FlexProp 5.9.8 will start fresh without any of your font and other settings.
The compiler also has a number of changes, including:
Added some more bit-banging optimizations (e.g. bith/bitl -> bitc)
Added a new optimization for simple FOR loops with constant bounds
Added special function optimizations for pinread/pinwrite
Added SIZEOF operator to BASIC
Added BITREV function to BASIC
Added ALIAS, DECLARE, EXTERN, LINE, and LIB keywords to BASIC
Added support for DLY() to default -g debugging
Added #pragma ignore_case directive to the preprocessor
Added DECLARE ALIAS to BASIC
Allowed printing of pointers in BASIC
Changed default runtime tests to use P2 instead of P1
Fixed a few missing definitions in <propeller.h>
Fixed a problem with SendRecvDevice() in BASIC
Fixed an incorrect optimization for loops containing GOSUB
Fixed multiple args in DEBUG() statements with -gbrk
Fixed a problem with extern declarations in C not working in .o files
Fixed in bug in mis-detecting use of result values in bytecode output
Fixed a nasty bug for functions with more than 99 local registers used
Fixed a bug in DIR$() in subdirectories of SD cards
Fixed printing of values passed by reference
Improved C++ compatibility for class functions, including supporting "static" in classes and declarations of functions outside the class
Made RESULT no longer a reserved word in Spin2, should fix a number of bugs
Optimized local variable push/pull (thanks Ada)
Reduced number of temporary registers needed by the compiler
Preliminary support for the Spin2 TERM and PLOT windows. BITMAP and **SCOPE **will be coming soon, I hope, with the rest of the DEBUG windows to follow eventually.
@Rsadeika said:
In my Win 10 Pro setup, the new flexprop GUI 'Compile and flash', is not writing to flash.
Ray
What is it doing? Can you give us any more information about your setup -- are you using WiFi or Serial, Internal or External terminal, are there any messages printed? Can you run ordinary programs? What are the DIP switch settings on your board (and what kind of P2 board are you using)? Forgetting to set the DIP switches is a common reason for flash failures.
I have some glitches in serial terminal in Linux (Xubuntu 20.04):
2 Mbps is "not stable" - sometimes uploads fast, sometimes much slower
debug(udec(something)) where this something is fast displays garbage on the internal terminal while on the external terminal it works. Also, while the internal terminal works in most cases uploading and flashing programs, it can sometimes fail to flash. The workaround, if it happens - as in the debug - was to use the external terminal.
I'm also seeing issues with the prop loader. I realize it's probably not a flexprop complier problem, but proploader is pretty obtuse.
It claims download was successful, but the P2 only starts up maybe 1 in 5 attempts. The last thing in the terminal window says is that it found a revision G prop 2.
I'm using the older P1 era style prop plug on the edge mini breakout with Windows 10, which wasn't a problem before. Baud rate doesn't seem to affect the odds as I've tried all of them from the flexprop gui drop down menu. And then pressed the "compile and run on P2" button for 10 trials in a row with a simple blink program. It actually started in about 2 to 4 times, out of 10 tries.
@whicker said:
I'm also seeing issues with the prop loader. I realize it's probably not a flexprop complier problem, but proploader is pretty obtuse.
It claims download was successful, but the P2 only starts up maybe 1 in 5 attempts. The last thing in the terminal window says is that it found a revision G prop 2.
I'm seeing similar problems with the most recent proploader, as well... I get 2-4 failed uploads before a successful upload to the P2. That's for a "Compile & Run on P2"... And, "Compile & Flash", although stating a successful upload, results in a reset of the P2 and it runs previously saved code from flash (i.e. the new binary does NOT get uploaded). This has been true for both wired (USB) and WiFi uploads.
My problem with PropLoader is that it it does not support reset by RTS.
Just toggle RTS together with DTR for a reset, no extra commandline switch needed.
@whicker said:
I'm also seeing issues with the prop loader.
It claims download was successful, but the P2 only starts up maybe 1 in 5 attempts. The last thing in the terminal window says is that it found a revision G prop 2.
Same issue here. Running under Win10 with a Rev B Eval board. I have tried all 16 combos of dip switches on the board with no joy. My interim solution is to use the old loader from 3 versions of FlexProp ago. This gets me back to working again, but the GUI is unresponsive while the terminal window is open (ie, the terminal window is modal to the GUI window).
Same issue here under MacOS with a mini breakout board with either a direct serial connection or via WiFi. Most times I try to program into flash, it claims download was successful, but the flash still contains the previous version. I can Compile & Run
Flexprop 5.9.8 install issues.
followed the script exactly to make 5.9.8 on a linux Mint vr 20 . Ran the makefile, made the new flexprop DIR but it contains no flexprop. type cd flexprop and it goes to the directory. type "./flexprop" get "no such file or directory. I was sort of looking to trying out the debug commands.
Jim
If you're having a problem with FlexProp, particularly with serial downloads, please let me know the operating system you're using. Mac, Linux, and Windows all use different serial drivers, and it's hard to debug these because they're timing dependent.
As for flash not working, of course it does here for me (on all of my OSes) . I have heard that what is programmed into the flash might matter, e.g. if it uses serial or SPI pins then there might be an issue. I haven't been able to confirm this, but it's worth investigating -- if you can change what you have in your flash, and/or report what it is, that might be helpful.
@Ariba said:
My problem with PropLoader is that it it does not support reset by RTS.
Just toggle RTS together with DTR for a reset, no extra commandline switch needed.
I believe that adding the command line option "-D reset=rts" makes proploader use RTS reset instead of DTR.
@RS_Jim said:
Flexprop 5.9.8 install issues.
followed the script exactly to make 5.9.8 on a linux Mint vr 20 . Ran the makefile, made the new flexprop DIR but it contains no flexprop. type cd flexprop and it goes to the directory. type "./flexprop" get "no such file or directory. I was sort of looking to trying out the debug commands.
What errors did you get when you ran "make install"? If it was:
/bin/sh: 1: tclsh: not found
you can fix this by replacing the two instances of the word "tclsh" in the Makefile with "tclsh8.6". For some reason Linux Mint does not include an alias for tclsh, but installing tk8.6-dev does install tclsh8.6.
@Ariba said:
My problem with PropLoader is that it it does not support reset by RTS.
Just toggle RTS together with DTR for a reset, no extra commandline switch needed.
I believe that adding the command line option "-D reset=rts" makes proploader use RTS reset instead of DTR.
Thanks Eric. That works!
I have no problems with downloads on a newer Win10 computer.
@ersmith Where should I ask questions about using FlexProp in C with P1 (actually P1V)?
Anyway, I was testing out this 3-color epaper C code with P1V and was amazed that it compiled without changes. But, was too big, so had to cut a lot of fonts...
Still, the size seems to be much bigger than it should be. I'm wondering if there's some way to figure out what is using up all the space...
Also, I was getting gibberish in the terminal until I realized that my P1V has a 6.25 MHz fake crystal. The manual didn't really help in this regard as it just mentions using the Spin clkset() function, which I don't think applies in this case. Anyway, did this to fix it:
uint32_t * p=0;
*p=100000000;
Maybe there's a prettier way? This is just writing the 100 MHz clock frequency to the first long in hub memory...
Comments
This isn't a good place to ask questions about Proptool, as it's focused specifically on Flexprop and the people who know the most about Proptool may not be reading. I'd start a different thread to ask about your serial problems. Include as much detail as you can (ideally the code)! Saying "I cannot get the rx to work" is kind of like saying "I can't get my airplane to take off"; there's not nearly enough information there to diagnose the problem. What kind of airplane is it? Does the engine start? Are there warning lights of any sort? Can the plane taxi? There are so many questions... ideally you would take us out to the plane and show us the problem (i.e. share the code) so we can see exactly what you're trying.
So my suggestion is: start a new thread, post your code there and what you're seeing (any messages from the compiler, behavior when you try to run, etc.).
@ersmith
Thanks for the suggestion. I will do that. I like your airplane analogy.
Is it possible - in Linux environment - to prevent running more than one copy of Flexprop at once?
There's some strange coding style giving me trouble, converting code from Arduino..
void SetHeight(int height) { height = height; }So, there's a global variable called height and local variable with same name.
I don't know how the Arduino compiler figures out which one to use but FlexProp C doesn't seem to get it the same way...
I think that's just... Not a thing that actually works? Like, you sure the code is good to begin with?
@Wuerfel_21 It's from Seeed Studio Github for 2.7" E-Ink display. I'm pretty sure it works (somehow).
@ersmith Maybe you don't have time for this, but this code is doing something I don't understand...
I'm telling it the height and width variable settings with Paint() and also SetWidth() and SetHeight() in the Demo() function in 3Color_EInk.c.
But, it seems to be just ignoring that and somehow getting the value of the full screen resolution (176x264).
This code is using a smaller than full screen buffer because the Arduino doesn't have enough ram for full screen buffer (1 bit per pixel).
By making the buffer bigger, I made it not crash and it actually works, but not how it's supposed to.
Anyway, next job is to actually ask for full screen buffer, so maybe it doesn't matter.
But, it's some really strange behavior...
Update: Okay, turns out it wasn't actually making a new binary when all the .c files were on the build line.
Moved them back as #include and now it works...
Ok, figured out it wasn't actually making a new binary, even though it said it was...
This is the command line:
C:\FlexProp\bin\flexspin.exe -2 -L C:\FlexProp\include epdif.c epd2in7b.c epdpaint.c 3Color_EInk.c
I was previously using #include on the other .c files, guess I'll switch back to that...
Ok, maybe this was operator error... I just noticed there's an epdif.binary.
Guess the first file decides the output filename... Thought it was the last one...
It is the first one. But if you want to be sure, you can add "-o SomeOutputFileName.binary" to the command line to explicitly specify what output name you want.
Is everything else sorted out? I kind of lost track of the comments above.
Yes, all good now
Thanks
I don't think there's any easy way to do that. Actually it might be useful to run multiple copies, if you have multiple propellers (e.g. one for the P2 and one for the P1).
Does mount() return anything that tells you if it worked?
Maybe this?
/* Results of Disk Functions /
typedef enum {
RES_OK = 0, / 0: Successful /
RES_ERROR, / 1: R/W Error /
RES_WRPRT, / 2: Write Protected /
RES_NOTRDY, / 3: Not Ready /
RES_PARERR / 4: Invalid Parameter */
} DRESULT;
mount(), like most disk functions, returns 0 on success and a negative number on failure. In the latter case more detail on the error is put in "errno"; the file <errno.h> has a list of defines for error conditions.
I've released FlexProp 5.9.8. This has some major changes, particularly in the GUI, and so it probably has a few rough edges. But the benefits are substantial too, I think. The new GUI features include:
The compiler also has a number of changes, including:
Wowzers. @ersmith has been BUSY! 👍
In my Win 10 Pro setup, the new flexprop GUI 'Compile and flash', is not writing to flash.
Ray
What is it doing? Can you give us any more information about your setup -- are you using WiFi or Serial, Internal or External terminal, are there any messages printed? Can you run ordinary programs? What are the DIP switch settings on your board (and what kind of P2 board are you using)? Forgetting to set the DIP switches is a common reason for flash failures.
I have some glitches in serial terminal in Linux (Xubuntu 20.04):
I'm also seeing issues with the prop loader. I realize it's probably not a flexprop complier problem, but proploader is pretty obtuse.
It claims download was successful, but the P2 only starts up maybe 1 in 5 attempts. The last thing in the terminal window says is that it found a revision G prop 2.
I'm using the older P1 era style prop plug on the edge mini breakout with Windows 10, which wasn't a problem before. Baud rate doesn't seem to affect the odds as I've tried all of them from the flexprop gui drop down menu. And then pressed the "compile and run on P2" button for 10 trials in a row with a simple blink program. It actually started in about 2 to 4 times, out of 10 tries.
I'm seeing similar problems with the most recent proploader, as well... I get 2-4 failed uploads before a successful upload to the P2. That's for a "Compile & Run on P2"... And, "Compile & Flash", although stating a successful upload, results in a reset of the P2 and it runs previously saved code from flash (i.e. the new binary does NOT get uploaded). This has been true for both wired (USB) and WiFi uploads.
version info:
dgately
My problem with PropLoader is that it it does not support reset by RTS.
Just toggle RTS together with DTR for a reset, no extra commandline switch needed.
Andy
Same issue here. Running under Win10 with a Rev B Eval board. I have tried all 16 combos of dip switches on the board with no joy. My interim solution is to use the old loader from 3 versions of FlexProp ago. This gets me back to working again, but the GUI is unresponsive while the terminal window is open (ie, the terminal window is modal to the GUI window).
Same issue here under MacOS with a mini breakout board with either a direct serial connection or via WiFi. Most times I try to program into flash, it claims download was successful, but the flash still contains the previous version. I can Compile & Run
Flexprop 5.9.8 install issues.
followed the script exactly to make 5.9.8 on a linux Mint vr 20 . Ran the makefile, made the new flexprop DIR but it contains no flexprop. type cd flexprop and it goes to the directory. type "./flexprop" get "no such file or directory. I was sort of looking to trying out the debug commands.
Jim
If you're having a problem with FlexProp, particularly with serial downloads, please let me know the operating system you're using. Mac, Linux, and Windows all use different serial drivers, and it's hard to debug these because they're timing dependent.
As for flash not working, of course it does here for me (on all of my OSes)
. I have heard that what is programmed into the flash might matter, e.g. if it uses serial or SPI pins then there might be an issue. I haven't been able to confirm this, but it's worth investigating -- if you can change what you have in your flash, and/or report what it is, that might be helpful.
I believe that adding the command line option "-D reset=rts" makes proploader use RTS reset instead of DTR.
What errors did you get when you ran "make install"? If it was:
you can fix this by replacing the two instances of the word "tclsh" in the Makefile with "tclsh8.6". For some reason Linux Mint does not include an alias for tclsh, but installing tk8.6-dev does install tclsh8.6.
Thanks Eric. That works!
I have no problems with downloads on a newer Win10 computer.
Thanks Eric. I will try that 1st chance I get.
Jim1.
@ersmith Where should I ask questions about using FlexProp in C with P1 (actually P1V)?
Anyway, I was testing out this 3-color epaper C code with P1V and was amazed that it compiled without changes. But, was too big, so had to cut a lot of fonts...
Still, the size seems to be much bigger than it should be. I'm wondering if there's some way to figure out what is using up all the space...
Also, I was getting gibberish in the terminal until I realized that my P1V has a 6.25 MHz fake crystal. The manual didn't really help in this regard as it just mentions using the Spin clkset() function, which I don't think applies in this case. Anyway, did this to fix it:
uint32_t * p=0; *p=100000000;Maybe there's a prettier way? This is just writing the 100 MHz clock frequency to the first long in hub memory...