Comments (15)
I try for CO_init to be the same for all microcontrollers. Otherwise there is necessary to add controller-specific code into CANopen.c file.
I think, mapping inside CO_init function is most elegant solution.
from canopennode.
Hi, so what do you exactly mean with mapping inside CO_init?
I think there is some inconsistency. In the CANopen.c you use this prototype:
/**
* Initialize CANopen stack.
*
* Function must be called in the communication reset section.
*
* @param CANbaseAddress Address of the CAN module, passed to CO_CANmodule_init().
* @param nodeId Node ID of the CANopen device (1 ... 127).
* @param nodeId CAN bit rate.
*
* @return #CO_ReturnError_t: CO_ERROR_NO, CO_ERROR_ILLEGAL_ARGUMENT,
* CO_ERROR_OUT_OF_MEMORY, CO_ERROR_ILLEGAL_BAUDRATE
*/
CO_ReturnError_t CO_init(
int32_t CANbaseAddress,
uint8_t nodeId,
uint16_t bitRate);
Then you use in the PIC diver this prototype
CO_ReturnError_t CO_CANmodule_init(
CO_CANmodule_t *CANmodule,
uint16_t CANbaseAddress,
CO_CANrx_t rxArray[],
uint16_t rxSize,
CO_CANtx_t txArray[],
uint16_t txSize,
uint16_t CANbitRate);
So you pass a int32_t CANbaseAddress to an uint16_t CANbaseAddress function.
Do you get no warning here?
from canopennode.
Sorry, I meant mapping inside CO_CANmodule_init function. That is in the driver. For example as in 16bit PIC (line 178): https://github.com/CANopenNode/CANopenNode/blob/master/stack/PIC24_dsPIC33/CO_driver.c
You are right, there is some inconsistency, CANbaseAddress should be int32_t in all drivers. I will fix it.
from canopennode.
Okay many thanks,
I will update the STM drivers i will add some pulls for the STM32F103 and STM32F407 in the near future.
cheers
mathias
from canopennode.
So to fix the inconsistency ... one solution could be to write a new header file as an example CO_driver_interface.h => here every function prototype and maybe also every define and typedef which is mandatory equal for every driver driver could be added to this header. And in der CO_driver.h the interface must be included. Otherwise you have to duplicate a lot of prototypes and other stuff.
from canopennode.
Please think about to separate the stack and the drivers. If you have separate repositories for everything it would be much easier to use the project in a managed build environment.
CANopenNode
CANopenNode_driver_stm32 => f1, f2, f3, f4, f7
CANopenNode_driver_k20
CANopenNode_driver_pic => different pics
CANopenNode_driver_ecos
...
...
As an example if I would like to use STM32 I add the stack CANopenNode as submodule and the CANopenNode_driver_stm32 as a submodule. And then I do not have to exclude every driver and so on ...
It is only a point to think about...
cheers
from canopennode.
I got a hint about separating the drivers last week also from someone else. And like the idea quite much.
I think, I will separate the drivers, as you suggested. I can't maintain drivers for all devices, so there is no sense to have all them in my repositories. I will only include links to known implementations. So the stack could stay clean and nice.
cheers
from canopennode.
That sounds great. Do you know a good CANopen Host SW? I tried CANopen Device Monitor from Port.de but I am not able to use peak CAN in the eval mode on windows.
I would like to test my STM32 node.
many thanks
from canopennode.
Here is an effort to rewrite a Object dictionary part of CANopenNode. New version will have separate drivers. Interface won't change.
I'm currently using my CANopenSocket with client command interface and some tools from can-utils on Linux. There is also Python client, but I didn't test it yet.
from canopennode.
I think you linked the wrong thing. That's my issue for the pull request to add the K20 driver, I did not try to rewrite the OD.
from canopennode.
Above was some "off topic" discussion about splitting the drivers from the stack. New OD was also discussed. And driver for STM32. There will be a little reorganisation of the stack.
from canopennode.
Concerning the reorganisation. Have you taught about a CO_drivers_interface.h which lives inside the stack. And every driver must support the functions from that interface. With that approach it is really clear which functions are needed inside the stack and which functions I have to support in the driver. With the current design there is a lot of duplicated drivers.h files around with a lot of duplicated code.
from canopennode.
inside /stack/drvTemplate/CO_driver.h are the necessary functions. PIC32 (and socketCAN) are most relevant examples.
from canopennode.
Hi,
Yes I know that´s wasn´t that what I mean. I mean why noch add a CO_driver.h ... or I don´t know how to name it ... only once inside the stack. And every driver can use this.
from canopennode.
separation is handled in #108 (comment)
from canopennode.
Related Issues (20)
- On STM32,Multiple TPDOs uses event-driven transmission, How to use the function "OD_requestTPDO(uint8_t *flagsPDO, uint8_t subIndex)" and "uint8_t *OD_getFlagsPDO(OD_entry_t *entry)" sends TPDO? HOT 2
- error handling on comms error HOT 2
- Open and close brackets mismatch in CO_Emergency.c HOT 1
- Send to different Nodes with same objects HOT 10
- How to handle SIGSEGV during the communication process to prevent program crashes HOT 4
- Configuring the micro as MASTER problem, CO_NMT_sendCommand() not defined HOT 1
- Multiple nodes, NMT problem HOT 2
- return CO_ERROR_OUT_OF_MEMORY HOT 1
- Questing about NMT and Heartbeat status queries HOT 1
- MISRA 2004 compliant for a few rules HOT 3
- Issue with include style fo Arduino HOT 4
- Porting SRDO to v4.0 HOT 4
- Trying to receive SDO messages in SDO client over the CO_SDOclient_receive HOT 5
- Unsigned int 24 bits HOT 5
- Enter the pre-oprational state HOT 5
- Please help HOT 3
- RPDO configuration every 2 Syncs HOT 1
- How to make it possible to receive all messages (SDO, PDO, NMT) in raw form? HOT 2
- Compiler warnings HOT 1
- Compiling without "CO_SINGLE_THREAD", using "1 w 0x1010 1 vs save" via ascii gateway causes deadlock (CO_LOCK_OD)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from canopennode.