KDS / Eclipse newbie could use some help getting started

[k64konfused]

Another technique is to use the final HW to interface with the SPI device but rather than have the complete application on the board just send each received packet (received via SPI) in a UDP frame to the simulator. The simulator runs the complete application with a UDP socket in place of the SPI interface so the real HW is an extension to it. Rather than sending generated frames to teh SPI they are sent in a UDP frame to the board, which passes it on to the SPI based device. Once application development is complete, remove the UDP socket and connect to the SPI HW instead.

Hi Mark, I'm trying to understand this approach still -- based on the terminology you're using, it sounds to me like you are proposing a mixture of physical hardware and the simulator.  I'd like to outline it in excruciating detail just to confirm that I understand what you're suggesting.

The way I interpret what you're saying is to have the Wiznet 5100 plugged into the FRDM-K64F, and write code to interface with it over SPI.  Everything that comes from the W5100 gets sent over the FRDM-K64F via UDP packets.  The FRDM board is connected to my PC, running the simulator, via Ethernet.  Everything sent over UDP gets to the simulator, which then executes whatever command was contained in the UDP packet.

When the command is executed (which could result in simulateddata, like reading a sensor), this data is packaged up in a UDP packet and sent back over ethernet to the FRDM board.  The board does whatever it wants to with the data.

If this is what you're suggesting, I like it, but the one problem is that the Wiznet chip is intended to be connected to another network.  By using a mixture of hardware and simulator, the hardware port I'm trying to test connect with another network would end up getting used up to send UDP packets to the simulator on my PC.  Perhaps it's my lack of understanding about how networks can be configured that is preventing me from figuring this out.

I also picked up that book you had recommended.  Thanks for that info as well!

[mark]

Hi

The uTasker TCP/IP stack can operate on multiple networks and multiple interfaces. This means that you can have more than one IP address (either sharing one physical MAC address on a single interface or with multiple MAC addresses on a single interface, or on multiple interfaces).
The K64 has one EMAC (for Ethernet), which is an "interface".

If you have additional chips supplying further interfaces you can have a TCP/IP stack integrated into it but this will then not be a real dual-homed solution since the two TCP/IP stacks are completely seperate and so you will need some application layer that acts as a 'proprietary' interface between the two. This may get a bit messy since each interface may have rather different APIs.

The other solution, which I prefer for consistency and simplicity, is to add a second 'dumb' interface that just does the work of the EMAC (be it an SPI-EMAC-PHY or WiFi interface etc.). This means that there is only one TCP/IP stack involved which already handles all internal details and the application interface is essentially identical for whichever interface is being used. The API is consistent and there is probably less code involved in total.
Unless there is a special requirement of the other TCP/IP stack I would also stick to a 'dumb' interface due to the fact that any extensions to TCP/IP will be valid for all interfaces - if you find that there is something that the TCP/IP stack in an intelligent Ethernet module doesn't do that you want [may be even a special feature] you are completely stuck without either changing the HW or asking the supplier to upgrade the SW to make it possible (could be a risk since it is not fully under your control).

