Ethernet system architecture help

[demedeiros]

Hi all,

I am in the early stages of putting together a system where I need a micro to send some simple data (temperature, pressure, etc) over ethernet to a PC running a custom application. The completed system ends up having the PIC completely enclosed and its sent down 300-400ft beneath the ocean. Ethernet data (PIC & Cameras) is then sent up over a 10G fiber link to the PC on a surface ship. These pic/camera assemblies get changed out pretty frequently due to damage. Mixing and matching between pic/camera assemblies and PCs happens frequently. Setting static IPs is difficult.

Due to the nature of changing PIC/camera setups, it would be ideal to not have to "tie" the PIC to a single IP address of one PC. The network itself consists of 3 cameras, 1 PIC PCB, and 1 PC.

I am wondering what the best method for sending data would be? UDP is perfectly acceptable, however it seems like standard UDP requires a destination address. Multi-cast and broadcast seem like they might work, but I am having a hard time wrapping my brain around how to implement this, if its even possible on a PIC with CCS.

Lastly, looking through the older posts, it seems that the CCS stack is a very old microchip stack. These posts do seem old though... Is that still the case today?

Thanks!

[temtronic]

ok, I'm kinda confused with the 'hardware'.....

is it this ?
underwater.........................................:: on the ship
sensors->PIC--->eth-net---> PC--->fibre----> topside PC#2

I have trouble with English, and I was born in Canada,eh !

[Ttelmah]

Does your network have a DHCP server?. If so you can ask this what devices
have been attached. Remember you can potentially also talk to the broadcast
address. A huge amount depends on how the network is actually configured.

[newguy]

Went through this procedure relatively recently. We elected to go with the Microchip XC8 compiler and Microchip's "lite" TCP/IP stack.

1. I'm not a fan of the XC8 compiler, and I'm certainly not a fan of MPLAB X.
2. There were many bugs not only with the lite implementation of the stack, but also with MCC (Microchip's code configurator). I can't tell you how many times we rebuilt the project from scratch in MCC because trying to make a minor change after the fact always resulted in much dread.
3. It took a long time, but the resulting product was actually quite stable. We used the ENC28J60 mated to an 18 series PIC (with a lot of memory).

[demedeiros]

[newguy]

[demedeiros]

[newguy]

You can use the STM32 Cube MX to create the source code, but don't use the free STM compiler. Heartache awaits if you do. Compile that same code under IAR, and it works.

[Ttelmah]

At the end of the day, for what he is showing, the existing CCS stack
would probably be totally adequate. There is a balancing act here that
some of the newer features are not wanted/needed for most embedded
applications, and keeping the stack smaller is therefore worthwhile.

[asmallri]

First a bit about multicast..

Multicast is a little complex as multicast addressing occurs both a the link layer (multicast MAC address) and the Network layer (IP multicast) so an IP multicast packet has both an outer multicast MAC header and an inner IP multicast header. IP IP multicast addresses will map to a MAC multicast address.

When dealing with 8 bit PICs, you have to be careful when using broadcast as a broadcast packet is always forwarded from the controller (integrated or external) to the processor. So a PIC with limited processing resources can spend more time trying to process broadcast packets than to actually do other functions. If the device takes too long, the Ethernet controllers receive buffers can overflow and packet drop internal to the Ethernet controller occurs.

Mulitcast at the link layer is better than broadcast in this scenario provided the Ethernet stack configures the Ethernet controller correctly. This is because the Ethernet controllers can be configured to use MAC layer multicast filters which filter traffic incoming to the Ethernet controller buffers. Multicast UDP packets, with their corresponding multicast MAC address, are only passed through the ethernet controller if they match the configured multicast filter configuration on the controller. What is supposed to happen is when the device joins an IP multicast group (or groups) the Ethernet controller multicast filters are configured to pass the multicast MAC addresses of the subscribed IP multicast groups.

There is also a catch, at the MAC layer there are only 23 bits available for multicast addressing which at the IP layer there are 28 bits for multicast addressing. This means 32 multicast IP addresses match to a single multicast MAC address. In a worst case scenario where you have 32 devices in your network that all map to the same layer 2 multicast address, the effect is the same as if you used broadcast packets.

I developed a family of Ethernet bootloaders for PICs with embedded Ethernet controllers are well as external Microchip and Realtek controllers. These bootloaders used UDP and multicast. I wrote my own stack as, when I did this originally in 2004, there was no Microchip or CCS stack although later versions for users that use the Microchip compilers, I did use a their low level ethernet controller driver but not their stack.

So, It has been a LONG time since I looked at using the CCS stack. Maybe it does configure the multicast filter table of the Ethernet controller for you, but even if it doesn't, you could do that yourself.

I would not suggest using a DHCP server for such a simple network. Can you simplify this by using you own well defined IP address assignment mechanism.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Ttelmah]

I did a system a little while ago, where we used a packet as a
form of plug and play network addressing.
The standard CCS stack was used, and setup to use a fixed IP read from
it's internal EEPROM. The units all work up using the same fixed IP till
the EEPROM had a value. All you did was attach one new unit to the
network, we then had a simple PC program that would talk to the fixed
IP, and send a packet with the required IP. You just plug the unit on, ran
the program, and the unit's IP was set.

[demedeiros]

[asmallri]

[quote="demedeiros"]

[demedeiros]

[newguy]

I agree with Andrew. The ENC28J60 has many issues. You can get things done with it, but it has a long errata list.