Hello,
I am looking to migrate from the MOD5282 to a newer platform that is pin-compatible with it.
On the MOD5282, other than power and ground, I am currently using the following pins on J1:
- 6: Chip Select 2
- 7: Chip Select 3
- 8: Output Enable
- 11: Transfer-in-progress
And the following pins on J2:
- 3, 4: UART0 RX, TX
- 21, 22: UART1 RX, TX
- 39, 42: I2C Data, Clk
- 41, 44: CAN RX, TX
The CAN function is the only one which is critical for my application, so I require a replacement for MOD5282 which has the same form factor for the headers, and that pins 41 and 44 on header J2 are dedicated for CAN. I am flexible on the functions of the other pins in the replacement (other than power and ground, of course).
I notice that MOD5441X may be a good replacement. I have some questions:
1. Is that correct? Does MOD5441X satisfy my requirement for pin-compatibility with MOD5282?
2. Are there other options which also satisfy this requirement? https://www.netburner.com/products/syst ... s/#compare
3. If I decide to migrate to MOD5441X, what changes would need to be made in software? I would appreciate some information similar to this Migration Guide https://www.netburner.com/learn/upgradi ... modm7ae70/ but for MOD5441X
Please feel free to let me know.
Thanks.
Migrating from EOL MOD5282 to a replacement supporting CAN
Re: Migrating from EOL MOD5282 to a replacement supporting CAN
Hello AlokD,
1. Yes, those pin functions all match. Mechanically, the headers, mounting holes and Ethernet jacks are the same across the MODxxxx product line. The length of the MOD5441x is about 0.25 inches longer than the MOD5282. This is the dimension opposite the RJ-45 jack. So it does not affect mechanical positions of any connectors or mounting.
2. The other option would be the MODM7AE70. You have referenced the link to the information on compatibility. Since the MOD54415 uses a ColdFire processor, it is more similar to the MOD5282, but either can be used. The MODM7AE70 uses an ARM processor and the peripherals are slightly different from a hardware perspective.
3. Minor changes in software between the MOD5282 and MOD54415, depending on the software tools revision you are using. The MOD5282 is 20 years old, so if you have a tools release that old it might be more effort than if you are using the latest 2.9.7 release. It also depends on how the code was written. So far most 5282 ports have taken 1-2 days. But like I said, longer depending on how the code was written, and whether any 5282 specific registers were used that need to be converted to 54415.
From a tools perspective, if you were using anything earlier than 2.8, you should port to 2.9.7 first. You then have the option to use the 3.x tools if you wish, which add a bunch of IoT, security and configuration capabilities. Here are the docs: https://www.netburner.com/NBDocs/Develo ... index.html. The Configuration and Migration sections would be very helpful.
Please let me know if you have any additional questions.
1. Yes, those pin functions all match. Mechanically, the headers, mounting holes and Ethernet jacks are the same across the MODxxxx product line. The length of the MOD5441x is about 0.25 inches longer than the MOD5282. This is the dimension opposite the RJ-45 jack. So it does not affect mechanical positions of any connectors or mounting.
2. The other option would be the MODM7AE70. You have referenced the link to the information on compatibility. Since the MOD54415 uses a ColdFire processor, it is more similar to the MOD5282, but either can be used. The MODM7AE70 uses an ARM processor and the peripherals are slightly different from a hardware perspective.
3. Minor changes in software between the MOD5282 and MOD54415, depending on the software tools revision you are using. The MOD5282 is 20 years old, so if you have a tools release that old it might be more effort than if you are using the latest 2.9.7 release. It also depends on how the code was written. So far most 5282 ports have taken 1-2 days. But like I said, longer depending on how the code was written, and whether any 5282 specific registers were used that need to be converted to 54415.
From a tools perspective, if you were using anything earlier than 2.8, you should port to 2.9.7 first. You then have the option to use the 3.x tools if you wish, which add a bunch of IoT, security and configuration capabilities. Here are the docs: https://www.netburner.com/NBDocs/Develo ... index.html. The Configuration and Migration sections would be very helpful.
Please let me know if you have any additional questions.
Re: Migrating from EOL MOD5282 to a replacement supporting CAN
Hi TomNB,
I just realized I should probably have responded last week to let you know that I found the above information very useful! Thank you!
I was waiting to see whether my team would decide go with MOD54415 or MODM7AE70 given the above information. However, they have not yet made a decision, so at some point in the future I can give an update here once I hear from them.
We did go through the migration guide. We are currently using NNDK 2.7.3 (with the compiler updated to m68k-elf-gcc4.8.0 https://sysprogs.com/getfile/28/m68k-elf-gcc4.8.0.exe). So some code change will be required to update to 2.9.7, and a lot of change to update to NNDK 3.X.X.
If I’m understanding correctly, updating to 3.X.X is required for MODM7AE70 due to there being no 2.X.X cross-compile toolchain for the ARM processor? Whereas 2.9.7 is permissible for the Coldfire processor of MOD54415?
Hope to hear from you.
I just realized I should probably have responded last week to let you know that I found the above information very useful! Thank you!
I was waiting to see whether my team would decide go with MOD54415 or MODM7AE70 given the above information. However, they have not yet made a decision, so at some point in the future I can give an update here once I hear from them.
We did go through the migration guide. We are currently using NNDK 2.7.3 (with the compiler updated to m68k-elf-gcc4.8.0 https://sysprogs.com/getfile/28/m68k-elf-gcc4.8.0.exe). So some code change will be required to update to 2.9.7, and a lot of change to update to NNDK 3.X.X.
If I’m understanding correctly, updating to 3.X.X is required for MODM7AE70 due to there being no 2.X.X cross-compile toolchain for the ARM processor? Whereas 2.9.7 is permissible for the Coldfire processor of MOD54415?
Hope to hear from you.
Re: Migrating from EOL MOD5282 to a replacement supporting CAN
Hello Alok,
Thank you for the update. You are correct, ARM processors require the 3.x tools. Can you provide any more details on why going from 2.9.7 to 3.x would require a lot of change? So far in my experience, other than the web processing, not much change has been necessary. Although I have not done a CAN software port yet. Is the issue the CAN API?
The time to port web processing is heavily dependent on the way the code was written. To summarize, the difference is in 2.x all web processing was done in 1 function callback, so the URL needed to be parsed and checked against each page name. To greatly speed things up and make things easier to maintain for new designs, 3.x uses callbacks with optional masks. If all pages are unique, then there is a separate function for each and the code is easier to read. Similar pages can now have a mask. Lets say a product has 5 pages that display information for 5 similar systems. A single callback can handle all 5 with a mask like: system*.html to handle system1.html, system2.html, etc.
There is also an example in 3.x that uses a * mask to process all pages if you want to do it the way 2.x did.
Hope that helps.
Thank you for the update. You are correct, ARM processors require the 3.x tools. Can you provide any more details on why going from 2.9.7 to 3.x would require a lot of change? So far in my experience, other than the web processing, not much change has been necessary. Although I have not done a CAN software port yet. Is the issue the CAN API?
The time to port web processing is heavily dependent on the way the code was written. To summarize, the difference is in 2.x all web processing was done in 1 function callback, so the URL needed to be parsed and checked against each page name. To greatly speed things up and make things easier to maintain for new designs, 3.x uses callbacks with optional masks. If all pages are unique, then there is a separate function for each and the code is easier to read. Similar pages can now have a mask. Lets say a product has 5 pages that display information for 5 similar systems. A single callback can handle all 5 with a mask like: system*.html to handle system1.html, system2.html, etc.
There is also an example in 3.x that uses a * mask to process all pages if you want to do it the way 2.x did.
Hope that helps.