CANopenNode
New OD example dsPIC33
Please create a newOD branch in order to merge this.
I updated dsPIC33 example to compile with newOD, this could be a start point for CANopenPIC. LSS example code is not modified but commented as I don't use it.
I commented the following declarations in CO_driver_target.h to compile :
- GFC
- GTW
- TRACE
- SRDO This may not be the good way do disable those ?
I also added a custom inttypes.h as this is missing on XC compilers. You can add CANopenNode Copyrights on this header.
Hi @JuPrgn I just updated this repository to the latest CANopenNode with full support for PIC32. Also the driver PIC24_dsPIC33 was updated, which was minor. I didn't change the example for it, as you already did much work.
Now the branches are in conflict. Can you update your branch for PIC24_dsPIC33(I think CO_CONFIG... macros are not necessary in CO_driver_target.h and also while(1) are simpler than log_printf() in main_dsPIC33F.c. inttypes.h are also not necessary for usual CANopenNode configuration.)
I will then also add LSS slave to PIC24_dsPIC33, it is quite simple.
If you have any plans to use eeprom for object dictionary storage with PIC24_dsPIC33, you can add support for it. It is only necessary to configure SPI, see PIC32/CO_eepromPIC32.c and README.md.
I would ask you for another opinion. PIC24_dsPIC33 has a basic example which has main_dsPIC33F.c file. In PIC32 I use more universal and configurable main_PIC32.c file, which is part of the driver and has application interface specified by application.h file (similar to arduino). I use that main file also in my projects. Do you think, I can do the same with main_dsPIC33F.c? Will it be suitable for your projects? If yes, then I will combine changes from your PR with main_dsPIC30F.c and make main_dsPIC33F.c at side of the driver files.
Hi @CANopenNode
Ok I will will solve conflicts on this branch soon.
CO_CONFIG macros should not be used anymore or they should be somewhere else ?
I can change log_printf to while(1) if you prefer this but this is cool when you have a debug terminal to print verbose message, anyway a debug session can also help to figure out with blocking while(1).
Ok let's remove inttypes.h I don't remember for which part this was required when I updated this MR.
I am not using EEPROM storage directly from CANopenNode on my current applications we prefer to restore OD default values at startup but this could be useful.
This is a good idea, I think some users will use it directly in their projects and it will help them keep user code out of the stack code. Do you succeed to configure it without changing this main_PIC32.c code ? I guess if this is with the driver this sould not be edited by the user. These main_PIC32 / main_PIC33F are very similar and a modification on one is often directly copied in the other so it makes sense to keep them as similar as possible to simplify this.
In my case, I have a custom generic main that calls an interface to configure and run CANopen.h (which is similar to main_dsPIC33F.c), I would rather have a generic main that configures and uses a communication interface rather than be driven by CANopenNode main to not depend on the communication protocol used. This is still a work in progress on my side and on my previous application the main was very similar to main_dsPIC33F.c
Maybe you can wait and I will try to transfer main from Pic32 into dspic33. then you will test and add the details.
CO_CONFIG macros are used. However, if their default values are suitable, then you don't have to mention them in CO_driver_target. For example, if this is OK for your configuration, then you can omit configuration for your target device:
https://github.com/CANopenNode/CANopenNode/blob/c10043a11044f0c107b486dfbf01759e1ca9b6f5/301/CO_SDOserver.h#L33-L38
I didn't try log_printf in PIC32 as you mention, but I like your idea. So I could use that for PIC32 too. How is debug terminal used?
I think inttypes.h can be safely removed.
Please take a look into https://github.com/CANopenNode/CANopenPIC/blob/master/PIC32/CO_eepromPIC32.c. It may not be too complex to adapt that file to dsPIC33. CO_storage may be used for any data block, not only object dictionary.
In the past I have used own main_PIC32.c for my project. Now I made it more configurable (with #ifdef), so I can use it directly. but it still may not be suitable for everybody. I think your idea is also very good, main should not be driven by CANopenNode. We could rethink, how CANopenNode's "main" should look like. I would then change PIC32's "main" too.