VCI - Virtual CAN Interface - Ixxat

More documents

Recommendations

Info

Accessing the busAfter a message channel has been opened, it must first be initialized. This is donewith the function canChannelInitialize. The function expects as input parametersthe size of the receive and transmit buffers in number of CAN messages and thethreshold values for the receive or transmit event.The memory reserved for the receive and transmit buffers comes from a limitedsystem memory pool. The individual buffers of a message channel should thereforenot contain more than approx. 2000 messages.The receive event of a channel is triggered when the receive buffer contains atleast the number of messages specified in wRxThreshold. The transmit event istriggered when the transmit buffer has at least sufficient space for the number ofmessages specified in wTxThreshold.If the channel has been created, it can be enabled or disabled with the functioncanChannelActivate. The channel is enabled when the function is called with thevalue TRUE in the parameter fEnable. The channel is disabled by calling the functionwith the value FALSE in the parameter fEnable. A channel is disabled afteropening as the default setting.Messages are only received by the CAN controller or sent to it if the channel isactive. In addition, the CAN controller must be started, otherwise no messagetransfer takes place between the CAN bus and the channel. The message filter ofthe CAN controller also has an influence on the received messages. More informationon this is given in section 3.1.2.A message channel is closed with the function canChannelClose. The functionshould always be called when a channel is no longer needed.3.1.3.1 Reception of CAN messagesThe simplest way of reading received messages from the receive buffer is to callthe function canChannelReadMessage. If there are no messages available in thereceive buffer, the function waits until either a new message is received or thewaiting time specified in the parameter dwMsTimeout has expired. Every messagehas a associated message type (data, info, error, status, timer-overrun). (see§5.2.5 CANMSGINFO)The function canChannelPeekMessage also reads the next message from the receivebuffer. In contrast to canChannelReadMessage, however, the function doesnot wait for a new message but returns immediately to the calling program witha corresponding error code if no message is available in the receive buffer.It is possible to wait for a new receive message or the occurrence of the receiveevent with the function canChannelWaitRxEvent. The receive event is triggeredwhen the receive buffer contains at least the number of messages specified inwRxThreshold when canChannelInitialize is called.The following code fragment shows a possible use of the functions canChannel-WaitRxEvent and canChannelPeekMessage.22Copyright IXXAT Automation GmbH C-API Programming Manual, Version 1.5
Accessing the busDWORD WINAPI ReceiveThreadProc( LPVOID lpParameter ){HANDLE hChannel = (HANDLE) lpParameter;CANMSG sCanMsg;while (canChannelWaitRxEvent(hChannel, INFINITE) == VCI_OK){while (canChannelPeekMessage(hChannel, &sCanMsg) == VCI_OK)}{}// processing of the message}return 0;Note that the thread procedure only ends when the function canChannelWaitRxEventreturns an error code not equal to VCI_OK. However, when correctlycalled, all message channel-specific functions only return an error code not equalto VCI_OK when a serious problem has occurred.A program-controlled “normal” abort of the thread procedure from the previousexample does not therefore appear to be possible. However, it is possible to closethe handle of the message channel from another thread, where all currently outstandingfunction calls or all new calls end with an error code not equal toVCI_OK. However, the disadvantage of this is that any transmit threads runningsimultaneously are also affected.3.1.3.2 Transmission of CAN messagesThe easiest way of transmitting CAN messages to the bus is to call the functioncanChannelSendMessage. The function waits until sufficient space is available inthe message channel and then writes the message in a free entry in the transmitbuffer. If it was possible to enter the message in the transmit buffer in the timespecified in dwMsTimeout, the function returns the value VCI_OK. If the specifiedtime has elapsed without the message being written in the transmit buffer, thefunction returns the value VCI_E_TIMEOUT.The function canChannelPostMessage also writes a CAN message in the transmitbuffer. Unlike canChannelSendMessage, however, the function does not wait untilsufficient space is available in the transmit buffer but returns to the callingprogram with an error code if no free entry is available.It is possible to wait for the occurrence of transmit events with the function can-ChannelWaitTxEvent. The transmit event is triggered when the transmit bufferhas at least enough space for the number of messages specified in wTxThresholdwhen canChannelInitialize is called.The following code fragment shows a possible use of the functions canChannel-WaitTxEvent and canChannelPostMessage.23Copyright IXXAT Automation GmbH C-API Programming Manual, Version 1.5
Page 8 and 9: System overviewThe VCI server runni
Page 10 and 11: Device management and device access
Page 12 and 13: Device management and device access
Page 14 and 15: Accessing the bus3 Accessing the bu
Page 16 and 17: Accessing the bus3.1.2.1 Controller
Page 18 and 19: Accessing the bus3.1.2.2 Message fi
Page 20 and 21: Accessing the busAs the example sho
Page 24 and 25: Accessing the busHRESULT hResult;HA
Page 26 and 27: Accessing the bust zTransmit object
Page 28 and 29: Accessing the busNormally, the tran
Page 30 and 31: Accessing the bus3.2.2.1 Controller
Page 32 and 33: Accessing the busIf the connection
Page 34 and 35: Accessing the busAfter a message mo
Page 36 and 37: Interface description4 Interface de
Page 38 and 39: Interface descriptionReturn value:I
Page 40 and 41: Interface descriptionpszGuid[out] P
Page 42 and 43: Interface description4.2.1.2 vciEnu
Page 44 and 45: Interface descriptionComments:The c
Page 46 and 47: Interface descriptionpVciidDevice[o
Page 48 and 49: Interface descriptionComments:After
Page 50 and 51: Interface descriptionphControl[out]
Page 52 and 53: Interface descriptionReturn value:I
Page 54 and 55: Interface description4.3.1.6 canCon
Page 56 and 57: Interface description4.3.1.8 canCon
Page 58 and 59: Interface description4.3.1.10 canCo
Page 60 and 61: Interface description4.3.2 Message
Page 62 and 63: Interface descriptionpCaps[out] Poi
Page 64 and 65: Interface description4.3.2.6 canCha
Page 66 and 67: Interface description4.3.2.9 canCha
Page 68 and 69: Interface description4.3.2.11 canCh
Page 70 and 71: Interface description4.3.3 Cyclic t
Page 72 and 73:
Interface description4.3.3.4 canSch
Page 74 and 75:
Interface description4.3.3.7 canSch
Page 76 and 77:
Interface description4.3.3.10 canSc
Page 78 and 79:
Interface description4.4.1.3 linCon
Page 80 and 81:
Interface description4.4.1.6 linCon
Page 82 and 83:
Interface description4.4.2.1 linMon
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Interface descriptionReturn value:I
Page 90 and 91:
Types and structures• VciObjectId
Page 92 and 93:
Types and structures• wBusCouplin
Page 94 and 95:
Types and structures• dwStatus:[o
Page 96 and 97:
Types and structures5.2.5 CANMSGINF
Page 98 and 99:
Types and structuresCAN_MSGTYPE_STA
Page 100 and 101:
Types and structures5.2.7 CANCYCLIC
Page 102 and 103:
Types and structures• dwClockFreq
Page 104 and 105:
Types and structuresThe information
Page 106:
Types and structures• Bits.ovr:[o
show all

VCI - Virtual CAN Interface - Ixxat

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?