View previous topic :: View next topic |
Author |
Message |
demedeiros
Joined: 27 Dec 2013 Posts: 71
|
Ethernet system architecture help |
Posted: Mon Aug 07, 2023 7:56 am |
|
|
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! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9168 Location: Greensville,Ontario
|
|
Posted: Mon Aug 07, 2023 9:07 am |
|
|
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 ! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Mon Aug 07, 2023 9:45 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Mon Aug 07, 2023 10:52 am |
|
|
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). |
|
![](templates/subSilver/images/spacer.gif) |
demedeiros
Joined: 27 Dec 2013 Posts: 71
|
|
Posted: Mon Aug 07, 2023 11:38 am |
|
|
temtronic wrote: | 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 ! |
Sorry about the confusion. Its laid out like this:
Quote: | 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. |
It does not have a DHCP server, I guess we could run one on the PC. I am thinking the broadcast approach might be better though. From the PICs perspective, is this as simple as sending UDP packets to the broadcast address? Or is there something special about broadcast from the PIC? The PIC wont be receiving any data, just sending out data as of now.
Quote: | Went through this procedure relatively recently. We elected to go with the Microchip XC8 compiler and Microchip's "lite" TCP/IP stack. |
Was there a specific reason to not go with the CCS stack? I am not familiar with MPLAB X or any of their compilers. Would rather not have to go through that learning curve...
Thanks for all of your responses! |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Mon Aug 07, 2023 1:55 pm |
|
|
demedeiros wrote: | Quote: | Went through this procedure relatively recently. We elected to go with the Microchip XC8 compiler and Microchip's "lite" TCP/IP stack. |
Was there a specific reason to not go with the CCS stack? I am not familiar with MPLAB X or any of their compilers. Would rather not have to go through that learning curve... |
Short answer: the age of the stack. CCS' is very old, and Microchip's wasn't. You're going to have issues, but there isn't a clear winner in terms of which implementation to go with. If we had to do it over again, and if silicon availability wasn't a concern, I'd use an STM32 with built-in networking. Just don't think that using the STM32 free compiler is a good idea - it isn't. Bite the bullet and buy the IAR compiler. Not cheap, but also not buggy. The free STM32 compiler, last time I touched it, was riddled with bugs. |
|
![](templates/subSilver/images/spacer.gif) |
demedeiros
Joined: 27 Dec 2013 Posts: 71
|
|
Posted: Tue Aug 08, 2023 7:02 am |
|
|
Quote: | Short answer: the age of the stack. CCS' is very old, and Microchip's wasn't. You're going to have issues, but there isn't a clear winner in terms of which implementation to go with. If we had to do it over again, and if silicon availability wasn't a concern, I'd use an STM32 with built-in networking. Just don't think that using the STM32 free compiler is a good idea - it isn't. Bite the bullet and buy the IAR compiler. Not cheap, but also not buggy. The free STM32 compiler, last time I touched it, was riddled with bugs. |
Thanks for the info. Will research the IAR compiler, presumably the learning curve wont be too difficult. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Tue Aug 08, 2023 5:45 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Aug 09, 2023 3:29 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Thu Aug 10, 2023 2:01 am |
|
|
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!! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Thu Aug 10, 2023 2:34 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
demedeiros
Joined: 27 Dec 2013 Posts: 71
|
|
Posted: Thu Aug 10, 2023 6:59 am |
|
|
Ttelmah wrote: | 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. |
I like that approach, and I think it would simplify things for me greatly. I need to talk to the folks doing the PC side programming and make sure they are ok with it. I cant imagine why they wouldn't be.
Would you recommend a PIC with an Ethernet Module (PIC18F97J60) or a non ethernet pic with an external ethernet controller (ENC28J60 or Wiznet W5500)? |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Thu Aug 10, 2023 8:10 am |
|
|
[quote="demedeiros"] Ttelmah wrote: |
..
Would you recommend a PIC with an Ethernet Module (PIC18F97J60) or a non ethernet pic with an external ethernet controller (ENC28J60 or Wiznet W5500)? |
If the CCS stack supports both the PIC18FxxJ6x family and the ENC28J60 then it does not matter which you choose. Having said that, the Microchip ENC424j600 far superior to either of these. The ENC28J60 was basically their proof of concept and the ENC424j600 was how to do it correctly.
I have not used the W5500 as it didn’t suit my needs. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
demedeiros
Joined: 27 Dec 2013 Posts: 71
|
|
Posted: Thu Aug 10, 2023 8:34 am |
|
|
asmallri wrote: |
If the CCS stack supports both the PIC18FxxJ6x family and the ENC28J60 then it does not matter which you choose. Having said that, the Microchip ENC424j600 far superior to either of these. The ENC28J60 was basically their proof of concept and the ENC424j600 was how to do it correctly.
I have not used the W5500 as it didn’t suit my needs. |
Thank you for your very helpful replies. I appreciate all of the help you and everyone else has provided! |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Thu Aug 10, 2023 7:53 pm |
|
|
I agree with Andrew. The ENC28J60 has many issues. You can get things done with it, but it has a long errata list. |
|
![](templates/subSilver/images/spacer.gif) |
|