Go to Post We want people to exercise Gracious Professionalism® and play at their best, but also not really because we find this archaic rule to satisfy something related to inspiring students to pursue careers in science and technology.™ - PayneTrain [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #4   Spotlight this post!  
Unread 09-06-2013, 19:13
RufflesRidge RufflesRidge is offline
Registered User
no team
 
Join Date: Jan 2012
Location: USA
Posts: 990
RufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant futureRufflesRidge has a brilliant future
Re: Need a programmer familiar with CAN

Quote:
Originally Posted by apalrd View Post
Basically, the Jaguar's CAN chip has a 1-message rx buffer, and the receiving software in the Jaguar is either not interrupt driven or the 1khz control loop has higher priority, so multiple messages will overwrite and possibly corrupt the buffer (why not lock the buffer while reading?). The FRC solution is to not send another message to a single Jaguar until the Jaguar responds with an Ack. The WPIlib implementation waits for the Ack by locking the thread and waiting, which is terrible programming practice, especially in a single-threaded program sending command messages at 100hz plus configuration messages possibly as fast. Also, a single Jaguar failure will cause a 10ms task delay for each message missed when a Jaguar is down, which can cause several task iteration to be skipped waiting for Acks from other Jaguars.

A better solution would be to queue all messages to send to the Jaguars for a given loop tick and send one message to a jaguar at a time and hope the spacing is enough, relying on the CAN checksum, or use a state machine for each Jaguar to check if an Ack has been received without block-waiting for it and locking the thread.

Luckily, the great folks at Cross The Road Electronics are working hard to fix this for the 2015 control system. Until then, Jaguar CAN sucks.
Continuing to parrot this rhetoric at every opportunity over a season after No-Ack commands have been implemented in the Jaguar firmware and LabVIEW libraries doesn't seem quite right.

Now if you want to complain about the C++ and Java libraries not implementing them, that would probably be more appropriate.
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 22:57.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi