Philip: Sorry for the delay in responding. I went researching an answer to your question and got lost in my college texts.
The voltage regulator circuit that you described would be quite similar to San's. The differences are that a voltage regulator is always on, and thus an IR driver would need to be switched off and on. Disconnect the resistor from the Supply and you probably have an input for the switch voltage. Also, the "Constant voltage here" is used to place a resistor that will set the current. Since V=IR or I=V/R, then you can set "I" by selecting "R" based on the "V"
vimark: The "Simple transistor current source" is also always on, just like the voltage regulator. Disconnecting R1 from Vs(+) and connecting it to a PIC port pin which swings from GND to Vs(+) should do the trick. If you continue on down that Wikipedia page, the "Simple transistor current source with diode compensation" is getting closer to San's circuit.
San Bergman's circuit is here: http://www.sbprojects.com/knowledge/ir/ir.htm Scroll down to "The Transmitter" and read the working description of the final circuit. I like the possibility of ordering two of the same part (San uses two identical diodes) instead of two different parts.
The smallest Zener I could find is 1.8V, but a pair of simple diodes in series is 1.2V, giving more room for the IR LED forward Voltage drop.
[quote author="ajray"]Really, I was just gonna bit-bang it: write high, spin-wait, write low, spin-wait.[/quote]Not a bad idea. But I would recommend setting up a timer with a precise period, write high, wait for a certain number of timer cycles to fire, write low, wait for a certain number of timer cycles. I haven't looked into the Bus Pirate firmware too deeply, but I think there might already be a timer set up.
If you're a PIC guru, you could rewrite the firmware to lower the clock rate enough that 50 Hz might be possible. Most PIC variations have a really slow 31 kHz oscillator on board, but you'd only want to use that briefly - long enough to do your measurements and then bump back up to full speed. But this would not be a trivial feature to add to the Bus Pirate. The cool thing about open projects is that you can build many things on an open hardware platform that may have never been considered, although it means you have to write your own firmware which might break from the standard feature set.
Where can I order through-hole display connectors? I want to get data sheets and create Eagle packages. While it's cool to recycle connectors from old hardware, it's kinda hard to design for multiple people finding the same part. I couldn't find anything on Mouser (where I live and work), and I don't have Lady Ada's success when searching Digi-Key.
Ah, yes, the Bus Pirate could scan the monitor data and report it to the host, then later the Bus Pirate could program the chip on the dongle. Mac OS X has developer tools which show the raw data, so you don't even need a Bus Pirate to gather the data. I'd use my PICkit2 for I2C programming, so it looks like I don't need the Bus Pirate at all - it is a good cooperative pairing, though.
Yes, EDID should be just simple I2C from a couple of pins, and I recall the VGA/DVI provides power, too.
I'd be happy with a PCB instead of a finished product. Actually, I'm just thinking this would be a decent open design, even if it isn't manufactured and sold in volume. For me, the EEPROM should be reprogrammable. Personally, I don't like the uC design because it's sure to cost more than $0.13 in chips! I envision a super-minimal design that is permanently dedicated to a single purpose.
[quote author="Sjaak"]How about just I/O and H/L/Z (or 1/0/Z) ? You can also use the pinnumber instead of the name to keep it more general.[/quote]I second the I/O and H/L/Z, but suggest using both pin number and name for maximum readability. Then, if you pick a confusing abbreviation for the name, the number will be a certain identifier.
Another suggestion is to put each pin on its own row instead of in a column. The columns would then become Pin Number, Pin Name, Direction, and State. With only 5 pins being reported, there's not much difference between a 3-line, 4-line, or 5-line report.
At the very least you can grab the source and see what you can come up with. If you do get something working then I'm sure submitting a patch or checking in your changes can be worked out with the moderator.
I would like to design an EDID dongle for both VGA and DVI connectors that is easily programmed and is compatible with OSX and XP (or more).
First, a little history as to why I want to design this, then a few comments, and finally what I need to complete this project.
I'm a Unix person who currently uses Power Macintosh computers (after NeXT and Sun). Obviously, many of the PIC, DSP, and other hardware development tools require Windows. So, I've been borrowing computers - either Intel Mac or generic PC - and running them via VNC to avoid buying more keyboards, mice, and LCD monitors. First thing I noticed is that many computers will not work without a monitor attached. Those that will work will often refuse to go into certain video modes if a compatible monitor is not attached. I have a 1920x1200 Cinema HD display, so I often enjoy connecting to XP at 1920x1200 for PIC development under XP, particularly on the Intel Mac mini (it uses so little space on my desk). I don't want to keep disconnecting and reconnecting my Cinema HD every time I need to reboot XP, but then I get bumped down to 640x480 in my VNC session, if I'm even lucky enough for XP to boot headless.
After a bit of research, I discovered that both VGA and DVI support EDID, with data sizes in increments of 128 bytes. With an EDID dongle, I could copy the data from my display so that the Intel machine sees the same capabilities, but I could leave the Cinema HD attached to my Quad G5 all the time. I already have a program which reads the EDID data from my monitor, so all I need is a PCB and connectors. Such a circuit could be designed with a single EEPROM memory chip and not much else. I'd prefer if the memory could be write-protected, but that's not critical. The data lines should be very easy to wire to the VGA or DVI connector.
Ideally, I'd like to find a through-hole version of both a VGA connector and a DVI connector. My plan is to place pads for VGA on one side, and DVI on the other. I have no desire to design a VGA-to-DVI adaptor, but I'm thinking that a single PCB design would save money so that people needing either standard could use the same board. You just order the board, solder on the memory, and pick one of the two display connectors. The PCB should be small enough that the excess area for the unused display connector would be negligible. The whole thing would plug directly into the computer with little room taken up.
As I write this, I'm thinking that it might also be good to multi-site the memory for both through-hole and SMD. I was originally expecting to use SMD memory for the EEPROM, but perhaps through-hole (if available) would make the project even easier.
This whole thing might be nothing more than a bare PCB design and bulk purchase. However, I suppose Seeed could be involved for people who don't want to do any soldering. I have the PICkit2 programmer, so I plan on designing a 6-pin ICMP plug on the PCB for programming.
There is someone on the internet who sells such a device for $20, but I always like to design my own. I also don't know whether his design accommodates both VGA and DVI equally. I prefer not to use an adaptor when it should be so easy to just directly support each connector.
P.S. Candidates for the EEPROM are: $0.24 Microchip 24LC01BT-I/SN EEPROM 128x8 - 1.8V SOIC-8 I2C $0.45 Microchip 24LC21A-I/SN EEPROM 2.5V Dual Mode $0.13 ON Semiconductor CAT93C46WI-GT3 1Kbit Microwire Serial EEPROM
Can anyone suggest easy-to-use through-hole (or even SMD) VGA and DVI connectors? If so, then please provide links to data sheets so I can create packages in Eagle for the PCB design.
[quote author="rsdio"]As far as I know, the AVR series does not usually contain an internal Flash memory, so there could be quite an incompatibility.[/quote] Oops, I was thinking of the DSP chip that I'm designing with that doesn't have Flash. Lots of AVR chips have internal Flash, although they're typically much smaller than the PIC Flash at the same price point. But the bottom line is that programmers generally don't handle both.
What you describe can happen sometimes, but it's highly dependent upon the circuit that you have attached, and somewhat upon the type of port circuitry. A low on most PIC ports will be no higher than 0.4 V, which is typically too little to turn on any LED. Also, some circuits will go high if you use High-Z, certainly if there is any kind of pull-up. The moral is that you need to know what will happen with your particular circuit and choose HiZ, high, or low as appropriate.
1) There are breadboards and there are perf boards (perforated). You can find a big block of plastic, sometimes even mounted on a slab of aluminum, but sometimes smaller like you have is better.
2) Some of the PIC chips do not need more than 5V to program. Go to the Microchip site and look at their web selector. You can check boxes for USB and programming voltage, plus select packages that work on a breadboard, and see what options there are. I've used the PIC18F67J50, which needs only 3.6V maximum for programming, but it is SMD only, so you can't use it on a breadboard.
NOTE: The first programmer that I purchased from PIC16.COM burned out when my client made the board with VPP shorted to ground! I was able to fix it by looking for the smudge of smoke on the plexiglass cover which made it obvious that one transistor had burned out. It's SMD, so it was quite a trick to repair without damaging anything else. I bought a couple of spares before upgrading to the official Microchip PICkit2, which was only $5 more at the time. The advantage of the PIC16.com is that it has a cable so you can program boards where the PICkit2 from Microchip won't fit - e.g. the USB IR Toy cannot be programmed with the Microchip programmer if you have the straight ICSP header, but I see in the photos that Ian has a USB IR Toy with a right-angle ICSP header which would work. Another thing to note is that the price of the PIC16.COM product has gone up now that they have a plastic case over the whole thing. Mine looks more like a Dangerous Prototype, but I can tell from the alignment of the LEDs and button that the new model is just the old PCB in a new case. With the price increase, I can't say it's worth ordering from China unless Microchip is out of stock and you are in a hurry.
3a) Good question. I'd have to look at the schematics and software for the WinLIRC and figure out how it works before I could say anything worthwhile. If you've got more detailed knowledge about WinLIRC, then maybe you can figure it out. With the right circuit, the computer has less to do, and thus the timing and bit length becomes less of an issue. However, the WinLIRC circuits that I found were very basic, meaning that the computer must handle the Manchester coding, and must create 28-bit codes. Perhaps WinLIRC uses buffering inside the UART to concatenate more than one serial word together, without a timing gap, to get the longer bit sequence. Without code-reviewing WinLIRC, there's no telling how well it works. I did notice some brief comments on the random Google hits that I found which mention that WinLIRC is not very reliable. That might be very important to consider when comparing the USB IR Toy or your own PIC breadboard solution with WinLIRC.
3b) I'm new here, so I haven't looked at the Bus Pirate in detail. I'm sure 'rct' is correct: You should be able to make a simpler circuit to convert IR to voltage and use the BP instead of the USB IR Toy, since you already own the BP. Since you're on a breadboard, I suggest that you follow the links to San Bergmans' circuit, which uses a small number of cheap parts to create a constant current source instead of one where the current varies with the voltage. This allows you to get the maximum range from your IR transmitter. Make sure that you check your part number and get the spec sheet for your IR LED to confirm the maximum steady current that it can handle (not the higher pulsed current, since you can't be sure your firmware pulses won't be too long). You'll also have to make sure that the forward voltage of your IR LED is not too large compared to the power supply voltage, or else the circuit won't work.
I say go for it. The Bus Pirate should be a fine platform for USB IR experimentation, provided you can write firmware, program the chip, and breadboard the right circuits.
1) Just about any diode will work if you are building on a breadboard. Look at the Reset chapter of the PIC18F2550 Data Sheet, Figure 4-2, and you will see that the diode is used to condition the MCLR signal for reset. They do not give any particular parameters for this diode, so I imagine that just about anything will work. Might as well make sure it can handle at least 500 mA, but I'm not quite sure how to calculate the maximum current when shorting out the capacitor shown in the Microchip circuit. However, the USB IR Toy does not actually have the pull-up resistor or Power On Reset capacitor, so I'm not sure that the diode is even needed at all. Microchip points out that it is there to discharge the capacitor, so you can probably skip it entirely. Alternatively, you have the option of implementing the full circuit shown in the Data Sheet, with the capacitance and resistance recommended by Microchip. Since you're using a breadboard, it should be a simply matter to add this. I have learned that each PIC model has slightly different requirements for MCLR conditioning.
2) The PICkit 2 programmer is only $34.99 from Microchip, and less from vendors like PIC16.com, so I wouldn't bother hacking something that might not work. AVRDude might be specific to the AVR. As far as I know, the AVR series does not usually contain an internal Flash memory, so there could be quite an incompatibility. This does seem like a good question for the Bus Pirate forum, since general programming of any PIC would be a useful feature.
3) If you simplify the circuit, especially by removing the PIC, then you will lose compatibility with certain devices. It's certainly possible to cover a large subset, but you will lose something.
3a) This is an interesting question. I recently considered the question of why the USB IR Toy was not designed to simply use the UART that is built in to the PIC. I quickly answered my own question: IR Remote Control protocols are 14 bits long, and that generally is beyond the capabilities of most UART peripherals except those on a DSP (which is well beyond the capabilities of a PIC unless you upgrade to dsPIC). Not only are the Remote Control signals 14 bits long, but they are Manchester-encoded, meaning that they're really 28 bits long if you don't have the benefit of a hardware decoding circuit for the Manchester data format. Girder probably does not have the precision to handle 14-bit Manchester codes over the UART. You're on your own figuring that out, but get back to us if they claim to support 14-bit Manchester or 28-bit UART modes.
3b) There is no guarantee that any given remote control is using a standard protocol. The USB IR Toy is designed like a logic analyzer, so that you can discover the protocol even when it is unknown. If your goal is to store a particular remote control's commands, then you'll need to know in advance which protocol your remote control is using. The USB IR Toy is a great tool to discover which protocol your remote control uses. However, it's also possible to do a little research online and discover which protocols your particular collection of remote controls use, and then you might be able to design a simpler circuit. But be warned that without the PIC, you might need additional circuits to convert the Manchester codes to normal bits. If you're interested in that, feel free to follow up here after you've confirmed which protocol you need to implement for your particular collection of remote controls.
Speaking of the v1.2 firmware release, is this something with a public source code revision repository? If so, then I may be able to help with some things once I finally get started with the USB IR Toy.
[quote author="IPenguin"]In my opinion it would be nice if the design would have pinouts for the 3 most common JTAG connectors (20-pin, 14-pin and 10-pin) despite the extra board space needed.[/quote] I second this suggestion, although I would be using the 14-pin. I recently designed a TMS320VC5506 board with USB, 24 analog inputs, 32 analog outputs, and capacitive sensors. I had to use the following documents (SPDU079A, SPRU655D) to design the board to be compatible with Texas Instruments' JTAG debugger/programmer standards. I think you'll find that if you read through them, you might understand more about what your design should support. http://focus.ti.com/lit/ug/spdu079a/spdu079a.pdf http://focus.ti.com/general/docs/litabs ... r=spru655e
... however, I note that some of the advanced, high-speed JTAG ports would suffer if multiple pinouts were on the PCB. Texas Instruments actually suggests designing for a single connector. I suppose that recommendation may really only be necessary for the super high speed versions, but I only scanned the updated file.
Following up on the PIC Timer Calculator program errors, I decided to review the USB IR Toy firmware source briefly.
Looking in HardwareProfile.h, it appears that the 10 µs timer for TVBGONE was originally calculated as (65415) or 0xFF87, which would produce 10.083 µs, but later changed to 0xFF9A, which would produce 8.5 µs. I think that if 10 µs is really the goal (note that I have not researched TVBGONE to confirm this), then 0xFF88 (65416) would be better, since it produces precisely 10 µs.
#define T1_10usOffset() TMR1H=0xFF; TMR1L=0x88
Similarly, I've already explained that 64336 should be the preload for 10000.0 kHz.
I have not reviewed the Timer2 values. They might be right, since the interrupt occurs on TMR2 to PR2 match. That's not the same as interrupt on overflow. I think that the PIC Timer Calculation program might produce the right values here, since the Timer2 does count up from 0 to PR2. Then again, counting from 0 to N still gives a period of N+1, so they could be off by one after all.
I'm quite certain that this PIC Timer Calculator is wrong. If someone wants to follow up with HighcoPic on the Proton forum, then feel free to direct the author back to this thread. I'm certainly willing to discuss it here.
If you want to understand the PIC Timer, then read the Data Sheet. It clearly states that the Timer generates an interrupt on overflow. So, where the author thinks the Timer counts to 255 (8-bit mode) or 65535 (16-bit mode), that's off by one. The Timer actually counts to 256 (0x100) or 65536 (0x10000).
Getting back to the specific example of the USB IR Toy, we have FOSC at 48 MHz, but the peripheral clock is at FOSC/4, or 12 MHz. If your target is 10 kHz, then you need a divider of 1200, which translates to a Timer1 starting count of 65536-1200=64336 (0xFB50). The good news is that this is a precise 10000.000 Hz (or how ever many zero digits the crystal is rated for). The bad news is that the 64331 (0xFB4B) value given by the Win32 program actually produces 9958.50622406 Hz, not the advertised 10006.8 Hz.
If you have a calculator with hex conversions, then you can do everything without downloading a program anyway. For a desired frequency, f, just use C=65536-(12000000/f), then convert the resulting timer starting count value C to hex.
If you want to reverse the calculation, f=12000000/(65536-C). These formulae assume 48 MHz for the USB PIC and a Timer1 prescaler ratio of 1:1.
I've painstakingly confirmed these calculations for the PIC18F87J50 by measuring waveforms on a logic analyzer and also comparing the results to other time references. I suppose it's possible that I made a mistake, so please point out any errors.
