I know how it can be with projects that may never get off the ground. I was in a discussion recently about a S/PDIF decoder/debugger that I am designing, and one response was "sounds like a fun project." If only I had time to start that one!
Meanwhile, you could perhaps start looking around the Microchip Application Notes for some ideas on implementing a programmable hub. Now that you have an option under consideration that you really like, a little further study might eventually cause more detailed ideas to gel. Take it at your own pace and you may eventually get there.
I can't remember how long I thought about making my own DMX512 dimmer, but I eventually designed the board, ordered them from Sunstone Circuits, and am now taking my own sweet time writing the code. Since this is a PIC16 design, it's pretty much assembly language only. I even have a quote for stuffing the boards and a potential user (Burning Man art car), but who knows how long it will take to be finished.
Anyway, the point I'm making is that you can make progress even if it is slow progress. Sometimes even taking a small concrete step can boost your enthusiasm enough to carry you to the next step.
[quote author="Ytsirk"]Since fixing the LED I've made several attempts (short of removing the LED again) at trying to get the thing to fail the self test with no success. Bright sunny rooms, covering the LED and receiver with everything I can think of to block out the light, and every time it passes. I can't see anything in the code that would lead it to pass, but I'm not very good at debugging code.[/quote] I only very briefly skimmed the code. Could someone make a comment here as to how the self-test works? I don't think that I even see a self-test, at least not anything which loops. Where should I look in the source files for the self-test section?
(other IR circuit details): I only recently noticed that the IRRX signal connects to 2 port pins instead of just 1. One is RB2/INT2 and the other is RB4/KBI0. I assume that the purpose is to allow firmware which uses either INT2 (External interrupt 2) or KBI0 (Interrupt-on-change) for various potential firmware options.
For true analog testing, it might have been interesting to loop back both pins on the IR LED to RB1/AN10 and RB3/AN9, respectively, to test for reasonable voltages on those circuit nodes. Since those are analog inputs, the PIC could actually serve as a VOM for electrical self test. Of course, this assumes anyone could have predicted that the LED might be reversed, otherwise it's extreme overkill.
I thought you said that your camera showed a dim output from the IR LED? I didn't know about that trick until you mentioned it, and then I tried it with a regular TV remote and saw an obvious white LED shape flickering. I've already changed my USB IR Toy by resoldering, so I can't try the reverse with my camera. I was only curious, though, since I never thought about whether an LED would light up with reverse current.
On that note, most scanning LED matrix circuits have some amount of dim ghosting, and I wonder if this could be due to reverse current. I suppose I should test one of those circuits to find out whether it's just timing.
I am hoping to hear opinions and/or experience regarding the PIC PORT pins and their ability to handle excessive LED current. I recently saw an online "open" schematic design for a PIC driving some LEDs from the PORT pins, and the designer made the comment that no current limiting resistors were needed because the PIC has a maximum current of 25mA, which is safe for the LED. However, whenever I design for the PIC, I make sure to calculate the appropriate resistance to keep the LED current at or below 25mA.
My point is that I don't think the Microchip spec sheet means that they've specifically designed the PIC PORT pins to guarantee that the current will not exceed the ratings, and especially not that this is a feature you can rely on in your designs. Rather, I would assume it's quite the opposite: That you, as the designer, must make sure that your external circuits do not cause more than 25mA to be sourced or sinked from any PORT pin. Further, I would assume that any unlimited LED current would overheat the PIC PORT pin circuits internally, and shorten the life span of the PIC, causing it to burn out prematurely, if not instantly.
Looking at other sections of the PIC, such as the motor drive quadrature pins or the analog pins for the A/D, Microchip has several warnings about excessive current. Examples are the shoot-through current problems with half-bridge motor driving circuits and excessive current when analog voltages are connected to A/D pins that are programmed in digital mode. Even the simple !MCLR input has a current-limiting resistor in the Microchip sample circuits to protect it from excessive current in case the capacitor discharges suddenly.
I can't remember where I read this design comment. If it was anyone here on this site, I don't mean any offense by pointing out what I think was a grave error. I just want to see what other people think in case I'm missing something.
Perhaps my opinion is tainted by my use of the PIC18F87J50 Family, where only 24(32) pins can handle 25mA, and the remaining pins are either 8mA or even just 2mA. If you tried running an unlimited LED from a 2mA pin, you'd probably eventually burn out the port.
Only for the Curious: The SFH-480 has a 5V reverse voltage, with 10 nA reverse current, so it at least seems plausible that the backwards LED could still light up. It probably wouldn't work reliably if you actually wanted it to operate reverse biased, but maybe there's enough of a trickle of current for a dimly lit reverse LED.
[quote author="ian"]I think a tutorial on debugging options and what it means and how to use it would be really helpful.[/quote] Agreed. I've only used the PICkit2, and I don't know how it would differ from the ICD2, so it would be great to hear people characterize various levels of debugging support.
[quote author="s3c"]The reverse LED is still interesting though, before replacing it I looked at it through my camera and it did light up dimly, could it be that some of the LEDs are in fact correct but the R4 mishap made it appear otherwise?[/quote] (stealing this comment aside for a new topic) We know that a regular non-light-emitting diode will conduct slightly under reverse bias if a larger threshold is exceeded, and that's what a Zener is, but what I don't know is whether an LED will emit photons when reverse-biased. I haven't looked at the specs for the part in question, but perhaps it documents the reverse voltage and reverse current. P.S. What is that part number?
[quote author="s3c"]The eagle footprints have been ported to kicad, don't recall when this was done but it's been a while[/quote]Do you know whether there is an open-source tool to convert new Eagle library files to KiCAD? This would help for shops with in-house Eagle libraries who might need packages that aren't in the standard set.
I had a feeling that there should be no problem with multiple keyboards. I've used multiple mouse devices at once, and they always seem to work, even though they interfere with each other if both are moved at the same time. Two keyboards should work the same, although typing on both would result in jumbled text.
The HID+hub would be more expensive, suspicious, and perhaps less useful on a laptop, but I keep seeing more and more chips which implement a USB hub. Adding a few buttons for macros and an HID device should be easy. In fact, I don't think that that any literal merge would be needed so long as multiple keyboards are allowed. Once you have designed and implemented a HID+hub, with upstream and downstream ports, I think that it should still be possible to plug it into a laptop USB without an external keyboard and still get the right features. In other words, if the added expense of a hub doesn't stop such a project from getting off the ground, then it should be flexible enough to work in any situation, even one where a spare USB port is not available (provided you can remove the keyboard).
One final note is to wonder whether any system have security measures which might ignore added keyboards.
[quote author="ian"]Ah, but not all PICs are created equal. The 18F and under have config fuses in a 'special' memory location.[/quote] True, but the PIC18F87J50 Family has config in Flash. That's my favorite USB PIC. As you say, not all PICs are created equally!
[quote author="Sjaak"]An other approach would to have the same USB stack as source. By commenting out unneedded code it could be still light and benefit from bugfixes or newly introduces bugs Sharing the stack with the maincode is not wise, when the main code is corrupted (suppose you are testing an new USB stack )[/quote] All of your comments were welcome, but I wanted to respond to the item above. My design placed the USB stack in the bootloader, so corrupted main code would not be an issue. The main code would use the USB stack in the bootloader via an indirect function jump table, with the option of overriding any or all functions as needed by improvements. Meanwhile, the bootloader calls the USB functions directly since the jump table is not needed internally. As I mentioned, the drawback is always that you cannot update the bootloader once it is in the field without programming hardware.
I recommend licensing Eagle, but I guess that can be expensive. I wanted to support someone who makes PCB dev possible on a Mac. I've done 4-page schematic designs and 4-layer boards with the autorouter, and it works well. Doesn't take advantage of my quad CPU, but at least I can let it run in the background.
My clients want their hardware to work with the Mac, so they like the ability to share schematics and boards without being locked to Windows.
I should check out KiCAD. Even though their Mac support seems unstable, it's worth a look.
Texas Instruments makes several low-power DSP chips which support USB on board, making it possible to solve your problem without more than one microcontroller. These DSP chips can communicate directly with a 5 MSPS ADC via DMA and then pass the data on to the USB host. Look into the C5000 series, but there may be others that are appropriate. You can even program the DSP in C, but it will probably be a bit more complex than a PIC design.
Sharing the stack with the maincode is not wise, when the main code is corrupted (suppose you are testing an new USB stack