Implementing just the MAC/PHY for communication between boards

[jarispe]

Hello everyone,

I want to see if you guys would help me figure out a little more on how to accomplish this. I'm use a Kinetis K60 Tower board and I want to set up communication between them using ethernet MAC only. Is this possible without setting up a higher software layer for TCP/IP? Basically for this project I want to be able to receive data from UART or a file from an SD card, user ethernet to transfer the data to another K60 and send that data out via UART or store it on an SD card.

Right now I'm having trouble finding out how to put together the frames correctly. I used Processor Expert to generate code for the ethernet component to learn more on how it works. I mostly understand it but one thing I simply can't find is how to set the destination address of a frame. The RM talks about this being part of the frame and that it's needed, but I can't seem to find a register that writes this part nor does it seem to be part of the buffer ring descriptor.

Also, is there any way I can see the actual code for some of the PE modules? I found that this is one for reading a file as binary and it breaks it down into a byte array, which I think would actually help me in this application.
Thanks for your help in advance!

[mjbcswitzerland]

Hi

It is quite unusual for TCP not to be used for data transfer but communication with the K60 over Ethernet is also possible without the higher layers in the SW.

For your Ethernet destination question it is best to read about the Ethernet II frame: https://en.wikipedia.org/wiki/Ethernet_frame#Ethernet_II whereby it means simply that the first 6 bytes that the software prepares for the first buffer descriptor is the destination address.

For high speed and reliable communication between K60s in a LAN without TCP/IP there is already a solution: http://www.utasker.com/docs/uTasker/uNetwork.PDF

This allows boards to communicate with each other (including automatic frame repetitions in case of data loss due to interference) and even allows a single software application to be distributed over multiple K60's in a network, whereby tasks in the distributed system can communicate between each other without needing to know where the other task is physically located.

There are however also various UART<->Ethernet<->UART type configurations that use a TCP socket between them which would tend to be the more general choice.

In either case you could also look at the uTasker project for K60 since it includes all of the things that you need (whichever network technique is decided on) and allows you to configure and test the complete operation (including UART, SD card and the network commuication between two or more devices) in its K60 simulator. With the necessary configuration and a little application control to manage the data I would expect a project of this scope to be basically operational within around half a day of work (assuming some experience is already available with the environment).

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

K60: http://www.utasker.com/kinetis/TWR-K60N512.html / http://www.utasker.com/kinetis/TWR-K60D100M.html / http://www.utasker.com/kinetis/TWR-K60F120M.html

For the complete "out-of-the-box" Kinetis experience and faster time to market

[jarispe]

Thank you for your reply Mark.

I've come across uTasker while searching the forums previously and it seems like it might be a good choice.

But I'm still compelled to code all these functions myself or at least understand them thoroughly. I know that the first six bytes are the destination address and the rest of the padding is created by the MAC, but my question still isn't answered. You pointed me to the information and said the software does it. If I'm the one writing that software, how would I do it? I want to know how it works completely tool free. So far I've understood most of how to prepare and send a frame, it's just this simple process of defining a destination address. That's the information I'm most after.

You mentioned that the software writes this in the first buffer descriptor, but I don't see a field for it. Unless there's another descriptor I need for that?

Any more help would be greatly appreciated.

[mjbcswitzerland · Accepted solution]

Justin

If you code these functions from scratch your are looking at maybe 2..3 months of work for the complete application that you have described and possiby more until your have achieved complete reliability and solved all development bugs/issues not initially anticipated. Therefore it is usually only of interest to recode all if you are doing it for study purposes where the process rather than the result is the main goal. I note that you have started using PE for some code generation which is however contradicting your statement because this is also giving you black-box like code (with less visibility).

Even if you don't want to use the uTasker solution, which would allow you to complete the entire project in a couple of days, you can still use its simulator and code base to analyse the operation. Then you could simply learn all internal workings of peripherals and protocol stacks by stepping code in the simulator, reading the intensive comments which explain how it operates and monitor the peripherals registers/behaviors with little need to consult the user manual to understand how it all works together.

To your question about the Ethernet:

You have shown the TxBD in enhanced mode (to use this one the enhanced mode needs to be enabled, but its basic operation is similar to the standard buffer descriptor too).

- TxBufferPointer points to the frame that your SW needs to prepare - this must be 8 byte aligned. (This memory is the buffer descriptors actual frame buffer memory)

- The destination MAC address is written to the first 6 byte of that buffer (not the Buffer descriptor itself).

- After the MAC address (in the frame buffer memory) you fill it with the other values in the Ethernet II frame (including your own MAC address too) and then with your own protocol payload (or IP/TCP etc. with payload)

- You must ensure that there are at least two Tx buffer descriptors chained otherwise the frame will be sent more than once (see errata).

- You must also provide the buffer descriptor memory, which must be 16 byte aligned.

Regards

Mark

[jarispe]

Mark,

Thank you again for your reply,

Actually, part of this project is to develop functions from scratch more or less. At least, we need access to the lowest level of code in order to make changes if needed because the project itself is not a normal case. We may need to implement error correction other than what the MAC provides. (The transmission isn't going to be over wire or wifi, but another medium we're researching) So the time for development is ok. I understand the concern to waste time redoing work that's already been done and available.

These points are exactly what I was looking for. I think I'll be able to move forward with it. Thank you for taking the time to answer my questions.

[mjbcswitzerland]

Justin

The EMAC gives you CRC-32 so should be adequate in a local area network. This should be independent of the media transfer you use.

The EMAC in the Kinetis further supports check-sum offloading for typical protocols like IP, TCP and their payloads on top of this so it may still make sense to stick to a standard protocol to be able to benefit from this since it is several times more efficient than doing it in SW.

Regards

Mark