Yes, application can define and and initialize it to add additional functionality or override default read/write callbacks.
In CANopenNode V4 (latest on github) you could specify a custom callback function for reading and for writing any OD entry. SDOs and PDOs use those callbacks. That way you can access any external library, own way. You would then probably use CANopenNode for all CANopen communication.
https://github.com/CANopenNode/CANopenNode https://github.com/CANopenNode/CanOpenSTM32/ https://github.com/CANopenNode/CanOpenEditor
You are probably right. Here are my tests with Linux and PIC32: https://github.com/CANopenNode/CANopenDemo/blob/master/test/test_report.md#sdo-transfer-test-reports-for-different-target-systems If you use Linux, you could test STM32 as demoDevice the same way. Segmented transfer should work in all cases, for block transfer you need a good CAN interface. But I think, XXAT is not supported on Linux.
Maybe you can check: https://github.com/CANopenNode/CANopenDemo/blob/master/tutorial/README.md Or some other documentation about CANopen SDO.
I didn't try, but it should be possible. See CO_ODinterface(). The only function which uses object dictionary is OD_find(). It returns pointer to OD_entry_t object, if found. Please note, entries must be ordered by index for this function to work. Files CANopen.c and CANopen.h are complex because of flexibility and ability to integrate OD.h and OD.c files. For most custom solution you could also write own CANopen.h/c files and generate object dictionary dynamically without OD.h/.c files.
This is an old page, don't know, why it is still there. Please see: https://canopennode.github.io/ https://canopennode.github.io/CANopenLinux/index.html
https://github.com/CANopenNode/CANopenLinux#can-interfaces