Ethernet TCP/IP and Teensy C

[uTasker]

Hi All

As an experiment I have connected a Microchip ENC424J600 (10/10M Ethernet) to a Teensy LC:
http://www.utasker.com/kinetis/TEENSY_LC.html#LAN

Due to the fact that the device hasn't a great deal of code space and its RAM is limited it was not possible to activate all features but I wanted to mainly prove that it could work in parallel with an SD card sharing SPI0 (and switching SPI modes and speeds on the fly). So I set up

- USB-CDC and command line menu
- SD card and FAT
- Ethernet with ICMP and UDP, with DHCP, Netbios and SNTP clients
which allowed the operations to be verified.


In comparison, I recently did something similar for the Teensy 3.1:
http://www.utasker.com/kinetis/TEENSY_3.1.html#LAN
which has lots more Flash and RAM space so allowed a configuration with full features.

The main difference between the K20 on the Teensy 3-1 and KL26 on the Teensy LC with respect to the SPI is that the K20 can automatically share two SPI modes and speeds thanks to its SPI0_CTARx registers. But at the end of the day it is possible to achieve the same functionality with both devices.

Regards

Mark

Ref: https://community.freescale.com/thread/352024

 

[stevech]

If you use the WIznet 812MJ or 820, the whole TCP/IP/ARM/ICMP stack plus a socket driver for multiple sockets plus the RAM buffers for TX,RX per socket,

Are Off-loaded to the Wiznet product. As well as the threading, interrupts and all that rot.

Putting the IP stack on a modest MCU was done long ago but today it's not prudent. Especially the Microchip parts.

 

[uTasker]

Hi Steve

There are always pros and cons of every solution/implementation.

I am involved professionally with many Ethernet based applications where typically a Kinetis K60 or STM32F4xx (for example) is used (with internal Ethernet controller). In some circumstances multiple Ethernet interfaces are required (one may be internal and another maybe via SPI) and again sometimes a processor without internal Ethernet needs to have an external connection.

Assuming the processor has enough internal resources (say 64k Flash and 16k RAM as basis for the stack) a lot is possible in terms of Ethernet TCP/IP functionality and the flexibility and control over the application can be very important.

In some cases we deliver projects where there are several thousand devices in remote networks that need to be updated with new features over time as networks evolve and new requirement become demanded. Without full control over the stack there could be serious issues - what happens if protocols and functions are not available? If you have this part of your product in an external hardware and it doesn't support what is required (I don't know the full capability of the Wiznet devices), such as IPv6, ipSec, multicasting, VLAN or rare Ethernet protocols you have a high risk unless you can somehow work out an agreement with the supplier and also allow updates to be field programmable in the other parts if ever necessary.

I agree that for small batches and hobby work adding a module that takes over a lot of potential work is often the simplest, especially if the experience of software involved is not available.

For industrial products and higher volumes an integrated software solution becomes attractive (the software component is also being paid for in the hardware price of the HW based solutions, which becomes more sensitive as quantities go up).

As far as threading, interrupt etc. are concerned I don't have any issues or worries since the software already handles this and has been proven over a decade of use.

As for Microchip parts - I certainly avoided the previous high power consumption 10M only SPI parts that was quite popular in the past, but this (newer) one has good efficiency, RAM buffers that help offload storage space plus various acceleration and encryption engines that could be useful for secure connections. Even the basic Teensy LC manages 220us ping response times (including transmission) with minimum software impact.

Of course I wouldn't normally consider using a Teensy LC since it really has too little RAM but a Teensy 3.1 can easily handle a full-blown stack (although one would usually go for something like a K64 with its internal Ethernet controller for best integration). But the fact is that such code will run on all devices and so generally the software can be immediately used in any such part with little or no development effort.

Regards

Mark

P.S. As mentioned in the original post, the main interest of the exercise on the Teensy LC was due to the SPI port differences that the KL part has to the K parts, that I wanted to verify (together with SD card operation on the same SPI port, using a different SPI phase mode).
Mostly I use the SPI extension for multi-homed work with a K64 (for example) where the processor needs to act as a gateway and/or bridge and so having one TCP/IP stack in the processor and one in an external chip is not workable.