Dear U.Wilhelm,
thanks for your answer.
It was not my point to affront you or your company. In my introduction I wrote
that could be improved
and that's how I meant it. And before writing this post, I have carefully thought about the points,
because I know that an improvement must never break existing things.
The QtSerialBus Interface is not officially supported from PEAK-System - so you need to contact the community.
If you read my post again, you will notice that I only spoke about
your API. I'm looking at that API from
a users point. In my case, the user is QtSerialBus - I only wrote that as the first introducing sentence so
you know my background.
Your comments are your view - but not the view of all developer - most does not use the QT Environment.
Yes, they are my view, but as already said, I think these are points will affect a lot of your PCAN-Basic users.
And these are simply suggestions to make things even better. Feel free to ignore them from my side,
sooner or later you may hear them from others.
1. If your Environment need const char, instead of the used char* - simpl cast it for your need. We need to use it this way- The PCAN-Basic is a cross plattform and cross language API - some languages (in Windows) need it this way. Could be solved within seconds in your code.
Excuse me, but no. If a function takes a parameter by reference or as pointer, it is allowed to
modify the content. This is simple 40 year old C standard.
Obviously, CAN_InitializeFD will not change the pointer's content. But neiter the compiler, nor static code analysis tools nor a reviewer in critical environments will like to cast away the constness.
As said, both char * and const char * should be binary compabile in pure C. So in minimal, please change the
public include file for C and C++ compilers, so you swear you don't modify the contents of this pointer.
2. As you know it is a simple one line code to do this. But this have nothing to do with the API itself. Add it, if you think you need it, to your Lib.
It is not just one line of code, it is the conversion table you provided. And it has to do with the API, as your read and write functions operate on DLC, not on data length.
But Ok, can be solved in user code. Just that a lot of your users will have to write the same boiler plate code
as I do.
3. This is not possible, because the used Structure(s) are different in CAN and CAN FD (Message and Timing).
I know that the backend is different, but isn't the whole point of an API to abstract things?
Again, your users will have duplicated code when they need to support both CAN 2.0 and CAN FD hardware.
You look from user side fixed in QT. But we develop from Driver side - cross! not only Linux - please keep in mind.
I'm using your API in Windows and in Linux. That works indeed fine, really good work!
4. CAN-FD is much more complicated in timing, and so it is much more as simpe "use 500K nominal and 2Mbit data). This will end up into many errors and frustration for the users. The User NEED to be sure that they know EXACT the timing - otherwise they run into trouble in the filed.
So, please suggest me: how should I start if I want to be able to set the arbitration bitrates {125, 250, 500, 1000} and fro the data bitrate the same value and arbitration bitrate * 8?
Thanks, and best regards,
André
