#9 POSIX timer code not finished
Here is the "error" I get when I attempt to compile the code for Mac OS X. If instead of using Xcode 4.2.1 and SDK 10.7, I use Xcode 3.2.6 with the 10.6 SDK I get the same "error".
/Developer/usr/bin/gcc -DHAVE_CONFIG_H -I. -I.. -I../include -isysroot /Developer/SDKs/MacOSX10.7.sdk -I/Developer/SDKs/MacOSX10.7.sdk/usr/lib/gcc/i686-apple-darwin10/4.2.1/include -isysroot /Developer/SDKs/MacOSX10.7.sdk -I/Developer/SDKs/MacOSX10.7.sdk/usr/lib/gcc/i686-apple-darwin10/4.2.1/include -L/Developer/SDKs/MacOSX10.7.sdk/usr/lib -MT diag_tty.o -MD -MP -MF .deps/diag_tty.Tpo -c -o diag_tty.o diag_tty.c
diag_tty.c: In function ‘diag_tty_control’:
diag_tty.c:499: warning: format ‘%03ld’ expects type ‘long int’, but argument 6 has type ‘__darwin_suseconds_t’
diag_tty.c:640:2: error: #error "POSIX timer code not finished"
In an earlier email I had said that I probably was forced to use a POSIX implementation for Mac OS X. Well, I was wrong because there is no POSIX timer implementation for Mac OS X. In other words, if you reference -lrt, then you'll get an error.
I'm not aware of any Xcode framework that would provide a good timer implementation and I think avoiding interval timers is a good idea.
Perhaps using threads would be a better idea? After all pthread is implemented well on most platforms including Linux and Mac OS X.
Interesting. I would also like to find a better solution for this, since for most interfaces timing is not so critical - basically only the dumb interfaces absolutely need microsecond precision. The other interfaces only need large >10ms timeouts.
As for threads, well I hate to admit it but it's way out of my league...
For me to add further to the discussion, I'll have to admit my lack of understanding of the architecture of the code and OBD II in general.
There are some nouns that you're using that I just don't understand as well as I should. If I need to go read something before continuing, then I'm ok with that. Just point me in the right direction.
Here are the nouns:
dumb interface
other interface
When you use those, do you mean the hardware to which freediag connects? I can imagine that much can vary between car manufacturers and so I'm hoping that when you use "interface" that the connector (and the computer behind it) is what you mean.
If this is how you're using the term interface, then I think I understand how one might proceed. If it's not what you mean, the don't bother reading what follows.
The general idea of a single thread implementation is that a single thread has to interface with two things at once: the user and the other computer. With a single thread, the only way to "elegantly" handle both interfaces is to use signals of some kind. The interval timer or other type of timer is simply a method by which certain signals are handled. Signals are very difficult to manage in a consistent manner across platforms and that might be the reason why Mac OS X has yet to provide an POSIX real time implementation.
But a multi threaded implementation lets each thread handle its interface on its own. Then, using thread methods, you can communicate effectively between threads (passing information, passing control, etc).
I'm sorry, I wrote the other message as I would have written a note to myself. I wrote a short summary here, please excuse me if you already knew most of it... Perhaps it could be useful to someone else unfamiliar with the subject. -
By dumb / other (smart ) interface, I was referring to the hardware device between the personnal computer and the car's ECU. Since many such interfaces exist, freediag has "drivers", if you will, that handle the interface's particularities and tries to abstract them sufficiently so higher levels of freediag can be as generic as possible.
So I slightly abused the term "interfaces" in that I also call an "interface" the piece of code in freediag that deals with a particular type of hardware. If you haven't already, you may want to skim over the Supported Interfaces document -
http://freediag.sourceforge.net/Supported-Interfaces.html
By "dumb" interface I refer to the type of hardware that only acts as an electrical converter between a standard serial port and the car's ECU, through the OBD2 connector. This means freediag must handle the whole circus act of initialising the bus and sending/receiving data at specific baud rates with specific timing.
"other" / "smart" interfaces have an onboard mcu that handle at least part of the low-level details. freediag still needs an associated diag_l0_???.c file to make this intelligence useful.
In practice, this means that diag_l0_dumb.c needs to be able to arbitrarily manipulate the serial port pins, with precise timing. With any of the smart interfaces, freediag only needs to send serial commands in a very conventional way, with very permissive timing, for example not exceeding 3.5 seconds between communications, or no less than 25ms between commands, etc.
Hope this makes more sense than the previous comment...
As for the freediag code base, the "back-end" is divided in levels, from 0 to 3. L0 deals with the hardware directly connected to the user's computer, and L1 and up are purely software. Although in some cases the distinction is a bit blurry.
I had suspected this was the case with 'dumb' v 'other/smart'.
The thread portion of the discussion is irrelevant since even a single thread communicating with a dumb interface will still have a significant timing problem to overcome.
Apple's best recommendation (http://lists.apple.com/archives/Unix-porting/2005/Nov/msg00009.html) is to implement device drivers as kernel extensions (in Mac OS X vernacular). This is probably not the easiest thing to do since all the code runs in user space at this time.
Their next recommendation is to use Mach Scheduling and Thread Interfaces as described here: http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html. This is essentially using kernel programming techniques in user space to pull off real time scheduling. This might be the easiest thing to do considering how freediag is architected.
Their final recommendation is to trust the scheduler after setting the process priority so much that no other process can compete (i.e., in the case where there are multiple cpu bound processes running at the same time). This is by far the easiest to implement but is dangerous if faulty scheduling could cause harm to the ECU. But even if the ECU can't be harmed, surely an improperly scheduled application would not be thrilling to use.
POSIX code is pretty much finished in git. Some minor issues to iron out before a release.