The K64 has just one EMAC but if you need two complete Ethernet interfaces (for redundancy or multi-homed solutions you really only need to put in a Micrel KSZ8863 as PHY since this is a 3-port switch allowing 2 physically independent Ethernet connections to be created (costs may be $1 more than a standard PHY, plus a second RJ45 socket). This is supported in the project and allows it to be used as a switch (saving the need for external switches to attach multiple devices together or for redundancy) or as two controlable interfaces on a single EMAC (it has what is called tail-tagging operation which allows this and is supported by the EMAC driver). This avoids the need for further chips and SPI interface since all passes via the single MII interface!

Regards

Mark

[mark]

>>If this is what you're suggesting, I like it, but the one problem is that the Wiznet chip is intended to be connected to another network.

The principle is correct.
However the UDP frames are sent over the K64's Ethernet connection and not over the other network so this should be possible without any other impacts.

The idea is to have the main application (where the development work is at) on the PC in the simulation environment and just have final HW doing an interface extension (link between the API and the real HW).
Once all application development has been completed just build it for the HW without this simulation link (rather than [Application<->UDP in simulator]<-Ethernet link->[UDP<->SPI<->Ethernet on HW] it does [Application<->SPI<->Ethernet on HW] and should essentially operate identically (but already developed and debugged).

Regards

Mark

[k64konfused]

The K64 has just one EMAC but if you need two complete Ethernet interfaces (for redundancy or multi-homed solutions you really only need to put in a Micrel KSZ8863 as PHY since this is a 3-port switch allowing 2 physically independent Ethernet connections to be created (costs may be $1 more than a standard PHY, plus a second RJ45 socket). This is supported in the project and allows it to be used as a switch (saving the need for external switches to attach multiple devices together or for redundancy) or as two controlable interfaces on a single EMAC (it has what is called tail-tagging operation which allows this and is supported by the EMAC driver). This avoids the need for further chips and SPI interface since all passes via the single MII interface!

So basically this means I'd have to make a new board based on the K64F, but replace the current MAC/PHY with the Micrel part that you have recommended, and then uTasker would immediately be capable of multihoming using two different interfaces?  That sounds like a much better solution than adding the W5100 or even an SPI-based MAC/PHY, but since I'm not an EE, I have no idea how to evaluate the complexity.

That's definitely something to think about, but let's say that I want to use temporarily evaluate uTasker with a middle-ground solution and pick up a Micrel SPI MAC/PHY like the KSZ8851SNL.  Is uTasker already capable of interfacing with a chip like this out of the box?

EDIT -- another interesting question I have is that if uTasker is capable of handling multiple interfaces and the 3-port switch that you had referred to earlier, can it handle even more connections?  In other words, rather than having one interface that talks to my PC and the other that is connected to another network via a switch, couldn't I remove the switch completely and instead use a Micrel chip that supports, say, 8 internal connections?  I found this as an example: http://micrel.com/index.php/en/products/lan-solutions/switches/article/20-ksz8999.html

[mark]

Hi

I find the Micrel KSZ8081RNA to be the best match for simple one port interface since it allows a single 25MHz crystal to be used for the complete design (the PLL in the PHY is multiplied to 50MHz to supply the Kinetis oscillator input).
Whatever PHY you are using there are reference designs at Micrel and all you need to do is contact an application engineer there and they will review a design to ensure that it is all correct - so there is little risk involved.
I never used the KSZ8863 but all PHYs have a basic IEEE register set so usually all will "basically" work with little effort.

If the processor that you use has an EMAC (Ethernet controller) I don't really see any need for using an external Ethernent controller unless you have no TCP/IP software and want to use the one built into the chip (don't forget you are paying for this SW then in the chip's price and so paying for each device and not a single royalty), even when a multihomed design is needed and the processor has only one EMAC (due to the 3-port switch's capability to simply make it look like two). The SPI throughput will aways be lower than the EMAC's and so lower performance.

If the processor has no EMAC built in it may make sense to use something connected via SPI (I would look at the Microchip ENC424J600 in such a case since it is low cost and I expect to have it supported in the uTasker project shortly) but often it is simpler to directly put a processor with EMAC in in the first place.

I don't think that the KSZ8999 allows controlling sending Ethernet traffic to specified ports (on a per frame basis) so this is probably not suitable for an 8 interface multihomed solution as such (more for simple managed switches etc.). Micrel may have newer ones that do support the tail tagging mode which can be used to achieve this.

Some details:
Tail tagging simply involves the processor specifying which port a frame is to be transmitted on by tagging on extra control bytes at the end of the frame (eg. to send to port 0 or port 1 only, to send to both or to send in switch mode). On each received frame the switch adds a byte to the frame so that the processor can read on which interface the Ethernet frame arrived on. This means that the SW works as if it has more than one Ethernet connection and there are physically more than one in the HW. This is simply sharing the single MII but otherwise operates as true multihomed HW. The SW does this with a hand-full of extra lines of code in the Ethernet driver and otherwise looks like a true multihomed architecture.

Regards

Mark

[k64konfused]

Hi Mark, I think all of my questions are causing things to get a little confusing.  Let me present a simple overview of what I am trying to achieve:



My goal is to have the simplest implementation for two NICs possible with uTasker.  The FRDM-K64F block in the diagram doesn't necessarily have to be that board -- I could attempt to create my own board based on the same processor and add my own ethernet (dual) MAC/PHY of choice, but it's not the easiest option.  However, I still have to consider that to make integration using uTasker more seamless.  So I have two routes:

Use the FRDM-K64F
In this case, I would use the MAC/PHY currently onboard to talk to Network 2 in the diagram.  I would then have to pick an SPI-based MAC/PHY (likely from Micrel) and use the uTasker TCP/IP stack to communicate with the PC in the diagram over Network 1.  Do you already have support for the Micrel SPI=based KSZ8851SNL?  If it is not supported, then another, less desirable approach is to use the Wiznet 5100 and implement the SPI communication code to talk to the PC.

Use a custom board with same processor and replace the MAC/PHY
In this case, instead of using the MAC/PHY selected for the FRDM-K64F, I would select another suitable chip from Micrel.  Since I need two separate network interfaces (one to talk to the PC, and the other to talk to the switch that's connected to all of the devices in the diagram), I would need to pick something with more than one interface (i.e. KSZ8081RNA is not suitable, right?), like the KSZ8863.

Does this sound about right to you?

At this point, I do not think I need to route Ethernet traffic to specific ports if I delegate this sort of task to an internal off-the-shelf switch.  However, it would still be nice to eliminate the extra hardware if something like the KSZ8999 is sufficient.  Unfortunately, my knowledge in this area is pretty limited, so I appreciate your comments and feedback, as well as the extra info on tail tagging, which will help me to do more searching and learning about the subject.

[k64konfused]

I wonder if the Freescale Tower Board (TWR-K64F120M) is the right way to go, so we can more easily get access to RMII...

[mark]

Hi

I don't see the diagram but I am wondering whether you need two physical interfaces at all, especially as you write about not needing to be able to control the port that a switch would use.

There is no logical difference between a switch connected to multiple devices (each with their own IP and MAC and physical Ethernet connection) and a single Ethernet connection with multiple IP and MAC addresses.

If you don't physically need to sperate the networks so that no traffic is visible on the other Ethernet ports (eg like a router between two physically sperate networks) you can do it with a single Ethernet interface; the operation is controlled purely in SW.

A switch will simply allow one cable to be connected and will reduce traffic on each cable since it will not transmit frames if it knows that the destination is not situated there. The switch can be local (using a switch rather than a PHY) or simply connected to the Ethernet port externally.


If you need to add a three port switch (or other variation) rather than a simple PHY it woud be more practical to do this as prototype using a tower kit (than the FRDM-K64F) since you can add a prototype board with the PHY on it in place of the TWR-SER board (with the simple PHY connection on it).

Regards

Mark

[k64konfused]

That's strange, I can see the diagram two posts up on all of my PCs!

Regarding the separation of networks - while I technically do not need to direct specific frames to specific ports on the internal network, it would be nice to not needlessly send data to every device on the network.  I do need to separate the PC from the devices -- they cannot be on the same network, so that's why I need two interfaces.

It does sound like the tower board is the way to go for further development.  It looks like uTasker support for it is the same as the FRDM-K64F, so that is good for me.  I'll order one and give it a go.

Thank you!

[mark]

Hi

With Chrome I can see an image icon that I can then link to so I have now seen the diagram.

If you want the PC to be connected to network 1 and physically seperated from network 2 you do need the two interfaces.

You can however alread test the complete operation by connecting the PC (configured to be on the 10.10.10.x subnet) to the 8-port switch and configuring the FRDM-K64F to have IP addresses on both the 192.168.0.x and 10.10.10.x subnets but on its single Ethernet interface (either sharing a single MAC address of using two different ones). When the second Ethernet interace becomes available (in HW and the SW driver for it as well) it can then be reconfigured to do the same but on two seperate Ethernet interfaces.

Regards

Mark

[k64konfused]

Thanks, I will try that tonight.  Does uTasker support the TWR-SER2?  It has two interfaces, which would be great for me so I don't actually have to attempt to design anything.

[mark]

Hi

The TWR-SER2 is supported (enable TWR_SER2 to select it rather than the TWR-SER board) but I haven't tested it together with a K64 tower board (possibly the configuration needs to be copied from a different processor (?)).

However the TWR-SER2 has 2 MII interfaces to 2 PHYs and so the Kinetis boards can "still" only use one of these. The TWR-SER2 is intended for connecting to devices (such as some bigger Coldfire ones) that contain 2 complete Ethernet controllers in them.

Regards

Mark

[k64konfused]

You can however alread test the complete operation by connecting the PC (configured to be on the 10.10.10.x subnet) to the 8-port switch and configuring the FRDM-K64F to have IP addresses on both the 192.168.0.x and 10.10.10.x subnets but on its single Ethernet interface

Hi Mark, just to clarify the implementation portion of this, am I correct in assuming that this is done by setting IP_NETWORK_COUNT to 2 and then setting the properties for the 2nd subnet in network_default_1?  In addition, I leave IP_INTERFACE_COUNT as 1 until I eventually get the second interface, after which I would set it to 2?

[mark]

Hi

Yes, by setting IP_NETWORK_COUNT to 2 will add a second network address.

Search the project for
#if IP_NETWORK_COUNT > 1
to see where additional settings are made (like the second network configuration) and you can also see the locations where this has an influence. The present Kinetis release (1.4.7) does contain a working setup for 2 networks as it is (it will allow operation on 192.168.0.3 and 192.168.0.4).

Later IP_INTERFACE_COUNT can be incremented. Don't do this just yet since it is a bit more involved and I have seen that the present release has a couple of settings missing that cause errors - I will be using it shortly so it will be resolved by the time you need to start with it.

There is no (released) document covering all of this yet but I will be working on it too.

Regards

Mark

[k64konfused]

Regarding the test with the FRDM and multiple IP addresses with a single interface, you are basically saying this, right?  (see image below)



Honestly, I have never once tried hooking up devices that are on different subnets to the same switch.  All of the networking tasks I've done before just involve hooking up my home PCs to the same network!