|
I'm currently looking for an interface to run large numbers of sub-controllers (they will be controlling heterogeneous devices) from a single point of connection to a main computer. The bandwidth requirements are likely to be extremely low: In the order of 100 bytes/s at peak. The architecture that I've come up with involves a USB interface to a multiplexer, which can connect to other multiplexers and then to the final devices in a tree-like manner (number of endpoints needs to scale to 100s). Ideally, the endpoints would be left to do their thing and then report back to their master with an interrupt. I'll be using xmegas for this so I have about 34 pins for IO and would quite like to be able to run about 8 devices per multiplexer. The architecture I have in mind would therefore benefit from having device-select and interrupt share a line and then have a data bus shared between all sub-devices, with a similarly common clock. Questions: 1. Is this a stupid way of designing a scalable system. It really does need the ability to just bolt on more and more devices over time: Hence the tree architecture. 2. Is there any kind of interface standard that would fit the bill? Given the limited number of in-built com subs on each chip, I'm quite open to bit-banging, which should be ok given the low bandwidth requirements.
|
#
¿
Apr 10, 2013 23:03
|
|
|
|
| # ¿ May 11, 2024 11:35 |
|
|
movax posted:So if I understand correctly you have: Not sure if you're on the same wavelength so I'll clarify: Computer -> USB -> Root master -> sub masters 1..8 -> "Sub nodes" 1..64 (assuming 8 of the mulitplexers/sub masters) Each master node / multiplexer would cost peanuts, since I intend to use a cheapo Uc for each one and IDC connections. From what I understand, SPI doesn't allow the slave to initiate a data-frame, which would necessitate poling. I guess that would be ok but interrupts would be preferred. CAN/LIN does look the business however, it seems to be pretty much what I'm looking for and there seem to be a few AVRs with hardware support. Cheers.
|
|
#
¿
Apr 12, 2013 19:01
|
|
|
Otto Skorzeny posted:You might want to use the 2515 + 2551 or similar with a regular AVR rather than the 2551 (or some other CAN transceiver) with a CAN-capable AVR . They're pretty easy to use and it's more cheap poo poo to blow up if something is miswired instead of blowing up your micro This is perfect. I had hoped to use the xmega architecture (familiarity more than anything) but I don't think there is a CAN-enabled xmega available. This should solve that little problem. Thanks. movax posted:Or, you could calculate all the capacitance / cable length values and just make everything a CAN node. I really want to go with something scalable. Having something so monolithic doesn't fit well with the plan to eventually have hundreds of sub-devices. The hierarchic modular approach should allow quite a bit of positional flexibility too, since each 'plex is acting as a repeater too (The final apparatus will likely be spread over multiple fume-hoods in a chemical laboratory.) Active Quasar fucked around with this message at 03:58 on Apr 13, 2013 |
|
#
¿
Apr 13, 2013 03:55
|
|
|
armorer posted:I personally prefer to code on linux, and I fully intend to learn my way around the gnu toolchain for AVR development. At the moment though I am using AVR Studio because I can only learn so many things at once and I am focused elsewhere. I know it's a bit atypical, but I actually have a MBP for work. When they decide to replace it for me I am going to get a thinkpad too because (a) the MBP keyboard drives me nuts and (b) I would rather just have a linux box. So far I've done all my AVR coding on linux having taken one look at AVR studio bloat and noped right out of there. The import thing to bear in mind is that support for XMega architecture is hilariously broken in pretty much every OS bundled, and AVR source distributed, version. The oficial AVR binary distribution works perfectly however, so no bother but learning that cost me a few hours. Apart from that, gcc and avrdude has been running without problems. LUFA handles all the complex peripheral stuff, although it has a "somewhat" quirky build methodology, and the rest is simple enough to bash out onto the registers.
|
|
#
¿
May 24, 2013 23:25
|
|
|
Is anyone actually maintaining Avarice, these days? We've put together a bunch of patches to get various revisions of XMegas working and I have no idea who to send them to for incorporation...
|
|
#
¿
Feb 23, 2014 17:15
|
|