Enumerating available CAN channels

[Kamen]

Is there are better way of enumerating the CAN bus communication channels available in a system than simply probing in order: PCAN_PCIBUS1, PCAN_PCIBUS2, ..., PCAN_PCIBUS16, PCAN_USBBUS1, PCAN_USBBUS2, ..., PCAN_USBBUS16, and so on? Those aren't even consecutive numbers, even though, one shouldn't be making assumptions about the numeric mapping, if they were.

Kamen

[PEAK-Support]

If you want to know which Devives and channels are availabel , you simply run to a loop and check all - not much lines of code. The reason why the numbers for the Channels are not in a "row", is need to be compatible with older Software that did not support so much CAN Channels. Is it as it is - we could not change, but it is also no real problem. As a software developer you could simply map the Channels into a array and use this index to enumerate and check the channels so all in one single loop. If you want one single call to get all info - write a own function that handle it - use own structures for all channels with there "availability" - but this is up to you - most customer do not need it. The simply use 1 or 2 channels and check by reading the Device Number which channel is which device.

[Kamen]

Thank you, I understand. It is not about the effort writing a few extra lines of code. It is about stability and future-proofing. What if in future editions of PCAN-Basic there are new types of handles? Like, for a new communications bus. We'd have to add code to support it. As opposed to having a function in the library that returns all available handles. In this case, all we'd need is have our customers keep their PEAK drivers (DLL, etc.) up to date - makes them feel much more confident (single-point of failure vs dual). Plug-and-play and future-proof. All I'm saying is: there is much more value in PEAK supplying such a function in their library, rather than having the integrators write their own. And there is a big difference between something as fundamental as device discovery and all other functions that one would need, so it doesn't get much further.

Kamen

[PEAK-Support]

This is your point of view, we think that less is more - keep API DLLs simple! Users could very easy implement such features by their own if they really need it. Also for most customer it is a must that new Hardwaretypes should NOT work out of the BOX with their(older) applications, because they have not checked if their application/systems really support this device. (See new Virtual Network Devices - some customers do not want that their APPs work with this type, because of timing issues).