This camera project is going to have USB support, but not the sort of USB that your personal camera has. As discussed earlier, the camera processor module will communicate with the host computer via WiFi, so there is no need for USB there. But I'm not talking about peripheral USB ports anyhow. In fact, I want to hang USB peripherals off the processor module.
Motivations
There are two specific uses I have in mind for USB support. The first is to control filter wheels. There are a variety of store-bought filter wheels available, and most (if not all) can be controlled by USB. These are typically controlled by the host computer, but that host will be some distance away from the telescope, so they really have to connect to the processor module via a USB type-A connector.
I would also like to be able to attach a USB camera to the processor module. Why? Because I would like to build and test the processor board before the sensor board, and it would be very handy to control store-bought USB cameras during testing. I'm thinking specifically of my Nikon-D80 camera, although there are other USB astronomy cameras as well. Also, the former might be great for taking context shots while the main telescope is shooting, and the latter may be useful as an auto-guider. In either case, the extra camera is the USB device and the processor will need another USB type-A connector.
Implementation
So I need two USB ports and both need to at least support being USB hosts. It turns out that the Overo board supports one USB 2.0 host port and one USB OTG port. The OTG port (USB On The Go) should be able to choose to be a host when connected to peripherals, so that will work out fine. Also, the power management chip on the Overo CPU board already includes all the power management needed for the OTG port to work, there is little for me to do there other then provide a socket and a couple simple discrete resisters/capacitors.
The USB 2.0 port is a little more complex. The power management chip doesn't help with this port, but the Overo CPU board does include an SMSC PHY to handle most of the USB protocol. It still requires an external power management chip, and so I've placed a TPS61202 to manage power. The USB PHY provides the signals to select the power mode, so this won't be a software issue.
And finally, there are sockets. The USB 2.0 port gets a mini-A socket, and the USB OTG gets a mini-AB. This by the way preserves the option of having this device act as a USB target. I can't imagine why I would want to do that, but it's literally free.
The schematic sheet for the USB interface is processor_usb.sch, with a matching symbol processor_usb-1.sym.
Friday, May 20, 2011
Monday, May 16, 2011
Getting Back to it, and Headway on the LCD
It's been quite a while since I've been able to put any real effort into this project. I've been doing a lot of Icarus Verilog work, and keeping afloat only just barely with day-job work. But enough with my excuses. I've pushed into the git repository a bunch of changes to the schematics. The two major changes are that I'm dropping the ethernet interface and I've cleaned up the LCD interface.
Ethernet Is Out
This important change is a bit of scope reduction. Early on I thought to put every capability of the Gumstix board to use, whether it made sense or not. Some such capabilities include the myriad networking options. I specifically want to support WiFi in order to eliminate cabling between the telescope and the computer, but I was planning on including ethernet support as a high performance extra networking capability. The Pros:
LCD Progress
But I've also made positive progress on another front. With the processor_lan sheet out of the way, I've managed to focus some attention on the LCD display/touch screen support, and that can be found in the processor_lcd.sch schematic sheet. This sheet is both simple and tricky. It is simple because the OMAP processor includes built-in LCD panel support, so it is mostly a matter of hooking up the video signals from the processor to the LCD connector. There is not a whole lot of logical thought needed here.
But this is where it gets tricky: the processor signals are all 1.8V, whereal the LCD signals are at least 2.5V. Therefore, a bus transceiver is needed. I've chosen a TI SN74LVCH16T245 part to do the translation. I set it up so that the side connected to the CPU outputs is 1.8V, and the side connected to the LCD inputs is 3.3V. The transceiver chips take care of the rest. I need two transceivers of 16bits each to handle all the signals. (A few are left over. Should I tie them high or let them float?)
The touch screen controller is a little bit more helpful. The TI TSC2046 has flexible power options; what I do here is power it mostly with the 3.3V that otherwise powers the LCD, but give it a digital I/O power supply of 1.8V. Thus, the digital interface (mostly SPI) is directly compatible with the signals from the processor. The datasheet for the TSC2046 is a little vague about the touch interrupt handling, so I've taken the lead from the Palo43 schematics and added a weak pullup. Hopefully this will prevent spurious interrupts from the touch screen.
The LCD screen is illuminated by a built-in white LED back-light. I'm thinking of having a dial or slider that the user can use to control the brightness. I've thought about software controlled brightness, but frankly I would rather not have the brightness be part of a user interface on the screen. A manual brightness control is simply a variable resister in series with a limiting resister. I think simple is best here. Choose the limiting resister so that maximum brightness (zero variable resistance) gives me roughly 20mA at 3.3V. I'm not yet sure what the range of the variable resister should be, but I will want it to be pretty dim for night-time use. It might be a matter of trial and error.
I've tentatively settled on the LG 4.3inch LCD touch screen (LG part number LB043WQ2). It's not a huge display area (105mm x 67mm) but should be plenty large enough for a rather fancy hand-held controller. It's about the size of a portable automotive GPS. This screen is also known to work with the Palo43 board from Gumstix, so I'll plan on getting a Palo43 and LG 4.3 display from Gumstix as a means to do early software development. Since most of the LCD interface is inspired by the Palo43, it should be software compatible.
How I've Been Cheating
I've mentioned the Gumstix Palo43 a couple times, so it's should be pretty clear by now that I have in fact been using that board as a crib for a lot of these design choices. This is not just a lazy cheat, but a purposeful one. By making the LCD interface (including the display and touch screen) functionally similar to the existing Palo43 board, I've assured myself that I will have a development platform that I can use to prototype a lot of my software. I get a known-working set of similar hardware that I can reference when my custom designs go awry, and I get a collection of known working drivers and other software to get me started with the porting work when the real board is ready.
What's Next?
The most obvious next tasks for the processor unit are the USB interface and the stepper motor controllers. The USB support will be pretty easy (although there will be some tricks to support a debug console) but the stepper motor support will take some thought. I'll be borrowing some more USB details from the Palo43 sample board to keep with software compatibility, but things will get interesting when I start designing the motor controllers.
Ethernet Is Out
This important change is a bit of scope reduction. Early on I thought to put every capability of the Gumstix board to use, whether it made sense or not. Some such capabilities include the myriad networking options. I specifically want to support WiFi in order to eliminate cabling between the telescope and the computer, but I was planning on including ethernet support as a high performance extra networking capability. The Pros:
- Ethernet/TCP/IP is easy to set up,
- It is potentially faster, and
- It is reliable and free of interference.
- The external chips/magnetics take up board space,
- ethernet support a useless power draw when not in use,
- and it is not as trivial to implement as I hoped.
LCD Progress
But I've also made positive progress on another front. With the processor_lan sheet out of the way, I've managed to focus some attention on the LCD display/touch screen support, and that can be found in the processor_lcd.sch schematic sheet. This sheet is both simple and tricky. It is simple because the OMAP processor includes built-in LCD panel support, so it is mostly a matter of hooking up the video signals from the processor to the LCD connector. There is not a whole lot of logical thought needed here.
But this is where it gets tricky: the processor signals are all 1.8V, whereal the LCD signals are at least 2.5V. Therefore, a bus transceiver is needed. I've chosen a TI SN74LVCH16T245 part to do the translation. I set it up so that the side connected to the CPU outputs is 1.8V, and the side connected to the LCD inputs is 3.3V. The transceiver chips take care of the rest. I need two transceivers of 16bits each to handle all the signals. (A few are left over. Should I tie them high or let them float?)
The touch screen controller is a little bit more helpful. The TI TSC2046 has flexible power options; what I do here is power it mostly with the 3.3V that otherwise powers the LCD, but give it a digital I/O power supply of 1.8V. Thus, the digital interface (mostly SPI) is directly compatible with the signals from the processor. The datasheet for the TSC2046 is a little vague about the touch interrupt handling, so I've taken the lead from the Palo43 schematics and added a weak pullup. Hopefully this will prevent spurious interrupts from the touch screen.
The LCD screen is illuminated by a built-in white LED back-light. I'm thinking of having a dial or slider that the user can use to control the brightness. I've thought about software controlled brightness, but frankly I would rather not have the brightness be part of a user interface on the screen. A manual brightness control is simply a variable resister in series with a limiting resister. I think simple is best here. Choose the limiting resister so that maximum brightness (zero variable resistance) gives me roughly 20mA at 3.3V. I'm not yet sure what the range of the variable resister should be, but I will want it to be pretty dim for night-time use. It might be a matter of trial and error.
I've tentatively settled on the LG 4.3inch LCD touch screen (LG part number LB043WQ2). It's not a huge display area (105mm x 67mm) but should be plenty large enough for a rather fancy hand-held controller. It's about the size of a portable automotive GPS. This screen is also known to work with the Palo43 board from Gumstix, so I'll plan on getting a Palo43 and LG 4.3 display from Gumstix as a means to do early software development. Since most of the LCD interface is inspired by the Palo43, it should be software compatible.
How I've Been Cheating
I've mentioned the Gumstix Palo43 a couple times, so it's should be pretty clear by now that I have in fact been using that board as a crib for a lot of these design choices. This is not just a lazy cheat, but a purposeful one. By making the LCD interface (including the display and touch screen) functionally similar to the existing Palo43 board, I've assured myself that I will have a development platform that I can use to prototype a lot of my software. I get a known-working set of similar hardware that I can reference when my custom designs go awry, and I get a collection of known working drivers and other software to get me started with the porting work when the real board is ready.
What's Next?
The most obvious next tasks for the processor unit are the USB interface and the stepper motor controllers. The USB support will be pretty easy (although there will be some tricks to support a debug console) but the stepper motor support will take some thought. I'll be borrowing some more USB details from the Palo43 sample board to keep with software compatibility, but things will get interesting when I start designing the motor controllers.
Subscribe to:
Posts (Atom)