I/O co-processor over I2C

[Iksbob]

Hey folks.

Let me start with a little background:
While brainstorming on my trim encoder wheels project (link to topic in er9x forum), I got to thinking about a more universal method of implementing the wheel-reading code: add a low-dollar chip such as an ATtiny to read the trim wheel(s), and simply pulse the appropriate trim switch input when the wheel is moved. To the 'mega64 on the main board, it would look just like the stock trim switches, but only ever getting clicked one notch at a time. The first issue that came to mind on that was how often does the software check those switch inputs? How long would the pulse from the wheel chip have to be, and what limit would that put on wheel rotating, and corresponding trim adjustment speed?

That got me thinking about a more efficient way of getting the two chips to talk to eachother - I2C sure would be nice. That's when I had a wait-a-minute moment. After a few mins checking the 'mega datasheet, I found PD0 and PD1 can be configured for hardware assisted I2C. I knew most of the I/O pins are already used, but I thought I'd check anyway. Turns out the pins are in use... By the aileron trim switches. Two of the very switches I'm looking to move to this new chip, leaving their pins open for use.
So, my thought is to move all the trim switch/encoder wheel lines to I/O pins on this coprocessor chip, and have it pass trim adjustment values back to the 'mega64 when pinged over I2C. Among the other pins freed up is PD4, which has interrupt trigger functionality. This could potentially let the coprocessor force an update, or at least get the main processor's attention if something high-priority is happening on the coprocessor.
PD2 and PD3 can also be used as interrupts, or TX/RX pins for the second USART. This could let the main processor talk to a PC through a simple USB-TTL serial adapter.

However, from a hardware mod standpoint, the biggest gain is the I2C bus. A single 2-wire bus can support up to 128 devices - think of it as USB for ICs. Small, inexpensive I2C eeprom chips could be put on the bus to add model memory or enable data logging, additional display modules could be put on the bus, 'dumb' I/O expanders, 'smart' coprocessors, lipo charge/monitor circuits, really the sky is the limit.

Anybody with me on this one?

[cre8tiveleo]

skyboard... simple

[jhsa]

I knew you were going to say that... was just waiting..

[cre8tiveleo]

I knew you were waiting for it, I didnt want to dissapoint...

[MikeB]

Generally a good idea. Unfortunately, particularly with the FrSky version of the code, we are pushing the limits of what we can squeeze in to the mega64, hence the suggestion to use the ersky9x board to get all these extra functions.
We also need to consider how many users will do this sort of mod. Many users (over 2500 apparently) have reflashed their 9x's by purchasing the SmartieParts board which is a solderless programmer add on. I believe many of these would not have done the upgrade if they needed to do soldering for it. So to achieve this sort of add on really needs it to be an easy mod to achieve.
SmartieParts are in the process of producing a prototype run of the TelemetrEZ board. This addresses some of your ideas. It is intended to be a near solderless method of implementing the mod to allow use of the FrSky telemetry. In doing this, it provides a co-processor connected to the Mega64 via the serial port used for the telemetry. This co-processor also has some spare I/O that is not allocated to any specific function (yet).

Mike.

[Iksbob]

Hmm.
Well, an I2C + USART adapter board could be solderlessly installed at the main board connector for the right hand trim switches and gimbals. The gimbal analog signals would simply pass through the adapter (acting as a simple jumper) while the trim switch signals would be intercepted and handled by the adapter board co-processor. I haven't read much about the details of the "official" telemetry mod, but I would think using an existing hardware USART to handle the serial traffic would free up a fair amount processor time and memory. Since these USART pins are already available on a header (ele trim switches), it could make the telemetry mod a truly solderless mod.
[edit]
Yeah, ok; it looks like the current mod uses USART0 instead of the USART1 available via the trim/gimbal connector.
I'm not sure how far along SmartyParts is in the design process, but could the TelemetrEZ board be designed as a replacement rear panel PCB? There's gobs of unused space on that board, and it would let you add an external connector to the rear panel immediately adjacent to the transmitter module. Then internal mods to the module would be unnecessary - just plug a 2" jumper from the stock module connector to the rear panel connector.
[/edit]

[MikeB]

