USB seems to be PITA
Rayman
Posts: 13,900
in Propeller 2
But, would be great selling point for P2 IMHO..
Hope Chip can figure it out.
I wouldn't be upset if crystal had to be a certain value to make it all work btw...
Hope Chip can figure it out.
I wouldn't be upset if crystal had to be a certain value to make it all work btw...
This discussion has been closed.
Comments
Initial tests would be ideally at 12 * N MHz (N >= 4), but I think even 80MHz will be ok, as it will give /7/7/6 in the NCO & the sampling error is less than the 20.833ns of 48MHz
Depends on if the targets use Analog PLL, or DPLL, and I think DPLL are used on all devices I have seen.
LS USB should come for free, with FS USB, and may be easier to trouble shoot.
Did you guys see Western Digital produced a special hard disk for the Pi? It's running over USB. Having that one really common comms capability, in addition to serial, spi, etc... is going to make lots of devices accessible and useful.
"The WD PiDrive 314GB device is based on Western Digital's proven, high-volume 500GB platform with design changes made specifically for Raspberry Pi. Customizations made to the drive's magnetic recording and electrical system operating set-points align with Raspberry Pi's USB data and power design to reduce the electrical power load of the hard drive on Raspberry Pi, while still maintaining sufficient performance to deliver maximum USB data transfer rate."
Not clear why the drop from 500GB to 314GB ? - and also not mentioned are numbers on the 'Customizations' ?
Wonder if it works ok on a USB FS port ?
This will make the SD boot dictate, look a more of a kludge...
Now it's pi hundred MB (3.14 X 100).
The fact that Chip is struggling to get it implemented isn't a statement about his abilities, it's a statement that this is not a good fit for the P2.
For hobbyists wanting USB host functionality, there are already a variety of inexpensive USB Host Shields that provide easy integration with existing smart cell capability. If your only desire is to hook up mouse and keyboard, USB-to-PS2 adapters are readily available and cheap and should work quite nicely with the existing smart cells. And for commercial USB host applications, there are a variety of ICs that already provide more functionality than that which Chip will be adding.
If, on the other hand, you want to implement a USB device, there are also a variety of existing breakout boards and bridge ICs that are already available and more capable. Not only that, but adding USB support in P2 does not get you around having to deal with the VID/PID issue, writing custom drivers, etc.
And, as I pointed out once before, adding this capability to every smart cell is a waste of resources! Very few of the pins will actually be used for USB, if at all. I'm sure there will be a rare case where multiple USB interfaces will be used, but the chip should not be designed around the rare use cases.
Just leave USB out.
Of course if adding USB is really just a couple days away, and the ramifications of adding USB (such as requiring VID/PID registration, driver distribution for multiple OS "gasp", cost, etc.. etc..) are really not significant, then maybe having USB now might as well be.
But if this extra feature is really a troublesome one, with many dark days ahead, and potential for many unknown twists and turns- then I've gotta speak that leaving it out for now and rather focusing on finishing up the feature-set that is already in hand seems to me a more logical path forward.
Partly my logic is, that with the release of P2 you will regain control of your time, and also be generating income that can be slated to support development of a future version with USB support back on your own pace.
And from a practical standpoint, dedicated chips for USB are so well accepted now. I'm not sure you could increase the retail price of a current P2 by the value of a USB chip inside. Plus USB is also moving on standards wise. P2 with USB 1 or 2 now may be less than useful with USB 3 comes out. It's a kind of moving target.
I remember fondly my daughters happiness when JK Rowling released the first of the Harry Potter books. And then her joy as each successive book came along. I feel that had JK waited until the full saga was complete, that the infamous cult of HP may never have been, and perhaps the educational value for millions of young fans missed. As was true of Star Wars trilogy too no doubt, for those of an elevated persuasion.
P2, I feel, will do great things without USB.
And Chip, I feel, your mind will be free to achieve even greater things once the next P2 is released.
So do please accept some support from us- if you were to consider wrapping this feature for next time. You've already done so much of which we remain forever in awe.
Get the "final" FPGA ready and released for testing and as the Smart Pins get used by more people, there may be things that are needed for completeness or make more sense to have in All Smart Pins may better fit that real estate.
There are plenty of USB ICs out there from low speed (12 Mbps), to medium speed (480 Mbps), to high speed (5 Gbps).
BTW, the FT232H/FT2232H has a fast synchronous 245 parallel FIFO mode and the datasheet claims 35 MBytes/s. The FTDI outputs a 60 MHz clock and sends 8 parallel bits.
I think It would be much more worth the effort to adapt the P2 streamer to this fast 245 FIFO. Also, a 245 mode seems kind of generic and can be used for any other communication purposes.
uh! Well, how to say this ... you know it is Q1 2016 now, right ;-D.
You can order FT600 or FT601 at digikey for less than US $10 (single quantities).
They are USB 3.0 and are able to do stream 16 bits (FT600) or 32 bits (FT601) at 100 MHz. The datasheet also said that can talk at 66 MHz, but this is not clear. BTW, can the P2 streamer handle this?
Yes, they are stocked !!! (FT600 344 pcs., and FT601 531 pcs.).
Actually, I (and others) said to abandon USB several weeks ago. And Chip has been saying "it's coming together" (in one way or another) for several weeks as well. Don't let USB be driven by the Sunk Cost Fallacy!
Supporting Chip is opposite of what you may think - it's in the interest of every possible stakeholder to finish Propeller 2 without USB support now, and consider adding it on a future revision. Roll back to a prior GitHub version, make it work and go to fabrication.
Products have specifications and release dates. At Parallax, specifications are a combination of being market and engineering-driven. There's a union of these two circles of possibilities that represent the ideal outcome. The size of each circle could represent the time required to provide the specification (above, I read that USB could "come for free" - wow!), with the overlap size being the financial viability. The specifications from marketing say that Propeller 2 has A/D, more RAM, faster speed and more I/O. Code protect is a requested feature from the highest volume customers. The engineering circle includes many amazing things: Smart I/O, video functionality, and now USB.
Now, what size would you draw each circle, and how much overlap would you give them? Keep in mind this overlap area represents ROI. Considering you are all engineers or engineering-minded, does it look right? Now picture yourself as a businessman, investor or accountant. Does it look any different?
I almost forgot about the role of specifications and schedule. You can fill in the blanks here, but normally specifications are dropped to reach release dates, not added to extend them.
Chip, I realize you're almost done. Even though you're almost done, you have my 100% support to roll back, test and finish. The last month or two of experience have been extremely valuable in terms of knowledge that can be applied on the next round of development.
We've been here before, several times. Enthusiasm gets ahold of us, the die and complexity grow, what looks easy is not, the chip goes on a diet and gets scaled back. For people to get my point maybe I need to be extreme like a politician so you remember what I write because it is so silly and irrelevant to the topic. I'll do that, then, and leave you with this: be like Oprah and put P2 on a diet - for every pound she looses her supporters and financials go berserk! Parallax needs a bit of the Oprah hype and success to support this project.
Ken Gracey
P.S. I have been told I have a special way of squashing discussions and accompanying engineering enthusiasm. That needn't happen here. Carry on as you do, sharing your thoughts!
I agree pretty strongly with you. The P2 sans USB is already a feature rich device that I can't wait to have as a final product in chip form. I realize that having USB "built in" would be nice and a lot of other MCUs have it, but it's certainly not the end of the world to not have it. We've all done quite well with the P1 even though it doesn't have it, because it's pretty trivial to use an FTDI (or other) USB chip to get it.
Chip,
Let's get P2 out the door, and then you can work on P2.5 (or whatever you want to call it) that has some of these extras like built in USB.
What's been taking so long with USB is not exactly technical. The whole thing has just been unpleasant. USB is an ugly little wad of pointy concepts, and it seems to me that the driving impetus behind it was to force people into making custom silicon while roping them into a system of tribute. This is opposite of fun and free, and so it's been a slog to get through.
Today I should have the transmitter done. Then, I'll bring the receiver in. It's really not that much silicon. I don't think the testing for this is all that complex, either. It's going to be more about getting the software interface straight, so that writing code for it is not ugly.
Isn't that what some of these 16 cogs are for?
Unfortunately, without the helper instructions and 96MHz, the USB task is just that much harder. Add that to the moving target, and the possibility of a full byte assembling hardware, I have just sat on the sidelines, and developed some P1 stuff instead.
There are some I/O driving requirements that make things tight, like needing to control DIR and OUT simultaneously. The smart pin does this now by leaving DIR on, but changing the high/low modes (1.5k/15k/drive/float) on each clock cycle. We'll do it right, but without the CRC stuff.
Ken Gracey
I think we all sense USB unpleasant, and hoping someone else would deal with its unpleasantness so we wouldn't have to. Trouble is it's probably unpleasant all the way up, from this bit level stuff up to drivers and beyond.
We can have a lot of fun with the chip as it stands in the v7 image. We may even be able to achieve usb using the programmable state machine modes by sacrificing a few cascaded pins, and operating at a multiple of 12MHz
Great, Sounds very close.
Certainly, these faster chips need to be supported, as the planned USB is LS/FS only, and the streamer can pump data far faster than FS USB.
They should not be overlooked - I believe both paths are needed.
I have always assumed talk of 'the streamer' included simple handshake / FIFO lines for connection to other hardware, but given Chip's more recent questions I'm not certain of this ?
The FT600 looks a little tougher than FT232H, as it seems to have only two CLK choices, and requires the P2 is a slave to that clock.
Possibly a P2 > 132MHz might manage this ?
Not sure how to test this tho ?
CRC is needed somewhere, it is a question of HW? at the pin?, or in SW ?
I'd try the USB flow with SW CRC, and see what the real-world issues are.
If the SW cannot keep up, then that makes a stronger case for Logic-CRC
If it was needed, maybe CRC-Logic could slip into the Cordic ?
That has only one copy, and the turn-around speed for Cordic may be ok here.
This should be able to support both LS and FS USB ?
Early testing could be on LS USB, then FS, as the code is tuned.
P2 will be able to manage both HOST and DEVICE, which none of the sub $1 parts can, and P2 will be able to push USB to full FS bandwidth.
When you actually test many of the cheap USB parts, they struggle to do above 1~2MBd sustained flows.
It seems closer to $1.50 is needed, to get what I'd call proper Full Speed operation.
But, as you point out (though I know it's not your intent), there are just way too many questions that still need to be answered. This is part of my concern about adding hardware USB support at this point in time. Once it's added, then we MUST make sure that both device and host implementations will work correctly. And that MUST be done before the P2 can be finalized. Not only that, but if we apply the same due diligence that we've applied to the rest of the current implementation, we will need to make sure that the hardware is as optimized and easy to use as possible. If we know anything about Chip's ideals, we know won't release the P2 until he's sure it's done right. And that will take a non-trivial amount of time for something as complex as USB.
Having said all that, Chip's prior comment makes it clear that he absolutely intends to implement the USB hardware support, so I hope that those who want baked-in USB are already working on a software stack, test code, etc. As soon as Chip's released an image, it's the software that will be holding up the his ability to call the design complete.
A parallel 'ghost' RX is how I would test the Rx side - clip the P2 onto a working USB link, (eg FT23x already on PCB) and test until you can extract what the FT23x sees.
Then, start adding replies on another USB pin pair, until the scope says they 'line-up' with FT23x replies.
When all that looks ok, live connects can be tested.
Chip says "I don't think the testing for this is all that complex, either. It's going to be more about getting the software interface straight, so that writing code for it is not ugly."