??? 06/04/07 02:43 Read: times |
#140216 - Software design problem |
Okay, my micro is supposed to talk to a J1850-type automotive network: to receive messages from it, and to respond to those messages in a timely manner. Microsecond timing doesn't matter, in other words, but, say, deciseconds do.
My micro is imitating the behavior of a vehicle's PCM (Powertrain Control Module) under known conditions. Its objective is to make a scan tool (a tool used to communicate with the PCM of a real car to retrieve information for diagnostic purposes) believe that it is talking to, and controlling, certain aspects of a real car. This requires it to respond to strings of serial data negotiating a data format, starting the sending of data using that format, requesting one crucial two-byte piece of information, and stopping the data stream. My problem is that serial data from my micro must pass through a network adaptor which handles arbitration on the J1850 bus. It's a single-line bus; protocol details for the curious at http://www.intel.com/design/in...850_wp.htm Under most conditions, this is no issue. The adaptor was designed primarily to listen to J1850 traffic, and to inject occasional messages into it. For this task, it works well. However, when I use it to inject messages at a faster rate, it sometimes forgets to append protocol headers (private protocol between it and my micro) and so sends the entire process to various interesting and nonfunctional places. My solution to this has been to simply restrict the rate at which I send messages to it to be broadcasted to the J1850 network. I did this by using a timer to generate 'ticks' at 10-millisecond intervals, and then simply counting those ticks, giving me a clock with second and 10-msec resolution. I save the state of the millisecond counter, and then just test against it until the difference between its value and the saved value >=25. That is, I wait for a quarter of a second between iterations of the main loop. Unfortunately, this means that any messages that arrive during that delay are not handled. If the crucial message mentioned above does not get handled (responded to) immediately, then the entire system fails. My question, then, is 'how would you solve this?' I've tried a couple different things, but I'm out of ideas. Asking for your help, ironically, has sparked a few trains of thought, but I could use some people to brainstorm with. I apologize for being so general; if specifics or further explication is required, please let me know. Many thanks, Bob Robertson |
Topic | Author | Date |
Software design problem | 01/01/70 00:00 | |
Something like this, maybe? | 01/01/70 00:00 | |
Well, yes, actually... | 01/01/70 00:00 | |
Duhr and a question | 01/01/70 00:00 | |
Which ones did you look at ? | 01/01/70 00:00 | |
Duhr and an answer | 01/01/70 00:00 | |
Is it not possible to | 01/01/70 00:00 | |
Horses for courses | 01/01/70 00:00 | |
have fun | 01/01/70 00:00 | |
A Queue? | 01/01/70 00:00 | |
I used what I called a \'cache\' | 01/01/70 00:00 | |
Gah, code repost | 01/01/70 00:00 | |
you need to read it all, THEN process | 01/01/70 00:00 | |
Your approach is much more general... | 01/01/70 00:00 | |
Prioritizing? | 01/01/70 00:00 | |
Some suggestions Bob | 01/01/70 00:00 | |
Thank you, sir! | 01/01/70 00:00 | |
Division / modulus not always slow | 01/01/70 00:00 | |
Are we making this too difficult? | 01/01/70 00:00 | |
I don't think so, it seems to work pretty well...![]() | 01/01/70 00:00 |