0
\$\begingroup\$

I'm working on establishing communication via ethernet between 2 microcontrollers.

Its a stand alone system. Controller1 will interface with the user via a keypad. Controller2 will be interface with a couple of motors(via drivers). When Controller1 receives keypad presses it will request controller2 to carry out certain motion tasks.

The block diagram will be(standard circuit): Controller(with an in built MAC) --- PHY --- transformer -- RJ45 and the same repeated on the other controller board.

What I'm trying to understand(from the firmware perspective) is whether I really need to get into all the abstraction layers (upto http), will my controllers need an i/p assigned, etc.

Assume that these are the only 2 devices interacting. Is it sufficient to have the code working up to only the data link layer. i.e I configure the MAC registers, each controller having its own MAC address and the communication is done via the ethernet frames with no higher level layers involved.

Working with ethernet for the first time so apologies if there are any basic errors in the query. All the forums mention using tcp/ip stacks, ip addresses but its not clear to me why that is needed.

\$\endgroup\$
  • 1
    \$\begingroup\$ We can't possibly tell when we don't know what end result you're trying to achieve. Please update your question to include that information. \$\endgroup\$ – user17592 May 6 '13 at 8:07
  • \$\begingroup\$ Have added a brief description of the end goal in italics. \$\endgroup\$ – Rustin May 6 '13 at 8:26
  • 1
    \$\begingroup\$ Why ethernet? Why not Rs485 or similar and simple basic serial link? \$\endgroup\$ – Spoon May 6 '13 at 8:27
  • 1
    \$\begingroup\$ If you go with IP networking, I'd strongly, strongly, suggest that you also develop programs which run on a PC and can substitute for either of the embedded devices. (Actually, what I would really do is make it so that the firmware can be built for a PC, interfacing to ethernet and with simulated or buttons-on-screen type I/O). This will prove itself of value over and over again during development and early testing, let others in your organization get hands on with the design even before you have the first hardware prototype, etc. \$\endgroup\$ – Chris Stratton May 6 '13 at 15:31
  • 1
    \$\begingroup\$ Easiest is to pick a Ethernet controller that has built in TCP/IP offloading. They are probably a bit more expensive, but it saves you a lot of work, programming SRAM and FLASH. \$\endgroup\$ – jippie May 6 '13 at 19:11
2
\$\begingroup\$

The basic answer is that you can do whatever communication you want to do.

Every chip which has an ethernet component to it can do simple phy-to-phy communication (i.e. layer 1 if we're talking about the OSI model), and unless your chip has a built-in IP stack or AX.25 layer or some other type of level-2/3 (i.e. data/network abstraction) layer baked into the silicon, this is what you will have to use.

The hardware is capable of doing some part of the ethernet protocol, whether this is 10BASE-T, 100BASE-T or whatever, and if you add an IP-layer your software stack will utilize that functionality. You can use that functionality directly!

Most people choose to put some sort of IP layer with TCP or UDP communications because this helps hide some of the complexity, and makes the code work the same way on their computer as it does on the chip. It also means that things like putting an ethernet switch in the middle of multiple circuits will work, and many other niceties that comes with using a professionally developed standard that a lot of people have thought about and tested. You don't have to do this if you don't want to, and it will save you a lot of complexity and processing power if all you're doing is sending simpled sequential messages from one circuit to another though.

I agree with @Spoon though, in that I think you should pick a different protocol if you're using simple point-to-point communication. If there a reason you're not using RS-485, RS-232, I²C, or some similar simple serial protocol? A lot of those will likely be easier than using ethernet.

Good luck!

\$\endgroup\$
  • \$\begingroup\$ Well, I found out sometime back that there is a possible third node in the design and that runs tcp/ip. Otherwise, yes it makes more sense to go for simpler protocols. I was hoping to reduce the overhead memory that would be used, but am sticking with the recommendations to go with the standard. Thanks for the answer! \$\endgroup\$ – Rustin May 6 '13 at 9:27
  • \$\begingroup\$ Even a third node can be handled by RS485 ... but if my boss said I have the choice.. I'd go with ethernet cos it is so much more useful on your CV :-) \$\endgroup\$ – Spoon May 10 '13 at 23:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.