NetBurner Community Forum

I am considering combining two and possibly three NB modules into an embedded device. All the modules would physically connect via J1/J2 to the same I/O board for serial , RTC, headers, power supply, SD, sensors, and add'l IO etc. Can folks weigh in on easy ways for the individual modules to share data, probably via UDP as shared structs? The question is not so much the code to allow data sharing (again, probably via UDP), but instead the hardware. Sounds like I need a small, board level switch to connect the modules via ethernet, and also to provide a connection for the group to an external network. Can anyone recommend a small, board-level switch, say with 2-3, or 4-5 ports that could be built into our widget? Is there another way to share data that would avoid the switch? SPI might be a method, but on most of the modules it is pretty tied up reading and writing files to SD. Avoiding a switch would be nice!

Thanks.

You can use regular system bus at J1 to share memory.

Hi Yevgeni: I could see J1 bus-mapped IO for two devices talking to each other... The ModDev100 schematic shows that kind of latched 16 bit interface hardware. Any idea how to set it up so that when one processor writes, it generates an IRQ signal for the other device to read? That would be a start.

Next question is how to make it work between several modules... Maybe the CS* pins to the enables of individual buffers or to a '138 for a few add'l modules? You can tell hardware is NOT my thing!

Even with this suggestion, I'm still interested in board-level ethernet switches as I'd certainly need a way to download code to each module anyhow... It would be nice to find some small (cheap!) 2 to 5 port industrial switch pcb rather than tearing apart some netgear / D-Link thing that's subject to constant change and non-availability...Any ideas?

Signals at J1 connector allow to arrange multiple-port memory (with some addittional logic). You can place here the data to share between the NB modules.

Ridgeglider wrote: Any idea how to set it up so that when one processor writes, it generates an IRQ signal for the other device to read? That would be a start.

Connect "R/*W" signal (unite it with CSx of the multi-port memory) to IRQy.

Ridgeglider wrote: Next question is how to make it work between several modules... Maybe the CS* pins to the enables of individual buffers or to a '138 for a few add'l modules? You can tell hardware is NOT my thing!

The additional control logic is quite simple. But, I have no ready principal diagram of this circuit. It is some hard to explain details of the bus interface arbitration for non-hardware man.

Ridgeglider wrote: I'm still interested in board-level ethernet switches as I'd certainly need a way to download code to each module anyhow... It would be nice to find some small (cheap!) 2 to 5 port industrial switch pcb rather than tearing apart some netgear / D-Link thing that's subject to constant change and non-availability...Any ideas?

Downloading the flash can be arranged with any commercially available cheap ethernet hub - especially for those, which have no experience with hardware design.

A few options:
- You could go to a RS-485 scheme with the uarts, but much more work than udp because you need to create the protocol.
- How many are you going to build? If less than 100, then find a off the shelf switch that works and buy enough for your needs.
- I have seen companies that sell a chip that implements a 3 or 5 port switch. You could get one of these and design it into your board that is connected to all the modules. This might not be too risky if the vendor has a reference design.

rnixon: thanks.

Your idea to share data via RS485 won't work in my case although it might work in others. The reason is that our current 5234 design is sucking in data from 6 or 7 sensors over a combination of '232, '422 and '485 serial ports (3 or 4 via the eTPU). Data from these ports is written as raw streams to SDcard, then parsed to several large structs of variables and made available to the rest of the system as safe objects. The rationale for considering separate NB modules is to off-load that work. It seems like it might be easy to publish the resultant data objects over UDP to other modules that need the input to perform some control functions.

Therefore, we're definately thinking of incorporating some small off the shelf switch to tie modules together, but we simply wondered if anyone could recommend specific board-level products or vendors for 2-3, or 4-5 port 10/100 ethernet switches? I know there have to be some board-level industrial products but can't seem to locate them. I've already used some generic netgear stuff but I'm tired of throwing away wall-wart and enclosure and always being subject to a shifting and (for these purposes) undocumented detaails like mechanical footprint, input power requirements, etc.

Any suggestions would be appreciated.
Cheers.

You could add an FPGA. The FPGA would implement multiple SPI interfaces, one for each NB. Each NB would be able to read/write it's own data as well as read the other NBs data via the SPI. Each NB would have addresses in the FPGA: NB0 addresses 0 to 99, NB1 addresses 100 to 199, etc. NB0 could read/write it's own address, but would only be able to read addresses associated with the other NBs.

Bill, Thanks. The FPGA route sounds very clean. However I keep thinking that if I have multiple modules, I'll need a switch to conect to them for code download anyhow. If so, I get the UDP transfer w/ zero extra hardware cost. Although the FPGA throughput would be much higher, UDP throughput should be fine albeit with less deterministic timing. So, I'm still looking for that simple (but apparently hard to find!) board-level swtch. Thanks again!

I have used Micrel Ethernet switches in my designs, they have worked well and Micrel has good documentation and support.

http://www.micrel.com/page.do?page=prod ... her_sw.jsp

Dear R*G*:

I am wondering why you want to multi-up the NB modules. Is it a bandwidth thing or a physical I/O thing or a redundancy thing or??? I would tend to add hardware and leave one module. I think it is a bad idea to connect multiple ethernet-atttached modules using interface electronics 'cause of what you are said-one would need to connect all modules to the ethernet anyway to upgrade code. If you need to connect them to the ethernet through a switch, then it is pointless to connect them in any other way unless you are planning a high-bandwidth parallel process that all processors get a piece of. So, what's the reason for multiple NB modules?

Chris