If you pull a new copy of my github repo you'll find that reset=gpio,17,0 is now the default on the Raspberry Pi.
That's pretty awesome. Thanks. Fits the PropellerHAT workflow well, but I wonder what pins other Pi-based add-ons use? 17 seemed a sensible if slightly arbitrary choice and setting sane defaults on the loader is a far better solution than depending on PropellerIDE to feed in the right parameters- which may vary from device to device.
That's pretty awesome. Thanks. Fits the PropellerHAT workflow well, but I wonder what pins other Pi-based add-ons use? 17 seemed a sensible if slightly arbitrary choice and setting sane defaults on the loader is a far better solution than depending on PropellerIDE to feed in the right parameters- which may vary from device to device.
You can still use the reset=gpio,pin,state option if you want something else. You can even still use reset=dtr or reset=rts if you can find a way to get those to work on the Pi.
Have not had a chance to try it yesterday/today, I just pushed my ODROID C1 review last night, and I am trying to push my Pi 2 B review tomorrow night... then I'll try p1load again
I just pushed a change to write the entire program image in a single call to tx(). This matches how the Propeller Tool does downloads. Unfortunately, that means I can't really report load progress anymore since once I call tx(), everything is in the hands of the OS and I can't measure the transmission progress. Anyway, I'm hoping this might solve Peter's problem.
I . Unfortunately, that means I can't really report load progress anymore since once I call tx(), everything is in the hands of the OS and I can't measure the transmission progress..
If you know the Baud and Pgm Size, you could report to the user an estimated time to complete ?
How does the RaspPi et al handle non standard Baud rates ?
The FTDI/CP210x have appx 1% steps at 115200, allowing users to bump a little for faster downloads. (once they have it stable at 115200, of course)
If you know the Baud and Pgm Size, you could report to the user an estimated time to complete ?
How does the RaspPi et al handle non standard Baud rates ?
The FTDI/CP210x have appx 1% steps at 115200, allowing users to bump a little for faster downloads. (once they have it stable at 115200, of course)
There are constants for the supported baud rates but it seems like you can specify anything you want and just pass a numeric value. I haven't tried non-standard baud rates though.
I just pushed a change to write the entire program image in a single call to tx(). This matches how the Propeller Tool does downloads. Unfortunately, that means I can't really report load progress anymore since once I call tx(), everything is in the hands of the OS and I can't measure the transmission progress. Anyway, I'm hoping this might solve Peter's problem.
I haven't had much time at all to check this but it's still the same problem, only a little different when I check it on the scope. I am seeing about 20ms transmission from the loader, about 22ms further transmission and response simultaneously, a 2ms gap and then further transmission from the loader but no more response from the Prop again. So that part actually looks normal but after the load there is no response back.
Except for the timing at the start this looks the same as when I try BST, it's about 6ms transmission, and 22ms transmission and response, a gap, the rest of the transmission, 240ms gap,then the burst of response over 25ms.
EDIT: hooked up the logic analyser and I can see what's happening better. After reset BST will send bytes F0 4A 25 D5 4A D5 92 95 etc whereas p1load just sends F9 FE FF FE FF FF FF FE FE FF etc.
But this latter handshake pattern is the same as the Prop tool.
EDIT: I can get it to work if I only load a 32K file into a 10MHz units and tell it to run after loading:
peter@peter-L702X-LM17 ~/p1load2 $ ./bin/linux/p1load -r EXPLORER-5-10MHZ.binary
Found propeller version 1 on /dev/ttyUSB0
Loading 'EXPLORER-5-10MHZ.binary' (32400 bytes)
Loading hub memory ... OK
peter@peter-L702X-LM17 ~/p1load2 $
peter@peter-L702X-LM17 ~/p1load2 $ ./bin/linux/p1load EXPLORER-5-10MHZ.binary
Found propeller version 1 on /dev/ttyUSB0
Loading 'EXPLORER-5-10MHZ.binary' (32400 bytes)
Loading hub memory ... Timeout
Those bytes you see BST sending are not part of the loader protocol. I have no idea what they are for. I'm afraid I will be unable to help with this any further without access to the hardware. Do you have a pullup resistor on the Propeller's TX line? Even if you don't want it there permanently, it would be helpful to know if it fixes the problem. This could be similar to the problem people were having with the QuickStart RevA board. However, I'm using a RevA board myself and don't see these problems. Does the Propeller Tool load your program successfully? What about BST? What about propeller-load?
You can still use the reset=gpio,pin,state option if you want something else. You can even still use reset=dtr or reset=rts if you can find a way to get those to work on the Pi.
Interestingly, I tried this and it still reports that it's using GPIO 17 for reset * in addition * to the pin or method specified by -Dreset=, is this intentional? In this instance, GPIO 17 isn't being toggled.
pi@daos ~ $ p1load -Dreset=gpio,16,0
Using GPIO pin 17 as Propeller reset (LOW).
Using GPIO pin 16 as Propeller reset (LOW).
Failed to write gpio16!
error: can't find a port with a propeller chip
It also seems to fail to write a pin on the first attempt- I hate /sys/class/gpio, but it's really the only sane method.
I'll have a dig through the code to see if I can provide more useful input than just reporting weirdness.
Another note, it doesn't deal well with -pAUTO, a parameter that Propeller IDE likes to feed into it when it's got "AUTO" selected as a serial port- presumably this used to work with older versions of p1load, even though it's frankly an absurd way to not specify a port.
If any other IDEs expect that behavior they might misbehave with this p1load also. IMO the IDEs should change, and not p1load.
Interestingly, I tried this and it still reports that it's using GPIO 17 for reset * in addition * to the pin or method specified by -Dreset=, is this intentional? In this instance, GPIO 17 isn't being toggled.
pi@daos ~ $ p1load -Dreset=gpio,16,0
Using GPIO pin 17 as Propeller reset (LOW).
Using GPIO pin 16 as Propeller reset (LOW).
Failed to write gpio16!
error: can't find a port with a propeller chip
It also seems to fail to write a pin on the first attempt- I hate /sys/class/gpio, but it's really the only sane method.
I'll have a dig through the code to see if I can provide more useful input than just reporting weirdness.
Another note, it doesn't deal well with -pAUTO, a parameter that Propeller IDE likes to feed into it when it's got "AUTO" selected as a serial port- presumably this used to work with older versions of p1load, even though it's frankly an absurd way to not specify a port.
If any other IDEs expect that behavior they might misbehave with this p1load also. IMO the IDEs should change, and not p1load.
Yes, it's normal that it prints the information about both pin settings. That should probably be fixed though. In fact, I'm not sure it should be printing anything unless there is an error. As you guessed, -pAUTO is not a legal option. It never was legal in any version of p1load that I created. Someone might have added it though in their own private copy. It isn't in the official repo.
Those bytes you see BST sending are not part of the loader protocol. I have no idea what they are for.
Dummy preamble bytes that the loader is known to ignore, can be useful for a Monostable type Reset circuit.
With that, the first TX edge pulses RST and some timeout after last Rx, RST can pulse again. NO other pins are needed.
( A 3rd trace showing RST timing would be useful.)
Dummy preamble bytes that the loader is known to ignore, can be useful for a Monostable type Reset circuit.
With that, the first TX edge pulses RST and some timeout after last Rx, RST can pulse again. NO other pins are needed.
( A 3rd trace showing RST timing would be useful.)
Is this mechanism used by any Propeller boards? It doesn't seem to be supported by propeller-load or the Propeller Tool.
Is this mechanism used by any Propeller boards? It doesn't seem to be supported by propeller-load or the Propeller Tool.
Not that I know of, but the HW is simple, and it could explain the unusual bytes.
Some user designs may use this feature ( it does save a pin, and eases config), so if you want to replace BST in all use cases, if the bytes 'do no harm', they may be useful to add ?
Yes, it's normal that it prints the information about both pin settings. That should probably be fixed though. In fact, I'm not sure it should be printing anything unless there is an error.
That's a good point, it's quite verbose at the moment!
Yes, it's normal that it prints the information about both pin settings. That should probably be fixed though. In fact, I'm not sure it should be printing anything unless there is an error..
Duplicate messages I would trim, but for any Serial Link SW, where there are a lot of failure points, I like to see good progress reporting, as that helps a lot with diagnostics.
If something will take a few seconds, tell the user that (ideally, how many if you can predict it )
Duplicate messages I would trim, but for any Serial Link SW, where there are a lot of failure points, I like to see good progress reporting, as that helps a lot with diagnostics.
If something will take a few seconds, tell the user that (ideally, how many if you can predict it )
I left the progress reports. All I removed was the message that says what GPIO pin is being used. That should be evident from the command line or from looking at the usage message if you're using the defaults.
As mentioned I haven't had a lot of success with p1load unfortunately although I know it's a work in progress so I am not at all perturbed as I know that you will be fixing bugs and making improvements.
There is nothing special about the variety of boards I have tested this on but certainly the only way I can get it to work under Linux Mint 17 is to load a 32K file and use the -r switch in which case it does not return a timeout (and works). If you saw the two identical operations in my last post you will see that one works and one doesn't, the only difference is the use of the -r switch.
I will try to provide some more feedback but what I will do is find out why one works and one doesn't by examining the digital analyser capture as with this one from BST.
As mentioned I haven't had a lot of success with p1load unfortunately although I know it's a work in progress so I am not at all perturbed as I know that you will be fixing bugs and making improvements.
There is nothing special about the variety of boards I have tested this on but certainly the only way I can get it to work under Linux Mint 17 is to load a 32K file and use the -r switch in which case it does not return a timeout (and works). If you saw the two identical operations in my last post you will see that one works and one doesn't, the only difference is the use of the -r switch.
I will try to provide some more feedback but what I will do is find out why one works and one doesn't by examining the digital analyser capture as with this one from BST.
Thanks Peter. Is BST the only loader you've been able to get to work with your boards? For example, does propeller-load work? I guess you're running under Linux so probably you haven't tried the Propeller Tool.
I just realized something. You say the loader only works if you use the -r option. I guess I've never tried leaving that out. Is it actually useful to load hub memory if you're not going to run the program you just loaded? Or are you using the -e option to write to the EEPROM? If so, I don't think I've ever tried that without also using -r. Maybe there is a bug if -r is not specified. I'll take a look at that tomorrow night. Unfortunately, I have to get up early to catch a flight in the morning and don't have any more time to work on this tonight. Sorry!
Is this the error you were seeing? I guess I now know how to duplicate it and can work on fixing it.
Davids-MacBook-Air:p1load dbetz$ ./bin/macosx/p1load fibo.binary
Found propeller version 1 on /dev/cu.usbserial-DAXLIRBW
Loading 'fibo.binary' (15324 bytes)
Loading hub memory ... Timeout
Thanks,
David
In one of my posts I mentioned that it will work if I use the -r switch which is not a problem to use that all the time. However it didn't work with a 64K file even with the -r switch. But yes, the hub memory timeout is the error I was getting.
In one of my posts I mentioned that it will work if I use the -r switch which is not a problem to use that all the time. However it didn't work with a 64K file even with the -r switch. But yes, the hub memory timeout is the error I was getting.
But the Propeller only has 32k of hub memory. Did you mean to say 33k?
In one of my posts I mentioned that it will work if I use the -r switch which is not a problem to use that all the time. However it didn't work with a 64K file even with the -r switch. But yes, the hub memory timeout is the error I was getting.
Maybe I misunderstood as I thought that this loader would be useful because it could load larger EEPROM images which the Prop tool cannot. For instance if someone wants to install one of my 64K Tachyon binaries then one of the only ways at present is to load a 32K Tachyon with SDFS which can then load the image. Of course I could also load a small Spin program to load a secondary 64K file directly into EEPROM but I want to keep it simple and as one operation.
I will have to reread your posts I guess or perhaps modify your loader to load my 64K bootloader and then continue with loading the 64K target file.
Maybe I misunderstood as I thought that this loader would be useful because it could load larger EEPROM images which the Prop tool cannot. For instance if someone wants to install one of my 64K Tachyon binaries then one of the only ways at present is to load a 32K Tachyon with SDFS which can then load the image. Of course I could also load a small Spin program to load a secondary 64K file directly into EEPROM but I want to keep it simple and as one operation.
I will have to reread your posts I guess or perhaps modify your loader to load my 64K bootloader and then continue with loading the 64K target file.
No, you're correct that I intend to enhance p1load to be able to load larger images. I need to get the standard loader to be reliable though before I start adding additional features. :-)
No, you're correct that I intend to enhance p1load to be able to load larger images. I need to get the standard loader to be reliable though before I start adding additional features. :-)
Understood then and fair enough though I am looking forward to that fast large memory bootloader!
BTW, it seems to me that this bootloader image by default would not really need to know the crystal parameters as we could make some basic assumptions like PLLX8 for instance and then the Prop could autobaud to the incoming synch pattern before accepting the final target. Either that or we can specify in the command line what clock parameters to use that would then be blended in with the bootloader image. The larger EEPROMs support 128 byte programming pages so it's possible to program 25.6K/sec so that a 64K file will take under 3 seconds to load. That would require a minimum baud rate of at least 300K if we include headers and checks which is easily achievable. Personally I find that if you can simply transmit the same packet 3 times (rather than complicated forward ECC) that this solves any small errors and delivers the result without any handshaking fuss or warning bombs.
I just realized why the following command doesn't work:
p1load fibo.binary
Because it doesn't have either -e or -r, it ends up sending the Propeller the command 0 (zero) which means that it should shut down after sending the handshake sequence. It isn't expecting any hub data and doesn't acknowledge it with a checksum verification bit. I should actually flag that as a syntax error. The only allowable commands are:
p1load fibo.binary -r
or
p1load fibo.binary -e
or
p1load fibo.binary -e -r
Leaving out both -e and -r should be flagged as an error.
I've just pushed an update that checks that either -r or-e is specified along with a file to load. I've also checked the image size to make sure it is <= 32k.
Or, it could default to some expected operation. (whichever is most common ?)
We've decided to make it default to -r. So the following rules will apply:
(no option) will default to -r
-r will load hub memory and run the program
-e will load hub memory and flash EEPROM
-e -r will load hub memory, flash EEPROM, and run the program
This translates directly into the commands that are understood by the P1 ROM loader.
Comments
That's pretty awesome. Thanks. Fits the PropellerHAT workflow well, but I wonder what pins other Pi-based add-ons use? 17 seemed a sensible if slightly arbitrary choice and setting sane defaults on the loader is a far better solution than depending on PropellerIDE to feed in the right parameters- which may vary from device to device.
Have not had a chance to try it yesterday/today, I just pushed my ODROID C1 review last night, and I am trying to push my Pi 2 B review tomorrow night... then I'll try p1load again
If you know the Baud and Pgm Size, you could report to the user an estimated time to complete ?
How does the RaspPi et al handle non standard Baud rates ?
The FTDI/CP210x have appx 1% steps at 115200, allowing users to bump a little for faster downloads. (once they have it stable at 115200, of course)
I haven't had much time at all to check this but it's still the same problem, only a little different when I check it on the scope. I am seeing about 20ms transmission from the loader, about 22ms further transmission and response simultaneously, a 2ms gap and then further transmission from the loader but no more response from the Prop again. So that part actually looks normal but after the load there is no response back.
Except for the timing at the start this looks the same as when I try BST, it's about 6ms transmission, and 22ms transmission and response, a gap, the rest of the transmission, 240ms gap,then the burst of response over 25ms.
EDIT: hooked up the logic analyser and I can see what's happening better. After reset BST will send bytes F0 4A 25 D5 4A D5 92 95 etc whereas p1load just sends F9 FE FF FE FF FF FF FE FE FF etc.
But this latter handshake pattern is the same as the Prop tool.
EDIT: I can get it to work if I only load a 32K file into a 10MHz units and tell it to run after loading:
BST LOADER
P1LOAD
Interestingly, I tried this and it still reports that it's using GPIO 17 for reset * in addition * to the pin or method specified by -Dreset=, is this intentional? In this instance, GPIO 17 isn't being toggled.
It also seems to fail to write a pin on the first attempt- I hate /sys/class/gpio, but it's really the only sane method.
I'll have a dig through the code to see if I can provide more useful input than just reporting weirdness.
Another note, it doesn't deal well with -pAUTO, a parameter that Propeller IDE likes to feed into it when it's got "AUTO" selected as a serial port- presumably this used to work with older versions of p1load, even though it's frankly an absurd way to not specify a port.
If any other IDEs expect that behavior they might misbehave with this p1load also. IMO the IDEs should change, and not p1load.
With that, the first TX edge pulses RST and some timeout after last Rx, RST can pulse again. NO other pins are needed.
( A 3rd trace showing RST timing would be useful.)
Some user designs may use this feature ( it does save a pin, and eases config), so if you want to replace BST in all use cases, if the bytes 'do no harm', they may be useful to add ?
That's a good point, it's quite verbose at the moment!
If something will take a few seconds, tell the user that (ideally, how many if you can predict it )
As mentioned I haven't had a lot of success with p1load unfortunately although I know it's a work in progress so I am not at all perturbed as I know that you will be fixing bugs and making improvements.
There is nothing special about the variety of boards I have tested this on but certainly the only way I can get it to work under Linux Mint 17 is to load a 32K file and use the -r switch in which case it does not return a timeout (and works). If you saw the two identical operations in my last post you will see that one works and one doesn't, the only difference is the use of the -r switch.
I will try to provide some more feedback but what I will do is find out why one works and one doesn't by examining the digital analyser capture as with this one from BST.
I just realized something. You say the loader only works if you use the -r option. I guess I've never tried leaving that out. Is it actually useful to load hub memory if you're not going to run the program you just loaded? Or are you using the -e option to write to the EEPROM? If so, I don't think I've ever tried that without also using -r. Maybe there is a bug if -r is not specified. I'll take a look at that tomorrow night. Unfortunately, I have to get up early to catch a flight in the morning and don't have any more time to work on this tonight. Sorry!
Thanks,
David
Is this the error you were seeing? I guess I now know how to duplicate it and can work on fixing it.
Thanks,
David
In one of my posts I mentioned that it will work if I use the -r switch which is not a problem to use that all the time. However it didn't work with a 64K file even with the -r switch. But yes, the hub memory timeout is the error I was getting.
Maybe I misunderstood as I thought that this loader would be useful because it could load larger EEPROM images which the Prop tool cannot. For instance if someone wants to install one of my 64K Tachyon binaries then one of the only ways at present is to load a 32K Tachyon with SDFS which can then load the image. Of course I could also load a small Spin program to load a secondary 64K file directly into EEPROM but I want to keep it simple and as one operation.
I will have to reread your posts I guess or perhaps modify your loader to load my 64K bootloader and then continue with loading the 64K target file.
Understood then and fair enough though I am looking forward to that fast large memory bootloader!
BTW, it seems to me that this bootloader image by default would not really need to know the crystal parameters as we could make some basic assumptions like PLLX8 for instance and then the Prop could autobaud to the incoming synch pattern before accepting the final target. Either that or we can specify in the command line what clock parameters to use that would then be blended in with the bootloader image. The larger EEPROMs support 128 byte programming pages so it's possible to program 25.6K/sec so that a 64K file will take under 3 seconds to load. That would require a minimum baud rate of at least 300K if we include headers and checks which is easily achievable. Personally I find that if you can simply transmit the same packet 3 times (rather than complicated forward ECC) that this solves any small errors and delivers the result without any handshaking fuss or warning bombs.
(no option) will default to -r
-r will load hub memory and run the program
-e will load hub memory and flash EEPROM
-e -r will load hub memory, flash EEPROM, and run the program
This translates directly into the commands that are understood by the P1 ROM loader.