@cgracey said:
Yes, that could be done, though timing is tight around the S and D muxes, already.
Chip,
A question on the S/D muxes: Do the special instructions like GETQX, RDPIN, GETCT add to those same critical mux times? If so, are they as expensive as a memory mapped special register like INA?
@cgracey said:
Yes, that could be done, though timing is tight around the S and D muxes, already.
Chip,
A question on the S/D muxes: Do the special instructions like GETQX, RDPIN, GETCT add to those same critical mux times? If so, are they as expensive as a memory mapped special register like INA?
Things like GETQX, RDPIN, and GETCT are results, not S/D values, so they go through other sets of muxes that select the instruction results. The final result mux selects from among a few pre-registered mux's that were captured in the prior clock. This reduces the fan-in to a manageable amount of signals, so that they settle before the next clock edge.
Cool. That figures. I did notice the large contrast between the compact instruction set of the Prop1 verses the extensive collection of little and special instructions thrown into the Prop2. The Prop2 feels more like a load-and-store architecture - which is RISC'y in nature anyway.
Chip,
Request for future silicon: Have a WAITNPAT instruction for waiting on the pattern going false. It's a definite need in a state machine to track both transitions of a condition like that. I guess all the WAITxxx instructions could do with a negated counterpart.
PS: I've found I can use JPAT looping on itself to achieve the same effect but obviously it has the jitter and power consumption of looping code.
IMHO the SETPAT+WAITPAT mechanism is somehow broken or at least too complicated. I liked the WAITPEQ of the P1 much more.
The problem is that the event is edge sensitive, not level sensitive. So if the pattern already matches the pin states before the SETPAT+WAITPAT no event is generated at all and WAITPAT waits forever. That special case has to be handled with extra code. This means you need at least 4 or 5 instructions to reliably wait for a pin mask. Busy looping is easier in most cases.
If we will ever have a chance of a new silicon revision we should discuss this problem further.
@ManAtWork said:
IMHO the SETPAT+WAITPAT mechanism is somehow broken ...
Yeah, I've gone around in circles more than once myself. I think the docs have the equality polarity of SETPAT inverted from what the hardware actually performs. So where the docs say:
Set whenever (INA & D) != S after 'SETPAT D/#,S/#' with C=0 and Z=0.
Set whenever (INA & D) == S after 'SETPAT D/#,S/#' with C=0 and Z=1.
Set whenever (INB & D) != S after 'SETPAT D/#,S/#' with C=1 and Z=0.
Set whenever (INB & D) == S after 'SETPAT D/#,S/#' with C=1 and Z=1.
It should say:
Set whenever (INA & D) == S after 'SETPAT D/#,S/#' with C=0 and Z=0.
Set whenever (INA & D) != S after 'SETPAT D/#,S/#' with C=0 and Z=1.
Set whenever (INB & D) == S after 'SETPAT D/#,S/#' with C=1 and Z=0.
Set whenever (INB & D) != S after 'SETPAT D/#,S/#' with C=1 and Z=1.
PS: This is only dawning right now by the way. I haven't been hiding it.
PPS: I have to admit that Pasm is a lot more friendly now with DEBUG() statements littered around as a cheap variable printing method.
Bah, it's weirder than that. You might be right, it is acting like an edge detect ... I'm not getting the expected excessive retrigging you'd expect from a level detect (which is what I'd have thought an equality/inequality would be).
Bah! I must have a serious bug somewhere. Some perfectly unrelated code has gone bonkers now.
Time to make a stand-alone program just for mapping out WAITPAT/JPAT behaviour ...
EDIT: OOOKAY, it's making sense finally! DEBUG() calls are messing with SETPAT ... and SETSEx too I suspect!!!
Right, so SETPAT rules are as per the docs except for it is an edge detect event. Ie: It requires a fresh toggle of the inputs conditions to retrigger.
I'm okay with that. Just have to remember that things like JPAT only work once on an edge trigger.
@evanh said:
Chip,
Request for future silicon: Have a WAITNPAT instruction for waiting on the pattern going false. It's a definite need in a state machine to track both transitions of a condition like that. I guess all the WAITxxx instructions could do with a negated counterpart.
PS: I've found I can use JPAT looping on itself to achieve the same effect but obviously it has the jitter and power consumption of looping code.
When you do the SETPAT instruction, the Z flag sets whether you are waiting for a match (Z=1) or a mismatch (Z=0). From the P2 Silicon doc:
POLLPAT/WAITPAT event flag
Cleared on SETPAT
Set whenever (INA & D) != S after 'SETPAT D/#,S/#' with C=0 and Z=0.
Set whenever (INA & D) == S after 'SETPAT D/#,S/#' with C=0 and Z=1.
Set whenever (INB & D) != S after 'SETPAT D/#,S/#' with C=1 and Z=0.
Set whenever (INB & D) == S after 'SETPAT D/#,S/#' with C=1 and Z=1.
Also cleared on POLLPAT/WAITPAT/JPAT/JNPAT.
@ManAtWork said:
IMHO the SETPAT+WAITPAT mechanism is somehow broken or at least too complicated. I liked the WAITPEQ of the P1 much more.
The problem is that the event is edge sensitive, not level sensitive. So if the pattern already matches the pin states before the SETPAT+WAITPAT no event is generated at all and WAITPAT waits forever. That special case has to be handled with extra code. This means you need at least 4 or 5 instructions to reliably wait for a pin mask. Busy looping is easier in most cases.
If we will ever have a chance of a new silicon revision we should discuss this problem further.
We would definitely review stuff like this if/when we make newer silicon. I think doing a POLLPAT after a SETPAT would be good to clear the event sensor, in case it was set due to configuration.
@evanh said:
Bah! I must have a serious bug somewhere. Some perfectly unrelated code has gone bonkers now.
Time to make a stand-alone program just for mapping out WAITPAT/JPAT behaviour ...
EDIT: OOOKAY, it's making sense finally! DEBUG() calls are messing with SETPAT ... and SETSEx too I suspect!!!
Right, so SETPAT rules are as per the docs except for it is an edge detect event. Ie: It requires a fresh toggle of the inputs conditions to retrigger.
I'm okay with that. Just have to remember that things like JPAT only work once on an edge trigger.
DEBUG shouldn't affect any settings, however it does steal time which could cause an event to be missed. Could this be what you are experiencing?
@cgracey said:
We would definitely review stuff like this if/when we make newer silicon. I think doing a POLLPAT after a SETPAT would be good to clear the event sensor, in case it was set due to configuration.
I think the problem wasn't an event flag already set which could always be cleared with a POLL but instead an event that never happens because the pins are already in the desired state. The event triggers only if there's a change from no pattern match to a match (rising edge), if I remember correctly.
I think, at the moment the piority should be set to finishing the assembler and hardware manuals. The P2 has very little bugs or flaws compared to other micros. It's all no big deal as long as there is good documentation how things actually behave and hopefully some examples that show how the features were intended to be used.
And just my humble opinion... If I had the money to do a new silicon revision I'd try to migrate to a smaller process to reduce die area and power consumption and increase clock frequency (and possibly memory size) instead of adding features. I think things are almost perfect as they are.
@cgracey said:
DEBUG shouldn't affect any settings, however it does steal time which could cause an event to be missed. Could this be what you are experiencing?
Dunno, my first attempt right now to reproduce is not impacting the behaviour. I'd removed all debug() statements from that code and have forgotten the exact config I had used before. I'll have a look back through old copies ...
EDIT: Hmm, you might be right. Since eliminating the debug()s and using my own mailbox memory I've troubleshot and fixed a bunch of logic flaws in my state machine. Just the sort of thing that might have gone spastic from erratic timing.
@ManAtWork said:
I think the problem wasn't an event flag already set which could always be cleared with a POLL but instead an event that never happens because the pins are already in the desired state. The event triggers only if there's a change from no pattern match to a match (rising edge), if I remember correctly.
That is correct. But arguably it's not any flaw, it's just the documentation needs updated to say PAT is edge sensitive rather than level sensitive.
On the other hand a level sensitive version might be handy to have as well. I, like you, had assumed it was level sensitive in the first place. Hence my original request for a negated WAITNPAT.
@evanh said:
Chip,
Request for future silicon: Have a WAITNPAT instruction for waiting on the pattern going false. It's a definite need in a state machine to track both transitions of a condition like that. I guess all the WAITxxx instructions could do with a negated counterpart.
PS: I've found I can use JPAT looping on itself to achieve the same effect but obviously it has the jitter and power consumption of looping code.
When you do the SETPAT instruction, the Z flag sets whether you are waiting for a match (Z=1) or a mismatch (Z=0). From the P2 Silicon doc:
My original request is somewhat defunct now. At the time I was still struggling with SETPAT in other ways. Namely I was still thinking it was level sensitive.
One thing I just thought of, and I don't know if someone mentioned it or not, is to get USB working really well, and get it into the boot code, thus eliminating the need for a FTDI chip or some such usb2serial chip.
@hinv said:
One thing I just thought of, and I don't know if someone mentioned it or not, is to get USB working really well, and get it into the boot code, thus eliminating the need for a FTDI chip or some such usb2serial chip.
Does sound feasible but in reality everyone is using the prop-plug so there is no cost advantage ... and more importantly, quick hack debug would be a pain without the prop-plug.
@hinv said:
One thing I just thought of, and I don't know if someone mentioned it or not, is to get USB working really well, and get it into the boot code, thus eliminating the need for a FTDI chip or some such usb2serial chip.
Does sound feasible but in reality everyone is using the prop-plug so there is no cost advantage ... and more importantly, quick hack debug would be a pain without the prop-plug.
Well, if Parallax's target market are just the people that already own a prop plug, their business is dead. Parallax is big i education. The lower the cost of entry the easier it is to get people to use it.
If your application doesn't use USB and needs all 8 cogs, then you are right, then it would be better to just have an FTDI chip.
Is something wrong with this picture? Yeah, I know it's not an apples 2 apples comparison, as one is a chip and the other is a complete ready to use circuit board, but still, I find this a bit absurd in terms of capabilities. It's a strange world we live in, for sure considering other inversions like the RaspberryPi, the MilkV-Duo, Pi Pico, Ox64, etc. The FTDI chip sells because it does what it needs to so reliably. I'm guessing P2 ROM code can be just as reliable.
@cgracey since you are writing the usb driver, I would love to get your opinion on this. Is an FTDI USB emulator that hard to do in ROM? What would the minimum clock need to be? Can it be made as reliable as an FTDI chip?
For a while parallax JUST sold boards with FTDI and I honestly hated it. First of all it makes every board more expensive and second you need a USB host like a PC. Especially on the p1 I often run out of pins, being able to (re)use 30 and 31 is one part of it, but mostly without FTDI I can use serial out to display on another P1/P2.
Sure If you just have one board a PropPlug is a additional expense, but I have lots of P1/P2 boards and just a couple PropPlugs. As @evanh mentioned just for debug reasons you can use any spare pin to send out some data, so having two connected makes life so much more easy.
Same goes for WIFI plugs or using a espxxx or like me some serial terminal on another P1 having a FTDI stealing two pins is not good.
Another problem with build in FTDI is the reset issue. you plug a thump drive into your PC, USB enumerates and resets the Propeller. with a PropPlug you just leave out the connection of the reset and - no trouble.
@msrobots said:
For a while parallax JUST sold boards with FTDI and I honestly hated it. First of all it makes every board more expensive and second you need a USB host like a PC. Especially on the p1 I often run out of pins, being able to (re)use 30 and 31 is one part of it, but mostly without FTDI I can use serial out to display on another P1/P2.
This would be the best of both worlds. USB built into the boot ROM would only add development costs, if another silicon rev is being done anyways.
Why would USB have to be permanently on those 2 pins?
Sure If you just have one board a PropPlug is a additional expense, but I have lots of P1/P2 boards and just a couple PropPlugs. As @evanh mentioned just for debug reasons you can use any spare pin to send out some data, so having two connected makes life so much more easy.
It is an additional expense for every new user, including students.
Same goes for WIFI plugs or using a espxxx or like me some serial terminal on another P1 having a FTDI stealing two pins is not good.
Another problem with build in FTDI is the reset issue. you plug a thump drive into your PC, USB enumerates and resets the Propeller. with a PropPlug you just leave out the connection of the reset and - no trouble.
@msrobots said:
For a while parallax JUST sold boards with FTDI and I honestly hated it. First of all it makes every board more expensive and second you need a USB host like a PC. Especially on the p1 I often run out of pins, being able to (re)use 30 and 31 is one part of it, but mostly without FTDI I can use serial out to display on another P1/P2.
Sure If you just have one board a PropPlug is a additional expense, but I have lots of P1/P2 boards and just a couple PropPlugs. As @evanh mentioned just for debug reasons you can use any spare pin to send out some data, so having two connected makes life so much more easy.
Same goes for WIFI plugs or using a espxxx or like me some serial terminal on another P1 having a FTDI stealing two pins is not good.
Another problem with build in FTDI is the reset issue. you plug a thump drive into your PC, USB enumerates and resets the Propeller. with a PropPlug you just leave out the connection of the reset and - no trouble.
just my two cents,
Mike
My opinion is very contrary here! Obviously boards can be made and sold with high volume production methods for very attractive prices which contain a USB serial chip. So the cost argument seems to be totally invalid from customer view.
Make it easy for the customer! I never understood, why the Parallax customer must care and pay extra for a prop plug. The need for the single pin is very rare in comparison to the benefit! I never thought, that I would want a esp32 board or one of the others without the usb chip!
The last propeller meeting video is interesting. Parallax seems to have found recently that they can sell their products very much better, if the price is competitive. So perhaps we will see lower cost boards with P1 and with P2 produced in high volume facilities?
If this happens, then it may even make sense to have a new P2usb....
Is something wrong with this picture? Yeah, I know it's not an apples 2 apples comparison, as one is a chip and the other is a complete ready to use circuit board, but still, I find this a bit absurd in terms of capabilities.
The prop plug is not a typical serial link price, but it has a few cents of convenience around RST.
@cgracey since you are writing the usb driver, I would love to get your opinion on this. Is an FTDI USB emulator that hard to do in ROM? What would the minimum clock need to be? Can it be made as reliable as an FTDI chip?
The ROM would need to be larger, and the real question is what is the silicon cost of that USB ?
People are paying $2.25 per COG, when they buy a Prop 2, does the P2-USB manage 6MBd and how many COGs are needed ?
@jmg I think if you were doing USB you might be able to do more than just serial and offer Mass storage and features like drag and drop downloads to a mounted drive like the Raspi Pico does for example so you'd get more bang for your buck. Although I still think for the price a Pico or other small RP2040 board could make a good PropPlug alternative anyway and if you could leverage its own drag and drop capabilities by bundling a P2 image inside a Pico image, that would be very useful. Then you might get drag/drop for free. In such a case you'd just drag and drop a bundled image to the Pico via USB and it then boots up to either download or flash the P2 from its own embedded P2 data "file" and then later communicates with the P2 serially, or simply pass through and behave more like a regular PropPlug for downloading to RAM etc.
You would need a tool to combine the two different MCU images somehow though and bring the necessary 3 pins out to reset and communicate with the P2. Just a random thought. Haven't considered any real-world issues that might arise to limit this, or the complexity of the runtime image needed in the RP2040 (which I've not programmed before).
Those sorts of features can be added to both. For example, Eric has offered the plan9 filesystem over a comport for a couple years now. On the software side, the biggest difference is USB requires a bulky complex bug prone manager layer, a comport doesn't.
@rogloh said:
@jmg I think if you were doing USB you might be able to do more than just serial and offer Mass storage and features like drag and drop downloads to a mounted drive like the Raspi Pico does for example so you'd get more bang for your buck. Although I still think for the price a Pico or other small RP2040 board could make a good PropPlug alternative anyway and if you could leverage its own drag and drop capabilities by bundling a P2 image inside a Pico image, that would be very useful. Then you might get drag/drop for free. In such a case you'd just drag and drop a bundled image to the Pico via USB and it then boots up to either download or flash the P2 from its own embedded P2 data "file" and then later communicates with the P2 serially, or simply pass through and behave more like a regular PropPlug for downloading to RAM etc.
You would need a tool to combine the two different MCU images somehow though and bring the necessary 3 pins out to reset and communicate with the P2. Just a random thought. Haven't considered any real-world issues that might arise to limit this, or the complexity of the runtime image needed in the RP2040 (which I've not programmed before).
Yeah, the RP2040 is pretty ubiquitous, and well known and bare metal. The raspberry pi does higher level stuff, all the way up to running FlexSpin suite. In between there is new crop of little boards that have really good performance, implement USB2.0, and have microSD slots, like the Ox64 and the MilkV Duo, which I was playing with yesterday. It has 65MB of memory, run's linux (for better or worse) is dual core, but one is currently not available, and has a 8051 core built in running up to 300MHz! It's new, so there is not a lot of documentation on it, but it will do over 20MB/sec reading a microSD. This could make a nice little companion processor for USB2.0 connectivity, sdio, and memory if more info is released about that second core. If we could run a high speed protocol between the two at speeds like 100Mb (like @ManAtWork enet) or better yet, just really high speed serial on pins 62 & 63, it would probably be better to use it (or another companion processor) for storage, since you can't really count on specific timings from microSD's anyways. Supposedly the MilkV Duo can also supply 2Amps on it's 3.3V Out line too! https://arace.tech/products/milk-v-duo and enet modules for them at https://spotpear.com/index/study/detail/id/1099.html
We have more serial options than ever before, but having USBserial built into the boot ROM could make adoption easier, since there will be another run of the silicon anyways.
Is something wrong with this picture? Yeah, I know it's not an apples 2 apples comparison, as one is a chip and the other is a complete ready to use circuit board, but still, I find this a bit absurd in terms of capabilities.
The prop plug is not a typical serial link price, but it has a few cents of convenience around RST.
@cgracey since you are writing the usb driver, I would love to get your opinion on this. Is an FTDI USB emulator that hard to do in ROM? What would the minimum clock need to be? Can it be made as reliable as an FTDI chip?
The ROM would need to be larger, and the real question is what is the silicon cost of that USB ?
People are paying $2.25 per COG, when they buy a Prop 2, does the P2-USB manage 6MBd and how many COGs are needed ?
The older CH340 is cheaper again, but it is deprecated as it is slower.
Yes, there are cheaper, faster, better USB2serial options out there, but they are still external hardware requirements. There is a reason why many microcontrollers build in a lot of the external dependencies including USBboot. People want them.
@"Christof Eb." said:
The last propeller meeting video is interesting. Parallax seems to have found recently that they can sell their products very much better, if the price is competitive. So perhaps we will see lower cost boards with P1 and with P2 produced in high volume facilities?
If this happens, then it may even make sense to have a new P2usb....
I don't remember this. Happen to know the time it is in the video?
One feature the PropPlug provides is to prevent parasitic powering of the target microcontroller via the TX/RX pins. Prevents unexpected behavior of the target device whilst it's supposed to be powered-down, rebooting, or in sleep; and aids to prevent possible USB port damage for (typically lower cost) computers (or hubs) that don't provide management of the power rail.
Things like that, and the special PropPlug reset circuit already mentioned, are good reasons for classrooms and industrial developers/users to adopt the PropPlug over simpler lower-cost programmers.
For sure, with hobby and early adopter use these things tend not to matter so much, but just to give a couple reasons where the commodity vs PropPlug programmers differ.
Comments
Chip,
A question on the S/D muxes: Do the special instructions like GETQX, RDPIN, GETCT add to those same critical mux times? If so, are they as expensive as a memory mapped special register like INA?
Things like GETQX, RDPIN, and GETCT are results, not S/D values, so they go through other sets of muxes that select the instruction results. The final result mux selects from among a few pre-registered mux's that were captured in the prior clock. This reduces the fan-in to a manageable amount of signals, so that they settle before the next clock edge.
Cool. That figures. I did notice the large contrast between the compact instruction set of the Prop1 verses the extensive collection of little and special instructions thrown into the Prop2. The Prop2 feels more like a load-and-store architecture - which is RISC'y in nature anyway.
Chip,
Request for future silicon: Have a WAITNPAT instruction for waiting on the pattern going false. It's a definite need in a state machine to track both transitions of a condition like that. I guess all the WAITxxx instructions could do with a negated counterpart.
PS: I've found I can use JPAT looping on itself to achieve the same effect but obviously it has the jitter and power consumption of looping code.
IMHO the SETPAT+WAITPAT mechanism is somehow broken or at least too complicated. I liked the WAITPEQ of the P1 much more.
The problem is that the event is edge sensitive, not level sensitive. So if the pattern already matches the pin states before the SETPAT+WAITPAT no event is generated at all and WAITPAT waits forever. That special case has to be handled with extra code. This means you need at least 4 or 5 instructions to reliably wait for a pin mask. Busy looping is easier in most cases.
If we will ever have a chance of a new silicon revision we should discuss this problem further.
Yeah, I've gone around in circles more than once myself. I think the docs have the equality polarity of SETPAT inverted from what the hardware actually performs. So where the docs say:
It should say:
PS: This is only dawning right now by the way. I haven't been hiding it.
PPS: I have to admit that Pasm is a lot more friendly now with DEBUG() statements littered around as a cheap variable printing method.
Bah, it's weirder than that. You might be right, it is acting like an edge detect ... I'm not getting the expected excessive retrigging you'd expect from a level detect (which is what I'd have thought an equality/inequality would be).
Bah! I must have a serious bug somewhere. Some perfectly unrelated code has gone bonkers now.
Time to make a stand-alone program just for mapping out WAITPAT/JPAT behaviour ...
EDIT: OOOKAY, it's making sense finally! DEBUG() calls are messing with SETPAT ... and SETSEx too I suspect!!!
Right, so SETPAT rules are as per the docs except for it is an edge detect event. Ie: It requires a fresh toggle of the inputs conditions to retrigger.
I'm okay with that. Just have to remember that things like JPAT only work once on an edge trigger.
When you do the SETPAT instruction, the Z flag sets whether you are waiting for a match (Z=1) or a mismatch (Z=0). From the P2 Silicon doc:
POLLPAT/WAITPAT event flag
Cleared on SETPAT
Set whenever (INA & D) != S after 'SETPAT D/#,S/#' with C=0 and Z=0.
Set whenever (INA & D) == S after 'SETPAT D/#,S/#' with C=0 and Z=1.
Set whenever (INB & D) != S after 'SETPAT D/#,S/#' with C=1 and Z=0.
Set whenever (INB & D) == S after 'SETPAT D/#,S/#' with C=1 and Z=1.
Also cleared on POLLPAT/WAITPAT/JPAT/JNPAT.
We would definitely review stuff like this if/when we make newer silicon. I think doing a POLLPAT after a SETPAT would be good to clear the event sensor, in case it was set due to configuration.
DEBUG shouldn't affect any settings, however it does steal time which could cause an event to be missed. Could this be what you are experiencing?
I need to look into the SETPAT / Z issue.
I think the problem wasn't an event flag already set which could always be cleared with a POLL but instead an event that never happens because the pins are already in the desired state. The event triggers only if there's a change from no pattern match to a match (rising edge), if I remember correctly.
I think, at the moment the piority should be set to finishing the assembler and hardware manuals. The P2 has very little bugs or flaws compared to other micros. It's all no big deal as long as there is good documentation how things actually behave and hopefully some examples that show how the features were intended to be used.
And just my humble opinion... If I had the money to do a new silicon revision I'd try to migrate to a smaller process to reduce die area and power consumption and increase clock frequency (and possibly memory size) instead of adding features. I think things are almost perfect as they are.
Dunno, my first attempt right now to reproduce is not impacting the behaviour. I'd removed all debug() statements from that code and have forgotten the exact config I had used before. I'll have a look back through old copies ...
EDIT: Hmm, you might be right. Since eliminating the debug()s and using my own mailbox memory I've troubleshot and fixed a bunch of logic flaws in my state machine. Just the sort of thing that might have gone spastic from erratic timing.
That is correct. But arguably it's not any flaw, it's just the documentation needs updated to say PAT is edge sensitive rather than level sensitive.
On the other hand a level sensitive version might be handy to have as well. I, like you, had assumed it was level sensitive in the first place. Hence my original request for a negated WAITNPAT.
My original request is somewhat defunct now. At the time I was still struggling with SETPAT in other ways. Namely I was still thinking it was level sensitive.
[doh, posted too soon]
Does sound feasible but in reality everyone is using the prop-plug so there is no cost advantage ... and more importantly, quick hack debug would be a pain without the prop-plug.
Well, if Parallax's target market are just the people that already own a prop plug, their business is dead. Parallax is big i education. The lower the cost of entry the easier it is to get people to use it.
If your application doesn't use USB and needs all 8 cogs, then you are right, then it would be better to just have an FTDI chip.
Is something wrong with this picture? Yeah, I know it's not an apples 2 apples comparison, as one is a chip and the other is a complete ready to use circuit board, but still, I find this a bit absurd in terms of capabilities. It's a strange world we live in, for sure considering other inversions like the RaspberryPi, the MilkV-Duo, Pi Pico, Ox64, etc. The FTDI chip sells because it does what it needs to so reliably. I'm guessing P2 ROM code can be just as reliable.
@cgracey since you are writing the usb driver, I would love to get your opinion on this. Is an FTDI USB emulator that hard to do in ROM? What would the minimum clock need to be? Can it be made as reliable as an FTDI chip?
For a while parallax JUST sold boards with FTDI and I honestly hated it. First of all it makes every board more expensive and second you need a USB host like a PC. Especially on the p1 I often run out of pins, being able to (re)use 30 and 31 is one part of it, but mostly without FTDI I can use serial out to display on another P1/P2.
Sure If you just have one board a PropPlug is a additional expense, but I have lots of P1/P2 boards and just a couple PropPlugs. As @evanh mentioned just for debug reasons you can use any spare pin to send out some data, so having two connected makes life so much more easy.
Same goes for WIFI plugs or using a espxxx or like me some serial terminal on another P1 having a FTDI stealing two pins is not good.
Another problem with build in FTDI is the reset issue. you plug a thump drive into your PC, USB enumerates and resets the Propeller. with a PropPlug you just leave out the connection of the reset and - no trouble.
just my two cents,
Mike
This would be the best of both worlds. USB built into the boot ROM would only add development costs, if another silicon rev is being done anyways.
Why would USB have to be permanently on those 2 pins?
It is an additional expense for every new user, including students.
Valid point.
Doug
My opinion is very contrary here! Obviously boards can be made and sold with high volume production methods for very attractive prices which contain a USB serial chip. So the cost argument seems to be totally invalid from customer view.
Make it easy for the customer! I never understood, why the Parallax customer must care and pay extra for a prop plug. The need for the single pin is very rare in comparison to the benefit! I never thought, that I would want a esp32 board or one of the others without the usb chip!
The last propeller meeting video is interesting. Parallax seems to have found recently that they can sell their products very much better, if the price is competitive. So perhaps we will see lower cost boards with P1 and with P2 produced in high volume facilities?
If this happens, then it may even make sense to have a new P2usb....
The prop plug is not a typical serial link price, but it has a few cents of convenience around RST.
More modern examples are like this one, uses a new CH343, which has faster BAUD capability, for US$1.25
https://www.aliexpress.com/item/1005005775551705.html
This one has a plastic case and IDC10 header, for US $2.40 (CH343G6T-EVT is $2.93 at lcsc)
https://www.aliexpress.com/item/1005005325103341.html
or more choices of connector
https://www.waveshare.com/ch343-usb-uart-board.htm
The ROM would need to be larger, and the real question is what is the silicon cost of that USB ?
People are paying $2.25 per COG, when they buy a Prop 2, does the P2-USB manage 6MBd and how many COGs are needed ?
lcsc show
CH343K WCH(Jiangsu Qin Heng) 6MBd ESSOP-10 200+ US$0.6221
CH343G WCH(Jiangsu Qin Heng) 6MBd SOP-16 100+ US$0.6173
The older CH340 is cheaper again, but it is deprecated as it is slower.
@jmg I think if you were doing USB you might be able to do more than just serial and offer Mass storage and features like drag and drop downloads to a mounted drive like the Raspi Pico does for example so you'd get more bang for your buck. Although I still think for the price a Pico or other small RP2040 board could make a good PropPlug alternative anyway and if you could leverage its own drag and drop capabilities by bundling a P2 image inside a Pico image, that would be very useful. Then you might get drag/drop for free. In such a case you'd just drag and drop a bundled image to the Pico via USB and it then boots up to either download or flash the P2 from its own embedded P2 data "file" and then later communicates with the P2 serially, or simply pass through and behave more like a regular PropPlug for downloading to RAM etc.
You would need a tool to combine the two different MCU images somehow though and bring the necessary 3 pins out to reset and communicate with the P2. Just a random thought. Haven't considered any real-world issues that might arise to limit this, or the complexity of the runtime image needed in the RP2040 (which I've not programmed before).
These devices are still pretty cheap here, even in our dollarydoos:
https://core-electronics.com.au/rp2040-zero-a-pico-like-mcu-board-based-on-raspberry-pi-mcu-rp2040-mini-ver-1.html
Those sorts of features can be added to both. For example, Eric has offered the plan9 filesystem over a comport for a couple years now. On the software side, the biggest difference is USB requires a bulky complex bug prone manager layer, a comport doesn't.
Yeah, the RP2040 is pretty ubiquitous, and well known and bare metal. The raspberry pi does higher level stuff, all the way up to running FlexSpin suite. In between there is new crop of little boards that have really good performance, implement USB2.0, and have microSD slots, like the Ox64 and the MilkV Duo, which I was playing with yesterday. It has 65MB of memory, run's linux (for better or worse) is dual core, but one is currently not available, and has a 8051 core built in running up to 300MHz! It's new, so there is not a lot of documentation on it, but it will do over 20MB/sec reading a microSD. This could make a nice little companion processor for USB2.0 connectivity, sdio, and memory if more info is released about that second core. If we could run a high speed protocol between the two at speeds like 100Mb (like @ManAtWork enet) or better yet, just really high speed serial on pins 62 & 63, it would probably be better to use it (or another companion processor) for storage, since you can't really count on specific timings from microSD's anyways. Supposedly the MilkV Duo can also supply 2Amps on it's 3.3V Out line too!
https://arace.tech/products/milk-v-duo and enet modules for them at https://spotpear.com/index/study/detail/id/1099.html
We have more serial options than ever before, but having USBserial built into the boot ROM could make adoption easier, since there will be another run of the silicon anyways.
Yes, there are cheaper, faster, better USB2serial options out there, but they are still external hardware requirements. There is a reason why many microcontrollers build in a lot of the external dependencies including USBboot. People want them.
I don't remember this. Happen to know the time it is in the video?
Cheaper, faster, better options....
Yes, people want them but will these same people also pay for what they want ?
In the end, it's about strategy and return on investment for the company that provides these features to the market. It must make sense to them too.
One feature the PropPlug provides is to prevent parasitic powering of the target microcontroller via the TX/RX pins. Prevents unexpected behavior of the target device whilst it's supposed to be powered-down, rebooting, or in sleep; and aids to prevent possible USB port damage for (typically lower cost) computers (or hubs) that don't provide management of the power rail.
Things like that, and the special PropPlug reset circuit already mentioned, are good reasons for classrooms and industrial developers/users to adopt the PropPlug over simpler lower-cost programmers.
For sure, with hobby and early adopter use these things tend not to matter so much, but just to give a couple reasons where the commodity vs PropPlug programmers differ.