See viewtopic.php?f=23&t=994, prototypes already exist.

Mike.

[Iksbob]

Huh. Similar idea, different connectors from the looks of it.
I guess the processor selection is for the sake of space saving and cost reduction? I can understand keeping it small when you've got the add-on board mentality (it's gotta fit in the available internal space), but replacing a relatively large and low-complexity board (like the rear PCB) sidesteps these limitations. The rear board could easily accommodate a second 'mega64, though at $7 and change a piece, it's admittedly a good bit more expensive than the prototype's ATtiny (around $2). But if you're getting custom PCBs made (not a small expense judging from the price hints here), why cheap out on the one thing that makes the board worth while? IMO, such a prototype board should provide a good bit of room for expansion and creativity - go up a step or two from what the creator needs, breaking out the unused pins to solder pads and such.
But then, I guess the goal of the TelemetrEZ board is to provide a product that solves one problem... That problem is apparently not the hardware limitations of the '9X platform.
Sigh. [/rant]

[Kilrah]

Have a read through the TelemetrEZ discussion. Yes it's designed for just one thing, add telemetry without requiring soldering (initially 2 easy solder points, then 0 with the new programmer board), with a very low cost.
The back board unfortunately has the shoulder switches/pots soldered to it, no connector, so replacing it wouldn't have the expected simplicity.
Cost needs to be low so that the SP programmer + TelemetrEZ combo is still significantly cheaper than the ersky9x replacement mainboard - which is as easy to replace (only a few plugs) and can do all that plus a whole lot more - so Steven didn't want to add other potential features that would drive the cost up for some people who won't use them.

It does have a few free I/Os and an open source firmware in the making though, so it should be no problem to add a rotary encoder or other things.

[Iksbob]

Cost needs to be low so that the SP programmer + TelemetrEZ combo is still significantly cheaper than the ersky9x replacement mainboard

That's not exactly a small window though. What bugs me about the ersky project is not just the high price tag, but that it seems to have put an end to er9X development.

[Kilrah]

What bugs me about the ersky project is not just the high price tag, but that it seems to have put an end to er9X development.

Huh? And what about the voice mod for er9x that has been a big focus point for the past few weeks?

[Iksbob]

Huh? And what about the voice mod for er9x that has been a big focus point for the past few weeks?

Where's that?

[Kilrah]

Probably the most active thread at the moment...

Audio (voice) - Stock 9X PCB

[jhsa]

No, er9x development is not stopped at all.. Just not as fast as open9x for example.. Mike is doing it alone.. Plus he has a real life as well, so we just have to be a little patient and wait.. and this is only a hobby for all of us.. so we wait and then when something new comes out we just check the new wonders.

[MikeB]

Iksbob: I'm doing what I can for er9x, ersky9x and eepe (and TelemetrEZ), and trying to find time to update the manual. Most of what has been added to ersky9x I've also managed to add to er9x as well. A couple of paid jobs are also needing time!
The stock board is close to its limit for flash, EEPROM and RAM usage, so often, in order to add something new in, I have to try to make the code or RAM usage smaller first.

Mike.

[Iksbob]

Iksbob: I'm doing what I can for er9x, ersky9x and eepe (and TelemetrEZ), and trying to find time to update the manual. Most of what has been added to ersky9x I've also managed to add to er9x as well. A couple of paid jobs are also needing time!

Yeah, I guess I'm just being impatient. I'm not entirely sure where (if anywhere) discussion about new features and work in progress is happening. Is there an er9X change log somewhere?

[MikeB]

Look on the er9x code site, there is a changelog.txt file in the trunk.

Mike.

[Helle]

Hy,

I think i/o co-prozessor via I2C is a good solution
we can get more analog inputs 4-6 more for funktions modell
we can get more digital inputs 6-8 switches for funktions modell
we can than use this inputs to the Channels 8-16 for real outputs

i/o co-Porzessor can do lots of other things itself, save flash at the mian -processor
more as one rotary wheel
we have much more memory and eeprom
we can use ready and cheap hardware, arduino nano modul for 8€
we can use SD-modul
we can use Voice-modul
and so on.


Helle

[jhsa]

telemetrEZ or the new sound module but this one only has 3 pins available