I'm designing a wired remote to interface with a master device equipped with an Arduino Micro. Cable will be in the ballpark of 25ft/8m. Power(5V+GND) will be supplied from the PSU in master device through the same cable.
The AS1115's will also transmit a IRQ signal to the Arduino when one of the momentary switches have been pressed. Should I just use 1 channel of another P82B715TD bus extender for this signal? Or is there a more practical option?
There is also an incremental rotary encoder on the remote with quadrature output. The output signal according to the datasheet http://download.siliconexpert.com/pdfs/2012/12/16/2/14/5/777/bos_/manual/em14.pdf is 25mA for each channel(<800mV Low, >4.0V High). It is 64ppr and will be hand spun. How should I transmit this pair of signals? I'm assuming they won't survive the 25ft run without assistance.
Finally, what would you recommend for the connector/cable standard?
I need to transmit:
5V
GND
SDA
SCL
IRQ
Encoder A output
Encoder B output
I have considered adding an Arduino to the remote. I haven't been able to justify it yet, as all I need to communicate with is two I2C LED drivers and a rotary encoder. Just seems excessive.
Maybe I'm wrong? Is it that difficult to carry those signals a relatively short distance of 25ft, even with some sort of line driver? The I2C lines have no problem with it using the P82B715's.
Transmitting the I2C bus is actually the part that I have already solved- the P82B715 chips are meant exactly for this purpose. (http://www.mouser.com/ds/2/302/P82B715-354923.pdf) My research on this topic was successful. However my research was unable to answer my other questions, which I why I'm here.
What I need to transmit are the IRQ line and the rotary encoder quadrature outputs as described in the first post. Would some sort of differential line driver be a reliable option?
I'm not sure of the answer to that, but am inclined to suggest a slave Arduino at that end rather than trying to send all those separate signals separately.
I have considered adding an Arduino to the remote. I haven't been able to justify it yet, as all I need to communicate with is two I2C LED drivers and a rotary encoder. Just seems excessive.
Well you can make up an Atmega328P stand-alone board for about $5 of parts. Or get one of those cheap printed-circuit boards designed for such a purpose, eg.
or:
The latter one is $3 (plus the chips) or here:
That is $11.75 including enough parts to get it going.
I hadn't considered making my own custom Arduino with the Atmega328P. You've convinced me that that is the best way, as I can easily incorporate the tiny processor into my PCB design and transmission over the cable will be simplified greatly. Also, it's probably cheaper in the end.
And a very helpful post at that! I have a few related questions:
First of all, I'll be using a surface mount 328P so I need to bootload/program it already soldered to it's destination PCB. Looks like I'll need a single-row 6-pin FTDI header for sketch programming using this cable: FTDI Serial TTL-232 USB Cable : ID 70 : $19.95 : Adafruit Industries, Unique & fun DIY electronics and kits and an ISCP 2x3 header for bootloading using an Arduino Uno. It appears I cannot hook up directly from this to the Uno's ISCP header, as the Uno's header does not contain the Slave-Select connection I need to hook up to the Reset pin of my 328P. That pin(pin 5 on the header) is not SS, but Reset. Does this sound right? Or can I get away with intuitively hooking right up to the Uno's ISCP header? It's so close to being conveniently perfect...therefore worth confirming.
In your linked guide you have the FTDI TxD hooked up directly to the 328P's Rx, while in this other version of yours you have a 10k resistor in series.http://www.gammon.com.au/images/Wire_Wrapped_Atmega132_e.pngIs one preferable to the other? Also, you have the FTDI CTS pin left open in the guide but hooked up to ground in the above linked schematic. Again, is one preferable? I find these are the little details that make it so I don't have to throw away my first prototype board.
That has been fairly carefully redone a few times to try to make it accurate. For example, it has the diode going from Reset to +5V.
The 10K resistor on the Rx line had a purpose, I can't totally remember what it was. My best recollection is it was for current limiting of the output from the FTDI device.
Tying CTS low was, I think, to be more accurate to the spec, for example:
If CTS# is logic 0 it is indicating the external device can accept more data, and the FTxxx will transmit on the TXD pin.
I don't think you need the FTDI port anyway, so both of those questions go away (and you don't need the diode). For low-volume programming just program via the ICSP header and forget about a bootloader and the FTDI interface. That is perfectly acceptable.
Does this sound right? Or can I get away with intuitively hooking right up to the Uno's ISCP header? It's so close to being conveniently perfect...therefore worth confirming.
No, you can't hook both the resets together. One chip has to be out of reset, and the other is programmed while reset is held low.
To program using the ISCP header, would I hook it up the same way as when I bootloaded it using the Uno? Or do I need to remove the 328P from the Uno and lose the SS to Reset connection?
What is the downside of this as opposed to using the FTDI cable?
I did a lot of work programming stuff on a custom board where there was no FTDI connection. I copied the sketch (.hex file) onto an SD card and used this project to program the chip:
You can use the FTDI cable if you want, you just have to program the bootloader once then. It just means slightly more complexity on the board. But if you pre-program the bootloader (and then put the chip on the board) then you don't need the ICSP header.
The ICSP programming is more low-level. You can use it to program a bootloader, or program the final sketch. You can also use a programming device like the USBtinyISP to do ICSP programming and then can program directly from the IDE.
You can get similar things pre-assembled, like the AVRISP mkII from various suppliers.
Yes, that is what I am saying. Programming a bootloader is just uploading code to the bootloader part of PROGMEM. To program a sketch instead you just upload to address 0, and set the fuses to make it start from there (and not the bootloader).
