I've done a fairly major overhaul to the P2 detection code. Now after the reset it tries sending the "> P2_Ver" string several times, flushing input and waiting for a response each time. This should make it less sensitive to initial boot timing.
@evanh, you mentioned a problem with 115200 baud. I just tried with 0.026 and loading at the default 961400 and running at 115200 seems to work for me. If you have time could you give it a try on your system?
Without a download specified, old versions of loap2 would just jump, after the reset pulse, straight to starting the terminal without sending any commands. This meant the prop2's auto-bauding hadn't been triggered and was still open to anything, I think.
Maybe, instead of reverting back to exactly that arrangement, when no download file and no user baud specified the user baud could default to same as download baud. EDIT: That way those query commands can be used and the terminal will then suit it.
Without a download specified, old versions of loap2 would just jump, after the reset pulse, straight to starting the terminal without sending any commands. This meant the prop2's auto-bauding hadn't been triggered and was still open to anything, I think.
PS: That's a feature I've used from time to time.
Ah. That's not a use case I had really considered, and raises an interesting question: if there's no download should we even send the reset pulse at all? If loadp2 is just being used as a terminal then perhaps it should just listen on the port and not try to reset the P2 -- that'd be useful for re-connecting to an already downloaded P2.
Although, to be honest, I'm not sure that loadp2 is particularly compelling as a terminal program -- it's pretty bare bones. You might be better served by minicom or something of that sort.
Okay, good opportunity to fit this in with the 100ms timeout then. How about, when there is no download file nor user baud specified, have the user baud default to same as download baud, then start the terminal. And still have the reset and the query commands before the terminal starts. Gives it a unique use.
@evanh, @jmg : the loadp2 discussion has been very productive and useful, but I worry that it may be lost in this thread (which is about fastspin rather than loadp2). So I'm going to open a new thread for loadp2 and we can carry on there, if you don't mind.
Good idea. Maybe a moderator can split the posts about loaders, into that thread too ?
Ah. That's not a use case I had really considered, and raises an interesting question: if there's no download should we even send the reset pulse at all? If loadp2 is just being used as a terminal then perhaps it should just listen on the port and not try to reset the P2 -- that'd be useful for re-connecting to an already downloaded P2.
Can users reset any time ? (Terminals usually have DTR buttons)
Display of the status lines could also be useful.
For now, in the UB3 code, I echo DTR, RTS back on 2 status lines, and change-increment the other 2 bits (RI,DCD), as a simple verifiable signature system without P2 needing to be alive.
Although, to be honest, I'm not sure that loadp2 is particularly compelling as a terminal program -- it's pretty bare bones. You might be better served by minicom or something of that sort.
Yes, for most serious use, users will use a more dedicated terminal program, but since a serial port is open and ready, simple is nice ...
eg I can see class use where a single environment means students have less scope to get lost..
How about, when there is no download file nor user baud specified, have the user baud default to same as download baud, then start the terminal. And still have the reset and the query commands before the terminal starts. Gives it a unique use.
I can see use cases for No-Reset->Terminal, and also Reset to SPI load->Terminal, with no query, and I've found the TAQOZ ability to change clock speed useful too...
I've done a fairly major overhaul to the P2 detection code. Now after the reset it tries sending the "> P2_Ver" string several times, flushing input and waiting for a response each time. This should make it less sensitive to initial boot timing.
Great
That should make it very tolerant of any future user circuits, as well as reducing the time it takes on faster-reset systems.
eg in the UB3 for P2D2, I generate 100us of accurate reset from DTR leading edge, and then only P2 internal delays add to that, so there is no external Reset-RC uncertainty.
PS: Having now watched it on the scope, at 2 Mbaud, there is notable rounding of the waveform of the data from the USB comport on the Eval boards. Single bit times don't flatten at all. That alone is is setting a real limit for max download speed. The prop2 responses are a lot crisper.
The Eval rev1 Schematic shows quite large 10k isolation resistors in both USB_TX and USB_RX lines, those would really need to be much lower, for 2MBd usage.
Does the new Eval use the same value ?
Even 1k has ~3mA contention limit, and 470R will be ~6mA contention.
Just spotted this older question. Here's the back-story to the design....
The 10K's prevent parasitic power in both directions, but mainly from P2 to FTDI, and also ensure default state (pullup) to keep a serial terminal clean. Much lower than 10K doesn't cut the mustard, and all sorts of odd power-switching issues can occur without it (FTDI body diodes). Sure, a buffer or similar would also work, but a resnet and cap pair is pretty simple, and uses parts already in BOM.
For P1 the 10K has been fine, but as you mentioned it limits the max baud which P2 would prefer to exceed. Hence a little series cap was added in RevB to blast through those high-speed edges. Based on the FTDI limit, we checked serial running over 3MBd on RevB and there's no signal deterioration. All nice and sharp.
Comments
@evanh, you mentioned a problem with 115200 baud. I just tried with 0.026 and loading at the default 961400 and running at 115200 seems to work for me. If you have time could you give it a try on your system?
Thanks,
Eric
Without a download specified, old versions of loap2 would just jump, after the reset pulse, straight to starting the terminal without sending any commands. This meant the prop2's auto-bauding hadn't been triggered and was still open to anything, I think.
PS: That's a feature I've used from time to time.
Ah. That's not a use case I had really considered, and raises an interesting question: if there's no download should we even send the reset pulse at all? If loadp2 is just being used as a terminal then perhaps it should just listen on the port and not try to reset the P2 -- that'd be useful for re-connecting to an already downloaded P2.
Although, to be honest, I'm not sure that loadp2 is particularly compelling as a terminal program -- it's pretty bare bones. You might be better served by minicom or something of that sort.
Good idea. Maybe a moderator can split the posts about loaders, into that thread too ?
Display of the status lines could also be useful.
For now, in the UB3 code, I echo DTR, RTS back on 2 status lines, and change-increment the other 2 bits (RI,DCD), as a simple verifiable signature system without P2 needing to be alive.
Yes, for most serious use, users will use a more dedicated terminal program, but since a serial port is open and ready, simple is nice ...
eg I can see class use where a single environment means students have less scope to get lost..
I can see use cases for No-Reset->Terminal, and also Reset to SPI load->Terminal, with no query, and I've found the TAQOZ ability to change clock speed useful too...
Please flag or PM if I've missed or included posts in the wrong place!
Great
That should make it very tolerant of any future user circuits, as well as reducing the time it takes on faster-reset systems.
eg in the UB3 for P2D2, I generate 100us of accurate reset from DTR leading edge, and then only P2 internal delays add to that, so there is no external Reset-RC uncertainty.
Just spotted this older question. Here's the back-story to the design....
The 10K's prevent parasitic power in both directions, but mainly from P2 to FTDI, and also ensure default state (pullup) to keep a serial terminal clean. Much lower than 10K doesn't cut the mustard, and all sorts of odd power-switching issues can occur without it (FTDI body diodes). Sure, a buffer or similar would also work, but a resnet and cap pair is pretty simple, and uses parts already in BOM.
For P1 the 10K has been fine, but as you mentioned it limits the max baud which P2 would prefer to exceed. Hence a little series cap was added in RevB to blast through those high-speed edges. Based on the FTDI limit, we checked serial running over 3MBd on RevB and there's no signal deterioration. All nice and sharp.