I wonder if a circuit could be built that turns breaks on the RX pin into a reset signal. Possibly just some kind of transistor and capacitor circuit. That should allow using any cheap USB serial converters that don't have the flow control pins. Though who knows if they support break signalling?
@evanh said:
Christof changed the subject. He wasn't talking about a software solution at all.
Well, yes and no. The argument to use a software solution for usb serial is cost. The software had to be developed and a new chip production run had to be payed for. If this would be done, then a edge board with usb serial would cost 79$ instead of 80$. In my opinion this would not help too much. In my opinion the biggest contribution to the cost of the edge board is, that it is not produced using highly automated large batch methods and also that Parallax tries to get back their investment with a low volume.
I didn't do a good job of explaining that either. The software solution's purpose wasn't really for cost reasons. Hinv used cost as an argument but he really wants to make it a USB only link. One that magically works without knowing how.
I've thought the USB code could reside in cog 7 and emulate the boot ROM when the flow control bits are toggled. The boot ROM is simple enough I don't think there would be any reason to make a special USB loader protocol. I don't know if drag and drop is an actual benefit for the developer. It would be a lot more complicated that USB serial.
Benefits
Much faster transfer speeds
Saves $1 off BOM
Supports other interfaces like audio, mass storage, and human interface device.
Drawbacks
Full USB compliance would be a lot of work, especially the suspend current.
Higher clock speed required for full speed USB, will increase power at startup.
It might be possible to use low speed USB on RCFAST, but low speed does not officially support communication devices.
Standard frequency crystal will be required.
Changing the clock frequency becomes more complicated as the USB cog needs to know the frequency at all times.
@evanh said:
Christof changed the subject. He wasn't talking about a software solution at all.
Well, yes and no. The argument to use a software solution for usb serial is cost.
Not just cost. The potential is ~11Mbaud for booting and then switch to higher than that for host services which are done better & cheaper on other devices like Network, sdcard blocks and general file storage, USB devices, that either the P2 can't do(like USB2.0 or 1.8V devices) or doesn't make sense to dedicate high performance pins to. I personally would rather everything be doable well on the P2, so I can KNOW the whole computer inside and out like the C64, but my requirements are more than they used to be.
The software had to be developed and a new chip production run had to be payed for. If this would be done, then a edge board with usb serial would cost 79$ instead of 80$. and also that Parallax tries to get back their investment with a low volume.
I've heard Ken talk about how expensive the FTDI chips are to know that they are more than $1 in volume. I brought up the subject because i thought it was worth mentioning in "New P2 Silicon" since Chip has already written USB drivers, and not needing an FTDI could certainly help people get up and running with minimal impediment. Just think of the wonderful things that could be done with a P2 if as many people were playing with it that play with the Pi Pico!
In my opinion this would not help too much. In my opinion the biggest contribution to the cost of the edge board is, that it is not produced using highly automated large batch methods and also that Parallax tries to get back their investment with a low volume.
Probably a good idea, whatever gets more P2's out there and makes Parallax more money is a good thing for all of us.
@evanh said:
I didn't do a good job of explaining that either. The software solution's purpose wasn't really for cost reasons. Hinv used cost as an argument but he really wants to make it a USB only link.
No, I never said that I wanted a USB only link, only USB boot ability be added to the protocols tried when booting. Like SPI boot that I think just gets ignored if there is nothing that responds like a SPI flash, USB protocol can be tried, if nothing responds, then try to talk to it via serial like is the case now. Is there a reason that cannot be done? Will an FTDI chip (or others) lock up or something if it sees 12MHz USB signalling?
One that magically works without knowing how.
While I might not know how to implement what I am suggesting, that doesn't mean it can't be done in a small amount of additional ROM or displace some other ROM code that doesn't get used much, that doesn't mean that it cannot be done.
Where is this code stored? This only works AFTER the P2 is booted, which means if you don't boot it off of serial, you have to dedicate 4 pins to SPI to either boot off of a flash chip or an sdcard.
I've thought the USB code could reside in cog 7 and emulate the boot ROM when the flow control bits are toggled. The boot ROM is simple enough I don't think there would be any reason to make a special USB loader protocol. I don't know if drag and drop is an actual benefit for the developer. It would be a lot more complicated that USB serial.
Benefits* Much faster transfer speeds
Saves $1 off BOM
Where do I get an FTDI chip for $1. The other ones don't count if Parallax won't use them.
Saves money & pins not needing SPI flash.
Seems like they've taken action to prevent the USB chip (whilst disconnected from USB) being powered by the target uC circuit (typically via rx body diodes, but not only), which is one issue with a basic FTDI circuit that leads to a repeating loop of DTR resets in the "right" situation. Not sure it would prevent the other issue, whereby the uC can source current from the USB IC tx pin, and then power itself to some extent. That's just a quick glance- anyway, it's progress.
I'm most interested in the smallest USB-C interface IC possible, and the smallest footprint USB-C socket possible (at sensible price). Slowly but surely it's coming!
@VonSzarvas said:
I'm most interested in the smallest USB-C interface IC possible, and the smallest footprint USB-C socket possible (at sensible price). Slowly but surely it's coming!
USB-C doesn't need any special IC. I think there's some pins that need to be grounded or something so the device at the other end knows to act as host or device, but fundamentally you just do the same old USB 1.1 signalling.
(USB-PD does need a special protocol/IC, but that is entirely disconnected from the actual USB data connection)
@VonSzarvas said:
I'm most interested in the smallest USB-C interface IC possible, and the smallest footprint USB-C socket possible (at sensible price). Slowly but surely it's coming!
USB-C doesn't need any special IC. I think there's some pins that need to be grounded or something so the device at the other end knows to act as host or device, but fundamentally you just do the same old USB 1.1 signalling.
(USB-PD does need a special protocol/IC, but that is entirely disconnected from the actual USB data connection)
ouch, that would be a bit hairy for serial programming - unless the P2 could talk USB protocols fully and directly, instead of bashing a UART type thing. Hmm, I guess that's the point of the USB discussion here, so my bad for pondering in the wrong place. In any event, I was thinking about a future USB-C UART adapter for P1 and P2. I've not really looked at how USB-C works though. so maybe you could use the rx-/tx- for gnds and bash rx+tx+ as whatever protocol. Hairy!
Comments
Christof changed the subject. He wasn't talking about a software solution at all.
I wonder if a circuit could be built that turns breaks on the RX pin into a reset signal. Possibly just some kind of transistor and capacitor circuit. That should allow using any cheap USB serial converters that don't have the flow control pins. Though who knows if they support break signalling?
Well, yes and no. The argument to use a software solution for usb serial is cost. The software had to be developed and a new chip production run had to be payed for. If this would be done, then a edge board with usb serial would cost 79$ instead of 80$. In my opinion this would not help too much. In my opinion the biggest contribution to the cost of the edge board is, that it is not produced using highly automated large batch methods and also that Parallax tries to get back their investment with a low volume.
I didn't do a good job of explaining that either. The software solution's purpose wasn't really for cost reasons. Hinv used cost as an argument but he really wants to make it a USB only link. One that magically works without knowing how.
I've thought the USB code could reside in cog 7 and emulate the boot ROM when the flow control bits are toggled. The boot ROM is simple enough I don't think there would be any reason to make a special USB loader protocol. I don't know if drag and drop is an actual benefit for the developer. It would be a lot more complicated that USB serial.
Benefits
Drawbacks
Not just cost. The potential is ~11Mbaud for booting and then switch to higher than that for host services which are done better & cheaper on other devices like Network, sdcard blocks and general file storage, USB devices, that either the P2 can't do(like USB2.0 or 1.8V devices) or doesn't make sense to dedicate high performance pins to. I personally would rather everything be doable well on the P2, so I can KNOW the whole computer inside and out like the C64, but my requirements are more than they used to be.
I've heard Ken talk about how expensive the FTDI chips are to know that they are more than $1 in volume. I brought up the subject because i thought it was worth mentioning in "New P2 Silicon" since Chip has already written USB drivers, and not needing an FTDI could certainly help people get up and running with minimal impediment. Just think of the wonderful things that could be done with a P2 if as many people were playing with it that play with the Pi Pico!
Probably a good idea, whatever gets more P2's out there and makes Parallax more money is a good thing for all of us.
I’ve not tested the feature, but the newest WCH parts mention anti current backflow:
https://wch-ic.com/products/categories/46.html?pid=1
No, I never said that I wanted a USB only link, only USB boot ability be added to the protocols tried when booting. Like SPI boot that I think just gets ignored if there is nothing that responds like a SPI flash, USB protocol can be tried, if nothing responds, then try to talk to it via serial like is the case now. Is there a reason that cannot be done? Will an FTDI chip (or others) lock up or something if it sees 12MHz USB signalling?
While I might not know how to implement what I am suggesting, that doesn't mean it can't be done in a small amount of additional ROM or displace some other ROM code that doesn't get used much, that doesn't mean that it cannot be done.
Where is this code stored? This only works AFTER the P2 is booted, which means if you don't boot it off of serial, you have to dedicate 4 pins to SPI to either boot off of a flash chip or an sdcard.
Where do I get an FTDI chip for $1. The other ones don't count if Parallax won't use them.
Saves money & pins not needing SPI flash.
Good to know, thanks.
Seems like they've taken action to prevent the USB chip (whilst disconnected from USB) being powered by the target uC circuit (typically via rx body diodes, but not only), which is one issue with a basic FTDI circuit that leads to a repeating loop of DTR resets in the "right" situation. Not sure it would prevent the other issue, whereby the uC can source current from the USB IC tx pin, and then power itself to some extent. That's just a quick glance- anyway, it's progress.
I'm most interested in the smallest USB-C interface IC possible, and the smallest footprint USB-C socket possible (at sensible price). Slowly but surely it's coming!
USB-C doesn't need any special IC. I think there's some pins that need to be grounded or something so the device at the other end knows to act as host or device, but fundamentally you just do the same old USB 1.1 signalling.
(USB-PD does need a special protocol/IC, but that is entirely disconnected from the actual USB data connection)
ouch, that would be a bit hairy for serial programming - unless the P2 could talk USB protocols fully and directly, instead of bashing a UART type thing. Hmm, I guess that's the point of the USB discussion here, so my bad for pondering in the wrong place. In any event, I was thinking about a future USB-C UART adapter for P1 and P2. I've not really looked at how USB-C works though. so maybe you could use the rx-/tx- for gnds and bash rx+tx+ as whatever protocol. Hairy!