If you add features to loadp2 can you also add the ability to use RTS instead, or concurrent to DTR for reset? Unfortunatly this is not possible yet.
I have showed a possible code here
RTS is normally not affected on open and closing a port, and you don't need the transistor circuit to invert the signal. Also some cheap USB to serial ICs only have a RTS output.
Andy
Who owns loadp2 these days? I think Dave Hein wrote it and I'm using the version from Eric's flexprop repository. Where is the official repository and where should I submit pull requests if I change it?
Thanks. Maybe I'll spend some time moving this feature into loadp2 so the external program isn't necessary. That is the way the older P1 loaders worked.
I'm not sure that moving it into loadp2 would be all that helpful. The current scheme allows for any kind of external storage to be used -- flash memory, SD cards, hyperflash, or whatever -- just by changing the loader program.
Thanks. Maybe I'll spend some time moving this feature into loadp2 so the external program isn't necessary. That is the way the older P1 loaders worked.
I'm not sure that moving it into loadp2 would be all that helpful. The current scheme allows for any kind of external storage to be used -- flash memory, SD cards, hyperflash, or whatever -- just by changing the loader program.
It just seems like having everything bundled together would make it easier. Is there a document that describes using loadp2 for writing programs to flash and SD or is it necessary to use the flexprop GUI and inspect the command lines it used as Jon suggested?
In -CHIP mode, filespec may optionally be multiple files with address
specifiers, such as:
@ADDR=file1,@ADDR=file2,@ADDR+file3
Here ADDR is a hex address at which to load the next file, followed by = or +
If it is followed by + then the size of the file is put in memory followed by
the file data. This feature is useful for loading data that a program wishes
to act on. For example, a VGA program which displays data from $1000 may be
loaded with:
@0=vgacode.bin,@1000=picture.bmp
The main executable code must always be specified first
And above example of using that for programming the EEPROM:
Also, the comments at start of P2ES_flashloader.spin2:
Prop2 Flash loader
Version 1.2 17th January 2019 - ozpropdev
18 Oct 2019 Reengineered the programming bitbashing to resolve an issue that turned out to be a faulty board - Evan H
31 Oct 2019 Modified to use dual smartpins for block reads with DualSPI signalling
17 Nov 2019 Modified to load source program length and then data from $8000
This allows use with loadp2 via:
loadp2 @0=P2ES_flashloader.binary,@8000+someprog.binary
to program an arbitrary binary like "someprog.binary"
Used in loadp2 with permission of the authors.
Writes user code (.obj) and loader into flash.
On P2-ES Eval board "FLASH" switch must be on.
"CODE" is stored in FLASH starting @ $1_0000
First long is code size in bytes.
See end of program for examples of how to include users .obj file.
(or better yet use loadp2 to put the file in memory at
$8000, see above)
Thanks. I didn't even see that subdirectory when I first built loadp2. Anyway, I won't make any changes to loadp2. Sounds like people are happy with it as it is. Also, it seems the main way to use flex is through the IDE and not the individual command line programs so I guess my refusal to do that is making things harder for me.
Thanks. Maybe I'll spend some time moving this feature into loadp2 so the external program isn't necessary. That is the way the older P1 loaders worked.
I'm not sure that moving it into loadp2 would be all that helpful. The current scheme allows for any kind of external storage to be used -- flash memory, SD cards, hyperflash, or whatever -- just by changing the loader program.
It just seems like having everything bundled together would make it easier. Is there a document that describes using loadp2 for writing programs to flash and SD or is it necessary to use the flexprop GUI and inspect the command lines it used as Jon suggested?
The documentation could definitely be better, but there is a board/README.txt that describes the board support programs (like the P2ES_flashloader.spin2 program) and the general mechanism for loading data for programs is described in the top level README.md.
Thanks. Maybe I'll spend some time moving this feature into loadp2 so the external program isn't necessary. That is the way the older P1 loaders worked.
I'm not sure that moving it into loadp2 would be all that helpful. The current scheme allows for any kind of external storage to be used -- flash memory, SD cards, hyperflash, or whatever -- just by changing the loader program.
It just seems like having everything bundled together would make it easier. Is there a document that describes using loadp2 for writing programs to flash and SD or is it necessary to use the flexprop GUI and inspect the command lines it used as Jon suggested?
The documentation could definitely be better, but there is a board/README.txt that describes the board support programs (like the P2ES_flashloader.spin2 program) and the general mechanism for loading data for programs is described in the top level README.md.
Is it really true that you might need a different flasher program for each board? It seems like we could have a concept like propeller-load had of board configurations that would automatically select the right program. That's essentially what the Arduino does so that you can type generic commands and have them customized automatically for different board types. If that's not wanted here that's fine with me. Now that I know how to write to the flash I can build the command into my Makefiles. It just doesn't seem all that user friendly.
Is it really true that you might need a different flasher program for each board? It seems like we could have a concept like propeller-load had of board configurations that would automatically select the right program.
If there are multiple programs, isn't that essentially "having a different flasher program for each board"? Maybe not different for each board, but different for each flash part, anyway. Maybe there could be a generic SPI flasher that would work on most boards; I don't know enough to say whether this would be feasible or how much it might impact performance.
I'm open to suggestions on how to improve all of this. Maybe we could organize things differently; definitely we could document it better. Heck, if you really want to have some of the programs built in to the loadp2 binary that's OK with me too, as long as we can also continue to call external programs. In general I think the "user friendly" part is going to be hidden by an IDE for most users, but making things easier for command line users isn't a bad thing .
Is it really true that you might need a different flasher program for each board? It seems like we could have a concept like propeller-load had of board configurations that would automatically select the right program.
If there are multiple programs, isn't that essentially "having a different flasher program for each board"? Maybe not different for each board, but different for each flash part, anyway. Maybe there could be a generic SPI flasher that would work on most boards; I don't know enough to say whether this would be feasible or how much it might impact performance.
I'm open to suggestions on how to improve all of this. Maybe we could organize things differently; definitely we could document it better. Heck, if you really want to have some of the programs built in to the loadp2 binary that's OK with me too, as long as we can also continue to call external programs. In general I think the "user friendly" part is going to be hidden by an IDE for most users, but making things easier for command line users isn't a bad thing .
The propeller-load program used different cache drivers for different boards and the one used for any particular load was determined by a config file. The cache drivers weren't actually included in the executable. They were pointed to by the config file and it was easy to add new config files for different boards. It didn't use that approach for writing to EEPROM because all known boards did that the same way. In that case, the flasher code was part of propeller-load. Actually, it was part of the P1 ROM. In any case, any modification I might make to loadp2 would not bundle the flash programs into the loadp2 executable. That would make it too difficult to add new flash part types.
I guess there is no point in making any changes to loadp2. I will use the methods others have suggested in this thread. The current behavior of loadp2 seems sufficient for the needs of other P2 programmers. I'm an outlier and I now know how to do what I need to do thanks to suggestions from people here. Thanks!
Comments
I'm not sure that moving it into loadp2 would be all that helpful. The current scheme allows for any kind of external storage to be used -- flash memory, SD cards, hyperflash, or whatever -- just by changing the loader program.
Here's what loadp2 help says:
And above example of using that for programming the EEPROM:
Also, the comments at start of P2ES_flashloader.spin2:
Last time I played around with P2ES_flashloader.spin2 was before Eric had the @ADDR feature in flexspin. So I've learnt new info here too.
The documentation could definitely be better, but there is a board/README.txt that describes the board support programs (like the P2ES_flashloader.spin2 program) and the general mechanism for loading data for programs is described in the top level README.md.
I'm open to suggestions on how to improve all of this. Maybe we could organize things differently; definitely we could document it better. Heck, if you really want to have some of the programs built in to the loadp2 binary that's OK with me too, as long as we can also continue to call external programs. In general I think the "user friendly" part is going to be hidden by an IDE for most users, but making things easier for command line users isn't a bad thing