I just realized, finally, that the avoidance of a standard data link protocol was by design in the USB plan.
Ah, I see the crux of the epiphany now. Sometimes, you have to hit me on both sides of the head (or twice) in order to get things to sink in. And thanks for the other comments, too, including the continued update on the USB development. It's good that things are falling into place, and maybe that USB stuff could somehow be used for something other than USB (see below),
Latest series of small monitors from China (vehicle focused) have both VGA and HDMI physical connectors on a step-back panels. (plus Composite of course)
That's right. In my case, I've bought many of the driver boards by themselves (without the LCD panels and housing) and have found the ones with HDMI to be somewhat more expensive (at least a while back). But I don't know whether the boards with HDMI connectors can be included in one's design without paying tribute (licensing), particularly if actually using the HDMI functionality. In my case, though, VGA is just fine. The LVDS driver boards can be even cheaper, but I'm not familiar with that signaling, and support for it on the P2 sounded "iffy" based on past comments. But maybe that will be more feasible now that USB functionality is being included, especially if it's generalized.
I never tought that I ever will vindicate the USB interface. I railed against it countless times.
But it's not as bad as you want to make it.
There are a few communication standards predefined by USB org, that we can use for Prop 2:
- CDC (Communication Device Class) that allows a serial connection with a virtual COM port, just like FTDI. It's built in on Windows (Win7+), Linux, MAC and others. Win-XP needs a driver.
- HID with fullspeed allows to send and receive custom 64 byte packets quite fast. Needs a library on the PC to access it easy from an application (many available for a number of languages)
- MSD (Mass Storage Device) lets you access it via files like a USB-stick.
All the latter need no custom driver on newer PCs, installation goes automatic, just like mouses and keyboards.
A totally custom protocol can be made with LIBUSB a driver library for Linux and Windows. The USB support in the Prop can be simplified, but the user must install a driver.
I use CDC since years with PIC microcontrollers to program and communicate with Prop 1.
I never tought that I ever will vindicate the USB interface. I railed against it countless times.
But it's not as bad as you want to make it.
There are a few communication standards predefined by USB org, that we can use for Prop 2:
- CDC (Communication Device Class) that allows a serial connection with a virtual COM port, just like FTDI. It's built in on Windows (Win7+), Linux, MAC and others. Win-XP needs a driver.
- HID with fullspeed allows to send and receive custom 64 byte packets quite fast. Needs a library on the PC to access it easy from an application (many available for a number of languages)
- MSD (Mass Storage Device) lets you access it via files like a USB-stick.
All the latter need no custom driver on newer PCs, installation goes automatic, just like mouses and keyboards.
A totally custom protocol can be made with LIBUSB a driver library for Linux and Windows. The USB support in the Prop can be simplified, but the user must install a driver.
I use CDC since years with PIC microcontrollers to program and communicate with Prop 1.
Andy
Andy, that sounds promising. Sorry for my negativity.
Does this CDC protocol, for which Windows has built-in libraries, allow us to have the Prop2 appear as a serial port device to the PC? Why does FTDI need to make any custom drivers, at all?
Andy, that sounds promising. Sorry for my negativity.
Does this CDC protocol, for which Windows has built-in libraries, allow us to have the Prop2 appear as a serial port device to the PC? Why does FTDI need to make any custom drivers, at all?
A cynic might say Legacy, and $ ?
FTDI started well before CDC was available, and you are exposed to Microsoft driver quality.
However, it is well worth testing CDC, and I found this in a Microchip forum from 2008
"CDC can go much faster than 64KB/s. I think the maximum I was able to sustain in one direction (either PC->PIC or PIC->PC) was about 700KB/s. You just can't go much faster than that no matter what type of device you are, you're saturating the USB at that point.
The 'baud rate' (like 115K for example) is completely meaningless in the CDC world - the 'baud' rate across USB is always as fast as the PC can schedule things (which can be up to 700KB/s in bursts)."
I'd nudge that claim 700kB up a little, as I've measured about 9.5Mb sustained on FS EXAR parts.
So that's about 760kB/s
Of course back in 2008, PICs could not keep up with the 700kB, and PCs were slower too, so that number was considered somewhat moot back then.
A P2 in 2016 should be able to push to whatever USB ( + PC side) can manage.
The PID/VID has been discussed on many forums. Some people/companies bought PID/VID groups from USB org when there were no sub-licensing restrictions but the USB have been heavy handed with them. Now you cannot sub-license the VID/PID.
For use here, there are some VID/PID numbers that some users decided can be used and you can get one+ from a website for free. They are not valid VID/PIDs, just what some users have decided to use. The general consensus seems to be that VID/PID cannot be patented so you are free to use what you like, but alas, there is always the concept that they may get legitimately allocated someday.
For the time being, I suggest we just use some of these.
From what I understand, you need to join the USB.org for some crazy amount like $7Kpa. Then you buy a PID/VID set for ~$1500. Now you need to test your product for compliance - more $$$ to USB org. Then MS gets their $$$ for testing and including your USB driver in Windows. This is a regular cost, each release of Windows, Windows Server/NT, etc. Then of course, you need to be a MS registered developer (free?) but then you need to buy MSDN (or whatever they call it now) - it's an SDK plus all software - used to be ~$3500pa but I heard that was doubled a couple of years ago.
My recommendation... Just do the hw. Don't go near the USB org as once you sign up you are committing to licensing their stuff.
The PID/VID has been discussed on many forums. Some people/companies bought PID/VID groups from USB org when there were no sub-licensing restrictions but the USB have been heavy handed with them. Now you cannot sub-license the VID/PID.
For use here, there are some VID/PID numbers that some users decided can be used and you can get one+ from a website for free. They are not valid VID/PIDs, just what some users have decided to use. The general consensus seems to be that VID/PID cannot be patented so you are free to use what you like, but alas, there is always the concept that they may get legitimately allocated someday.
For the time being, I suggest we just use some of these.
From what I understand, you need to join the USB.org for some crazy amount like $7Kpa. Then you buy a PID/VID set for ~$1500. Now you need to test your product for compliance - more $$$ to USB org. Then MS gets their $$$ for testing and including your USB driver in Windows. This is a regular cost, each release of Windows, Windows Server/NT, etc. Then of course, you need to be a MS registered developer (free?) but then you need to buy MSDN (or whatever they call it now) - it's an SDK plus all software - used to be ~$3500pa but I heard that was doubled a couple of years ago.
My recommendation... Just do the hw. Don't go near the USB org as once you sign up you are committing to licensing their stuff.
Sounds enchanting.
So, to get a valid VID, you must become betrothed to the whole thing. Entangling alliances.
But will any serious players design a P2 into their products if the USB implementation hasn't been certified?
The Prop2 is not a sub-$2 chip that's going to get used for consumer gadgets, so I doubt it would ever come up. The Prop2 will certainly go into lower-run, higher-cost products where nobody's going to suppose it might not work because it lacks a USB logo. And the developer would have gained confidence in it, already, so that he wouldn't be worrying about it. Just what I imagine the case would be, anyway.
But will any serious players design a P2 into their products if the USB implementation hasn't been certified?
Also, the way we are implementing this would probably not pass their full compliance testing, even though it will work fine. We are using an NCO to generate the output timing, which they would detect large jitter in. To do this "right" might take a real, dedicated PLL. It's NOT worth that much, in this context.
But will any serious players design a P2 into their products if the USB implementation hasn't been certified?
Also, the way we are implementing this would probably not pass their full compliance testing, even though it will work fine. We are using an NCO to generate the output timing, which they would detect large jitter in. To do this "right" might take a real, dedicated PLL. It's NOT worth that much, in this context.
Agreed. If full compliance is required, then an FTDI or similar USB compliant chip can be used. For anyone else, good enough will be a fantastic saving.
I hope there will be many places where the P2 shines. It is certainly not going to sell on price, but more on flexibility and simplicity.
The 10k resistors are used in host mode so that you can detect if a device is connected. Then D+ or D- has a pullup. So this should be no problem.
The 1.5k that is used for USB devices to signal the speed and presence, are more critical. It depends on the host if the device gets accepted with 1k or not. Theoretically the host can measure the voltage on the 1.5k / 15k divider, or can measure the current. But I don't know if hosts really do that and if so why they do that.
But I never seen another value than 1.5k.
I think we need to try it on many PCs to be sure.
Andy
Edit: I have bought 10 VID-PID pairs years ago when it was still legal. I would happyly spend one of them for a P2 USB bootloader.
Do any of you guys think it would matter if we used 10k pull-downs and 1k pull-ups for the USB connection?
They call for 15k and 1.5k in the USB spec, but the Prop2 is currently set up with 1k, 10k, and 100k pull-up/down resistors.
I started changing all these to 1.5k, 15k, and 150k, but I'm wondering if it even matters for the USB compatibility.
It's a difference of 0.1mA quiescent current plus 0.11mA driven current. Besides, if someone wants precisely 1.5k and 15k, they could still use external resistors, right?
I got the pin pull-up/down resistors switched over to 1.5k/15k/150k, so this should work, for sure.
I made these changes in both the old and new schematics and re-LVS'd them to make sure they were square. They look good, so I'm sending them to Treehouse. The layout change just involves making three resistors narrower. Should take about 2 minutes for them.
I decided to change our pull-up/down values, rather than add extra circuits, because it would have meant changing schematic symbols and adding tons of connections.
The way this will work is, the USB mode will control both the OUT and the HHH and LLL inputs to the low-level pad (M[5:0]), in order to control the resistors. This is going to be way simpler than I realized.
Edit: I have bought 10 VID-PID pairs years ago when it was still legal. I would happyly spend one of them for a P2 USB bootloader.
Those might come in very handy. Since you can't sublet them, can you bequeath them?
Ultimately, it would be good to have one for the Prop2 chip and one for things that customers make. That is, if I understand this whole thing properly.
I have seen 2K2 used for pull-up to 5V and the comments imply that while 1K8 may work to 5V that 1K5 doesn't work reliably. It doesn't quite make sense as if you have 4 devices on the bus, then 4x 1K5 in parallel makes 375 ohm - therefore for a single device 1K should be fine.
The pull downs are for host mode so we would be the ones checking so they would likely be fine.
Remember the USB spec supposedly permits 127 devices attached although I recall somewhere that there is a much lower number permitted on the one bus. However, most users of P2 are not likely to have many, if more than one, device(s) on a single bus.
Given the above, 1K might be low although 10K is likely fine for the pull downs. If they are 1k and we have problems I guess we can always use an external resistor and pin. We need to be able to switch the pull-up on/off to enumerate once the driver has been loaded/started, so if it is external we need to use an output pin to drive the external resistor.
BTW 10K pull-ups work fine for PS2 connections to keyboard/mouse/I2C.
I have seen 2K2 used for pull-up to 5V and the comments imply that while 1K8 may work to 5V that 1K5 doesn't work reliably. It doesn't quite make sense as if you have 4 devices on the bus, then 4x 1K5 in parallel makes 375 ohm - therefore for a single device 1K should be fine.
The pull downs are for host mode so we would be the ones checking so they would likely be fine.
Remember the USB spec supposedly permits 127 devices attached although I recall somewhere that there is a much lower number permitted on the one bus. However, most users of P2 are not likely to have many, if more than one, device(s) on a single bus.
Given the above, 1K might be low although 10K is likely fine for the pull downs. If they are 1k and we have problems I guess we can always use an external resistor and pin. We need to be able to switch the pull-up on/off to enumerate once the driver has been loaded/started, so if it is external we need to use an output pin to drive the external resistor.
BTW 10K pull-ups work fine for PS2 connections to keyboard/mouse/I2C.
You mean all those pull-ups wind up in parallel? That would create huge voltage distortions during driving, wouldn't it? I figured the USB hubs isolated things somewhat.
ADDED: They can't work in parallel, otherwise the bus couldn't differentiate slow-speed devices from full-speed devices, as they'd blur together. A USB hub has to isolate these somehow. And they're not going to let slow-speed devices see full-speed traffic, right?
Parallax gets a VID (only 65000 possible vendors possible, so kind of stupid to only allow a 16bit number when VID/PID was invented)
USB.org have been cracking down on subleasing, Parallax will create 10 CDC, 10 HID and 10 MSD PID products and let us know what PID's they are,
so we use the same numbers from this public domain pool when we create our homebrew products.
Parallax will "co-design" with big buyers of P2 chips to give them a few specific PID's of their own.
usb: msp430 recommends using a 1.4k external resistor as internal pin resistance is 100ohm so it must be pretty critical to get the total at 1.5K within 3% if they do this.
i2c: 1.5K is good for fast mode+ and 15K should still will work on slow speed if you keep traces short/cap down and is good if you're trying to save power on battery operated devices.
Maybe it's better to use external resistors for usb...
If prop is reset with usb device connected don't you want the right resistance value there at t=0?
Maybe it's better to use external resistors for usb...
If prop is reset with usb device connected don't you want the right resistance value there at t=0?
Sounds worthwhile to allow both:
Do 1.5k internal, as Chip has done, but not make that the ONLY choice.
Also, the way we are implementing this would probably not pass their full compliance testing, even though it will work fine. We are using an NCO to generate the output timing, which they would detect large jitter in. To do this "right" might take a real, dedicated PLL. It's NOT worth that much, in this context.
Plenty of parts do not use analog PLL.
Most run 48MHz RC osc with a closest snap setting, within 0.25%
It is more important to allow 48N* from common crystals, which is a quite small logic change to existing main PLL to include /M, /N
* maybe it can be 12N, N>=4
You only need the 1.5K while it enumerates (maybe also while active), that is why it's good to have it in software so you can turn it off to save power while in suspend mode.
You want to delay detection to fully initialize the P2's usb software driver that does the enumerations, as it needs to be loaded to the cog first.
or disconnect to force re-enumeration could be possible too.
Some USB hubs are totally passive - no ics, just parallel the connectors. Others are unpowered (power from host) but have an ic to separate the busses. Then there is the powered hubs with an ic to separate the busses.
So yes, up to 4 (or more???) pull-ups can be in parallel. From what I understand the pull-ups remain active while the device is active (working). Ie not in suspend mode.
IMHO 10K is more use than 15K. If that means 1K then so be it. There are other things more important. If 1K ends up not working the we will require an external 1k5 and a pin.
Is there a reason it can not be 1.5K and 10K (and a 3rd 100-150K range) as the options?
is there some binary parallel resistors lined up that makes it ^10?
Comments
The P2 design is currently on par with P1, as ESD goes. After beefing up the drive, it will be tougher.
Ah, I see the crux of the epiphany now. Sometimes, you have to hit me on both sides of the head (or twice) in order to get things to sink in. And thanks for the other comments, too, including the continued update on the USB development. It's good that things are falling into place, and maybe that USB stuff could somehow be used for something other than USB (see below),
That's right. In my case, I've bought many of the driver boards by themselves (without the LCD panels and housing) and have found the ones with HDMI to be somewhat more expensive (at least a while back). But I don't know whether the boards with HDMI connectors can be included in one's design without paying tribute (licensing), particularly if actually using the HDMI functionality. In my case, though, VGA is just fine. The LVDS driver boards can be even cheaper, but I'm not familiar with that signaling, and support for it on the P2 sounded "iffy" based on past comments. But maybe that will be more feasible now that USB functionality is being included, especially if it's generalized.
But it's not as bad as you want to make it.
There are a few communication standards predefined by USB org, that we can use for Prop 2:
- CDC (Communication Device Class) that allows a serial connection with a virtual COM port, just like FTDI. It's built in on Windows (Win7+), Linux, MAC and others. Win-XP needs a driver.
- HID with fullspeed allows to send and receive custom 64 byte packets quite fast. Needs a library on the PC to access it easy from an application (many available for a number of languages)
- MSD (Mass Storage Device) lets you access it via files like a USB-stick.
All the latter need no custom driver on newer PCs, installation goes automatic, just like mouses and keyboards.
A totally custom protocol can be made with LIBUSB a driver library for Linux and Windows. The USB support in the Prop can be simplified, but the user must install a driver.
I use CDC since years with PIC microcontrollers to program and communicate with Prop 1.
Andy
Andy, that sounds promising. Sorry for my negativity.
Does this CDC protocol, for which Windows has built-in libraries, allow us to have the Prop2 appear as a serial port device to the PC? Why does FTDI need to make any custom drivers, at all?
How does the unique VID enter the picture if you just want to be a serial port?
FTDI started well before CDC was available, and you are exposed to Microsoft driver quality.
However, it is well worth testing CDC, and I found this in a Microchip forum from 2008
"CDC can go much faster than 64KB/s. I think the maximum I was able to sustain in one direction (either PC->PIC or PIC->PC) was about 700KB/s. You just can't go much faster than that no matter what type of device you are, you're saturating the USB at that point.
The 'baud rate' (like 115K for example) is completely meaningless in the CDC world - the 'baud' rate across USB is always as fast as the PC can schedule things (which can be up to 700KB/s in bursts)."
I'd nudge that claim 700kB up a little, as I've measured about 9.5Mb sustained on FS EXAR parts.
So that's about 760kB/s
Of course back in 2008, PICs could not keep up with the 700kB, and PCs were slower too, so that number was considered somewhat moot back then.
A P2 in 2016 should be able to push to whatever USB ( + PC side) can manage.
How about the VID matter?
For use here, there are some VID/PID numbers that some users decided can be used and you can get one+ from a website for free. They are not valid VID/PIDs, just what some users have decided to use. The general consensus seems to be that VID/PID cannot be patented so you are free to use what you like, but alas, there is always the concept that they may get legitimately allocated someday.
For the time being, I suggest we just use some of these.
From what I understand, you need to join the USB.org for some crazy amount like $7Kpa. Then you buy a PID/VID set for ~$1500. Now you need to test your product for compliance - more $$$ to USB org. Then MS gets their $$$ for testing and including your USB driver in Windows. This is a regular cost, each release of Windows, Windows Server/NT, etc. Then of course, you need to be a MS registered developer (free?) but then you need to buy MSDN (or whatever they call it now) - it's an SDK plus all software - used to be ~$3500pa but I heard that was doubled a couple of years ago.
My recommendation... Just do the hw. Don't go near the USB org as once you sign up you are committing to licensing their stuff.
Sounds enchanting.
So, to get a valid VID, you must become betrothed to the whole thing. Entangling alliances.
I think your recommendation is sensible.
The Prop2 is not a sub-$2 chip that's going to get used for consumer gadgets, so I doubt it would ever come up. The Prop2 will certainly go into lower-run, higher-cost products where nobody's going to suppose it might not work because it lacks a USB logo. And the developer would have gained confidence in it, already, so that he wouldn't be worrying about it. Just what I imagine the case would be, anyway.
Also, the way we are implementing this would probably not pass their full compliance testing, even though it will work fine. We are using an NCO to generate the output timing, which they would detect large jitter in. To do this "right" might take a real, dedicated PLL. It's NOT worth that much, in this context.
I hope there will be many places where the P2 shines. It is certainly not going to sell on price, but more on flexibility and simplicity.
They call for 15k and 1.5k in the USB spec, but the Prop2 is currently set up with 1k, 10k, and 100k pull-up/down resistors.
I started changing all these to 1.5k, 15k, and 150k, but I'm wondering if it even matters for the USB compatibility.
The 1.5k that is used for USB devices to signal the speed and presence, are more critical. It depends on the host if the device gets accepted with 1k or not. Theoretically the host can measure the voltage on the 1.5k / 15k divider, or can measure the current. But I don't know if hosts really do that and if so why they do that.
But I never seen another value than 1.5k.
I think we need to try it on many PCs to be sure.
Andy
Edit: I have bought 10 VID-PID pairs years ago when it was still legal. I would happyly spend one of them for a P2 USB bootloader.
It's a difference of 0.1mA quiescent current plus 0.11mA driven current. Besides, if someone wants precisely 1.5k and 15k, they could still use external resistors, right?
I made these changes in both the old and new schematics and re-LVS'd them to make sure they were square. They look good, so I'm sending them to Treehouse. The layout change just involves making three resistors narrower. Should take about 2 minutes for them.
I decided to change our pull-up/down values, rather than add extra circuits, because it would have meant changing schematic symbols and adding tons of connections.
The way this will work is, the USB mode will control both the OUT and the HHH and LLL inputs to the low-level pad (M[5:0]), in order to control the resistors. This is going to be way simpler than I realized.
Those might come in very handy. Since you can't sublet them, can you bequeath them?
Ultimately, it would be good to have one for the Prop2 chip and one for things that customers make. That is, if I understand this whole thing properly.
The pull downs are for host mode so we would be the ones checking so they would likely be fine.
Remember the USB spec supposedly permits 127 devices attached although I recall somewhere that there is a much lower number permitted on the one bus. However, most users of P2 are not likely to have many, if more than one, device(s) on a single bus.
Given the above, 1K might be low although 10K is likely fine for the pull downs. If they are 1k and we have problems I guess we can always use an external resistor and pin. We need to be able to switch the pull-up on/off to enumerate once the driver has been loaded/started, so if it is external we need to use an output pin to drive the external resistor.
BTW 10K pull-ups work fine for PS2 connections to keyboard/mouse/I2C.
You mean all those pull-ups wind up in parallel? That would create huge voltage distortions during driving, wouldn't it? I figured the USB hubs isolated things somewhat.
ADDED: They can't work in parallel, otherwise the bus couldn't differentiate slow-speed devices from full-speed devices, as they'd blur together. A USB hub has to isolate these somehow. And they're not going to let slow-speed devices see full-speed traffic, right?
But now, I have to wonder about I2C pullups.... 1.5k seems small and 15k seems big.
Actually, I think this: http://www.nxp.com/documents/user_manual/UM10204.pdf
Says that 1.5k and 15k could both work...
But, maybe 1.5k would be safer as would work with any capacitance loading...
USB.org have been cracking down on subleasing, Parallax will create 10 CDC, 10 HID and 10 MSD PID products and let us know what PID's they are,
so we use the same numbers from this public domain pool when we create our homebrew products.
Parallax will "co-design" with big buyers of P2 chips to give them a few specific PID's of their own.
usb: msp430 recommends using a 1.4k external resistor as internal pin resistance is 100ohm so it must be pretty critical to get the total at 1.5K within 3% if they do this.
i2c: 1.5K is good for fast mode+ and 15K should still will work on slow speed if you keep traces short/cap down and is good if you're trying to save power on battery operated devices.
If prop is reset with usb device connected don't you want the right resistance value there at t=0?
Sounds worthwhile to allow both:
Do 1.5k internal, as Chip has done, but not make that the ONLY choice.
Most run 48MHz RC osc with a closest snap setting, within 0.25%
It is more important to allow 48N* from common crystals, which is a quite small logic change to existing main PLL to include /M, /N
* maybe it can be 12N, N>=4
You want to delay detection to fully initialize the P2's usb software driver that does the enumerations, as it needs to be loaded to the cog first.
or disconnect to force re-enumeration could be possible too.
So yes, up to 4 (or more???) pull-ups can be in parallel. From what I understand the pull-ups remain active while the device is active (working). Ie not in suspend mode.
is there some binary parallel resistors lined up that makes it ^10?