The computer at home has much more trouble with flashing the P2 Eval than the computer at the university. A lot of tries until it managed to flash at last - the same Xubuntu 20.04, but a slower (Ryzen 3600 vs 3700X) CPU.
@ersmith said:
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.
I see the problem on both macOS & RPi4, especially with WiFI uploads, but has also happened with serial... Of course, trying to repro with serial today, I get good uploads Here's the WiFI tests:
macOS results
Flexprop Terminal (I get 3-5 of these before a successful upload):
Opening file 'xbee4transpo
rt.binary'
Downloading file to port 10.0.0.133
ERROR: Download failed
... Again
...Again
...Eventually, I get:
Opening file 'xbee4transpo
rt.binary'
Downloading file to port 10.0.0.133
Download successful!
[ Entering terminal mode. Type Control-] or Control-Z to exit. ]
Compiler output:
"flexspin" -2 -l --tabs=8 -D_BAUD=230400 -O1 --charset=utf8 -I "flexprop/include" -I "flexprop/include/spin" -I "P2ESCode/p2library" "P2ESCode/xbee_transparent/xbee4transport.spin2"
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
Version 5.9.8 Compiled on: Jan 31 2022
xbee4transport.spin2
|-jm_prng.spin2
|-jm_fds_minimal.spin2
|-jm_FullDuplexSerial.spin2
|-|-jm_nstr.spin2
|-jm_ansi.spin2
xbee4transport.p2asm
Done.
Program size is 5276 bytes
Finished at Sat Feb 5 16:34:15 2022
Eric,
I just ran the instructions for installing 5.9.8 again and get the following error: jim@jim-HP-Pavilion-g6-Notebook-PC:~$ cd flexprop jim@jim-HP-Pavilion-g6-Notebook-PC:~/flexprop$ make install/ make: *** No rule to make target 'install/'. Stop.
has the revised makefile not included the changes from post 868 that runs under get clone?
I see a revised Makefile on get hub but
Jim
Thanks again for your help.
I downloaded your latest 5.9.8. Code what was working before now gives me this:
No issue with 5.9.6.
Also is there away to change the terminal background and font colors??
The black with white letters was great.
Thanks.
Martin
@ersmith
Eric,
I replaced the Makefile with the new one on get hub and ran that but no joy. I get an error that "flexprop" is a file not a program when I change to the file $flexprop/flexprop no program found when I start with " cd flexprop, I get $flexprop. then I enter ./flexprop and get the error "flexprop is a file.
what am I doing wrong?
Jim
For this prop ver G info, try changing the uart speed to 921600, and if it doesn't work, try changing the terminal to external. It seems the new loader still needs debugging
@pik33 said:
For this prop ver G info, try changing the uart speed to 921600, and if it doesn't work, try changing the terminal to external. It seems the new loader still needs debugging
I tried the baud change and got nothing.
I am on the P2 edge.
HI
I am new to using a propeller 1.
I have an EEPROM dump. How to translate it into assembler commands for analysis?
_From @MikeGreen:
No, not realistically.
The original program does not exist in the Propeller. The Propeller Tool compiles the program into interpretive code which is quite compact. It's possible to read the EEPROM with another program in RAM and dump the contents of the EEPROM to a PC for example. There is a debugger that is available that can disassemble the information from the EEPROM into Spin interpretive code source, but this is not something that can be recompiled. It could painstakingly be hand translated into Spin, but there are no variable names or method names and the deconstruction is difficult at best. Practically speaking, you can't retrieve it as Spin source, certainly not meaningful Spin source code._
Please start a new thread with this question. It's a bit off topic for this thread.
@ersmith
Eric: Call off the dogs! I finally got 5.9.8 to install. Deleted everything and started over from scratch!
Thanks for all of your good work.
Jim
@pilot0315 Do you get that message every time you run, or just sometimes? Do other programs work, or is it just the hello.spin that's giving problems? Does it happen with the external terminal as well as the internal PST or ANSI terminal?
HI
I am new to using a propeller 1.
I have an EEPROM dump. How to translate it into assembler commands for analysis?
_From @MikeGreen:
No, not realistically.
The original program does not exist in the Propeller. The Propeller Tool compiles the program into interpretive code which is quite compact. It's possible to read the EEPROM with another program in RAM and dump the contents of the EEPROM to a PC for example. There is a debugger that is available that can disassemble the information from the EEPROM into Spin interpretive code source, but this is not something that can be recompiled. It could painstakingly be hand translated into Spin, but there are no variable names or method names and the deconstruction is difficult at best. Practically speaking, you can't retrieve it as Spin source, certainly not meaningful Spin source code._
Please start a new thread with this question. It's a bit off topic for this thread.
I know how to use a soldering iron and a programmer. I have the eeprom file. I sometimes use the IDA Pro & OllyDbg programs. But these programs does not know propeller structure and commands
You recommend the program!
I'm not aware of any program or plug-in that exists that can help translate a P1 eeprom dump to source code. In the years since the P1 was developed, no one has mentioned one. The Spin interpreter in ROM was in fact encrypted and only after a lot of painstaking work by several community members was it decrypted and that was used to push for release of the original source code.
I manually changed commands from proploader to loadp2. Loadp2 works fast and reliable while proploader (1) works several times slower at the same baud rate (2) needs constant baud rate changes from 921600 for load to 2000000 to flash - flashing doesn't work at all at 921600, uploading doesn't work reliable at 2000000, using lower baudrate is very slow. It seems it was too early to change the default loader for a P2.
As the new version doesn't recognize %F, the commands for Linux are now:
HI
I am new to using a propeller 1.
I have an EEPROM dump. How to translate it into assembler commands for analysis?
_From @MikeGreen:
No, not realistically.
The original program does not exist in the Propeller. The Propeller Tool compiles the program into interpretive code which is quite compact. It's possible to read the EEPROM with another program in RAM and dump the contents of the EEPROM to a PC for example. There is a debugger that is available that can disassemble the information from the EEPROM into Spin interpretive code source, but this is not something that can be recompiled. It could painstakingly be hand translated into Spin, but there are no variable names or method names and the deconstruction is difficult at best. Practically speaking, you can't retrieve it as Spin source, certainly not meaningful Spin source code._
Please start a new thread with this question. It's a bit off topic for this thread.
I know how to use a soldering iron and a programmer. I have the eeprom file. I sometimes use the IDA Pro & OllyDbg programs. But these programs does not know propeller structure and commands
You recommend the program!
I'm quite old in this forum, but as a newbee I first looked around and found this forum different from others as there was politeness, modesty and an infinit crowd of people as much helpfull as knowing. So this mood should be conserved. Maybe you think about asking your question once again. And think how to use help.
@ErNa said:
I'm quite old in this forum, but as a newbee I first looked around and found this forum different from others as there was politeness, modesty and an infinit crowd of people as much helpfull as knowing. So this mood should be conserved. Maybe you think about asking your question once again. And think how to use help.
What's the current state of 64 bit integers again?
I've thunk about trying to get the Tremor, the fixed-point Vorbis decoder, to run on P2. A cursory glance reveals that there a few uses of 64 bit types. As far as I can tell, the two main uses are to portably implement math routines (which can by bypassed by implementing them in ASM) and for timestamps, which with some work I guess can be reworked to 32 bit, at the expense of it presumably going off the rails after 596 hours (231 milliseconds).
Full duplex serial on the P2 is a little simpler than it was on the P1. You just need to start a cog to read the data into a buffer and then empty it before it gets full.
Here is a simple example where the ring buffer is 256 bytes and I use character counters so when they get to 255 they start over at 0.
#include <stdio.h>
#include <propeller.h>
#include "serial.h"
#define RXPIN 37
#define TXPIN 36
void doreceive(void *);
unsigned char Buffer[256];
FILE *fds;
unsigned char Head, Tail;
unsigned int Stack[50];
int main(int argc, char** argv)
{
unsigned char data[256];
printf("Starting \n");
fds = serial_open(RXPIN, TXPIN, 115200);
cogstart(doreceive, NULL, Stack, 50);
while (1)
{
if (Head != Tail)
{
readdata(data);
printf(data);
}
_waitms(1000);
}
}
void doreceive(void *par)
{
Head = Tail = 0;
unsigned char data;
while (1)
{
data = serial_rxChar(fds);
Buffer[Head++] = data;
}
}
int readdata(unsigned char *data)
{
int i = 0;
while (Head != Tail)
{
data[i++] = Buffer[Tail++];
}
}
The serial driver I use here is hooked into flex prop so you can use fprintf functions to send formatted serial data if you want.
Thanks I will look at that. I am trying to duplicate my P1 GPS code in prop c and need to use whatever equivalent of fdserial for the input.
I ran into this: https://forums.parallax.com/discussion/comment/1513415#Comment_1513415
Do I have to go through this procedure to try to use your code??
Thanks
Comments
Ok, I figured out that Plan 9 adds ~20kB to executable, so that appears to be why it was coming out so big..
The computer at home has much more trouble with flashing the P2 Eval than the computer at the university. A lot of tries until it managed to flash at last - the same Xubuntu 20.04, but a slower (Ryzen 3600 vs 3700X) CPU.
I see the problem on both macOS & RPi4, especially with WiFI uploads, but has also happened with serial... Of course, trying to repro with serial today, I get good uploads
Here's the WiFI tests:
macOS results
Eric,
I just ran the instructions for installing 5.9.8 again and get the following error:
jim@jim-HP-Pavilion-g6-Notebook-PC:~$ cd flexprop jim@jim-HP-Pavilion-g6-Notebook-PC:~/flexprop$ make install/ make: *** No rule to make target 'install/'. Stop.has the revised makefile not included the changes from post 868 that runs under get clone?
I see a revised Makefile on get hub but
Jim
@ersmith
Thanks again for your help.
I downloaded your latest 5.9.8. Code what was working before now gives me this:
No issue with 5.9.6.
Also is there away to change the terminal background and font colors??
The black with white letters was great.
Thanks.
Martin
@ersmith
Eric,
I replaced the Makefile with the new one on get hub and ran that but no joy. I get an error that "flexprop" is a file not a program when I change to the file $flexprop/flexprop no program found when I start with " cd flexprop, I get $flexprop. then I enter ./flexprop and get the error "flexprop is a file.
what am I doing wrong?
Jim
@ersmith
The code I used to start with was your Hello code.
Is there something I am missing.
Thanks
For this prop ver G info, try changing the uart speed to 921600, and if it doesn't work, try changing the terminal to external. It seems the new loader still needs debugging
HI
I am new to using a propeller 1.
I have an EEPROM dump. How to translate it into assembler commands for analysis?
I tried the baud change and got nothing.
I am on the P2 edge.
_From @MikeGreen:
No, not realistically.
The original program does not exist in the Propeller. The Propeller Tool compiles the program into interpretive code which is quite compact. It's possible to read the EEPROM with another program in RAM and dump the contents of the EEPROM to a PC for example. There is a debugger that is available that can disassemble the information from the EEPROM into Spin interpretive code source, but this is not something that can be recompiled. It could painstakingly be hand translated into Spin, but there are no variable names or method names and the deconstruction is difficult at best. Practically speaking, you can't retrieve it as Spin source, certainly not meaningful Spin source code._
Please start a new thread with this question. It's a bit off topic for this thread.
@ersmith
Eric: Call off the dogs! I finally got 5.9.8 to install. Deleted everything and started over from scratch!
Thanks for all of your good work.
Jim
@ersmith
I have reinstalled 5.9.8 twice and now get this with your hello example
Any ideas?
Thanks
Martin
@pilot0315
I don't see what OS you said you are running?
Jim
@RS_Jim
I am using windows 10 pro. I have full admin rights.
5.9.6 no issues only with 5.9.8
Thanks
@pilot0315 Do you get that message every time you run, or just sometimes? Do other programs work, or is it just the hello.spin that's giving problems? Does it happen with the external terminal as well as the internal PST or ANSI terminal?
@ersmith
PST:
Internal ANSI is intermittant:
Cannot, or don't know how get the external to work with Parallax PST.
I know how to use a soldering iron and a programmer. I have the eeprom file. I sometimes use the IDA Pro & OllyDbg programs. But these programs does not know propeller structure and commands
You recommend the program!
I'm not aware of any program or plug-in that exists that can help translate a P1 eeprom dump to source code. In the years since the P1 was developed, no one has mentioned one. The Spin interpreter in ROM was in fact encrypted and only after a lot of painstaking work by several community members was it decrypted and that was used to push for release of the original source code.
Like I said, "No, not realistically"
I manually changed commands from proploader to loadp2. Loadp2 works fast and reliable while proploader (1) works several times slower at the same baud rate (2) needs constant baud rate changes from 921600 for load to 2000000 to flash - flashing doesn't work at all at 921600, uploading doesn't work reliable at 2000000, using lower baudrate is very slow. It seems it was too early to change the default loader for a P2.
As the new version doesn't recognize %F, the commands for Linux are now:
%D/bin/loadp2 "%B" -l%r -b%r -t -k
%D/bin/loadp2 %P -b%r "@0=%D/board/P2ES_flashloader.bin,@8000+%B" -t -k
There is another problem: "Terminal only" resets the P2
I'm quite old in this forum, but as a newbee I first looked around and found this forum different from others as there was politeness, modesty and an infinit crowd of people as much helpfull as knowing. So this mood should be conserved. Maybe you think about asking your question once again. And think how to use help.
This. A thousand-fold, THIS.
What's the current state of 64 bit integers again?
I've thunk about trying to get the Tremor, the fixed-point Vorbis decoder, to run on P2. A cursory glance reveals that there a few uses of 64 bit types. As far as I can tell, the two main uses are to portably implement math routines (which can by bypassed by implementing them in ASM) and for timestamps, which with some work I guess can be reworked to 32 bit, at the expense of it presumably going off the rails after 596 hours (231 milliseconds).
I don't know about 64 bit, but it would be great to have Ogg Vorbis files playing on the P2.
You can declare them, and pass them to subroutines, but arithmetic on them doesn't work (and initializing them may or may not work).
@ersmith
@anybody
I have been searching for the equivalent of this in FlexProp to use in C:
include "fdserial.h"
Any ideas?
Thanks.
Windows 10
5.9.9 beta
proploader hasn't successfully downloaded once.
P2 Edge mini breakout.
flash switch off, boot pin neither pulled up or down
This seems to work every time. Not 100% certain if I have every command switch perfect:
@pilot0315 ,
Full duplex serial on the P2 is a little simpler than it was on the P1. You just need to start a cog to read the data into a buffer and then empty it before it gets full.
Here is a simple example where the ring buffer is 256 bytes and I use character counters so when they get to 255 they start over at 0.
#include <stdio.h> #include <propeller.h> #include "serial.h" #define RXPIN 37 #define TXPIN 36 void doreceive(void *); unsigned char Buffer[256]; FILE *fds; unsigned char Head, Tail; unsigned int Stack[50]; int main(int argc, char** argv) { unsigned char data[256]; printf("Starting \n"); fds = serial_open(RXPIN, TXPIN, 115200); cogstart(doreceive, NULL, Stack, 50); while (1) { if (Head != Tail) { readdata(data); printf(data); } _waitms(1000); } } void doreceive(void *par) { Head = Tail = 0; unsigned char data; while (1) { data = serial_rxChar(fds); Buffer[Head++] = data; } } int readdata(unsigned char *data) { int i = 0; while (Head != Tail) { data[i++] = Buffer[Tail++]; } }The serial driver I use here is hooked into flex prop so you can use fprintf functions to send formatted serial data if you want.
Mike
PS: code not totally tested.
@iseries
Thanks I will look at that. I am trying to duplicate my P1 GPS code in prop c and need to use whatever equivalent of fdserial for the input.
I ran into this: https://forums.parallax.com/discussion/comment/1513415#Comment_1513415
Do I have to go through this procedure to try to use your code??
Thanks
@pilot0315 ,
Are you trying to do it on P1 or P2? The code I gave you will only work on P2 using flexc.
Here is the library for simpleIDE using fdserial.
Mike