Software Team Meeting 11/04/2003

In attendance: Ian, Peter, Tyler and Andrew (and Paul drifted in briefly)

LTC Status

Since the CANtalope hardware and firmware was actually working last week, we guessed that there was some hardware problem with the LTC CAN bus. Indeed, there was: one of the CAN bus wires had been broken, probably by being trapped between the door and the horizontal divider between the LTC section and the cable section. When the LTC cables are "refactored" ;) we'll button everything down with cable ties and holders so this can't happen again. For now, the CAN bus is just twisted together which seems to work.

CAN Driver

Ian hacked away at the CAN driver and made some progress, including being able to send and receive CAN messages.

I was mistaken that read(rtr_msg) will write an RTR message to the bus. It apparently is supposed to be used directly after write(rtr_msg) using the same descriptor and buffer. read(rtr_msg) uses write()'s message buffer to let the driver know which response message to block and wait for.

Another annoying issue: read() does not seem to reset the CAN driver's internal flag that wakes up select(). As a result, my LTC app spends all its time in read(), blocking on a 3 second timeout, making it very unresponsive to network commands. Does anyone know what part of a Linux driver tickles select() to wake up?

I am now meticulously comparing the Intel CAN chip's documentation sample assembly code for transmit, receive, and remote request with the Linux driver. I can't wait for CANteloupe to be done! -- Ian

CANtalope

Andrew introduced Tyler and Peter to the CAN bus and the CANtalope project. They're going to take the initial cut at the software side of things since no one else seems to be doing it. We tried to transfer the CANtaleop node and demo node to them, but it looks like the demo node isn't working so they'll pick it up on Thursday and try and make progress before next week's meeting.

Andrew