Has anybody used FPC to talk to a vehicle via the OBD connector?

Can anybody give me a quick summary of the position of FPC on Android etc.? (Graeme, that includes FPCgui if it's relevant).

We've been caught short by a vehicle problem that appears to be only fixable by a VB.NET program. However it's GPLed and we're trying to lean on the (reluctant) author for the source, it would be a natural to transcribe to e.g. a tablet or possibly a bratphone.

Last year I used www.CtrlTerm.com to talk to OBD using one of these boards: https://www.sparkfun.com/products/10769

There are links to the "ELM327 Command Set" near the bottom of those pages.

The best site for the OBD codes that I found is:
www.autocodes.com

Please update us with what you end up doing.

Regards
Paul
www.ControlPascal.com

I was looking in to this idea too. The only sources I found was some plain C or some kind of C code on sourceforge, which could (painfully) be converted or at least derived from to get ideas for FPC.

The downside is that this did not work on a windows Tablet, it has some GUI issues that doesn't work right on a tablet, but works fine on a desktop pc.

Can't remember the name of the software and don't remember what platforms it ran on.. maybe could find it by going to https://www.google.ca/search?q=obd+sourceforge

But there is also github... But as for FPC code or lazarus code? I have no idea. Would be interesting to know.

www.ctrlterm.com (fpGUI) works *very* well on a Windows 8.1 tablet with no extra worked needed for the touch screen!

Mark Morgan Lloyd wrote

Can anybody give me a quick summary of the position of FPC on Android etc.? (Graeme, that includes FPCgui if it's relevant).

Referring to small devices...

Android support for fpGUI is in the works for some 2-3 weeks now by another developer. You are welcome to discuss progress with him in the fpgui.support newsgroup.

WinCE support for fpGUI has been working for years.

RPi support for fpGUI has been working for years too.

Regards,
Graeme

Thanks Graeme (and others, please keep commenting).

This is something niche, for a specific vehicle (Range Rover P38 EAS unlock etc.), but could still be a nice little showcase program.

One odd thing is that the physical interface is apparently via manufacturer-specific pins on the connector carrying RS232 running at a non-standard speed. I've not hung a 'scope on the signals yet to verify that, but if it's correct I'll probably have to modify the Linux serial.pp unit again.

On 05/08/2017 04:48 AM, Mark Morgan Lloyd wrote:
...

If it's an OBD connector then the specs should be available. Here is more info:
https://en.wikipedia.org/wiki/SAE_J1939

It's on the manufacturer-specific pins. The specs are NOT freely available, and if the description I've seen so far is to be believed the comms run at 800 bps.

On 05/08/2017 09:11 AM, Mark Morgan Lloyd wrote:
...

It's on the manufacturer-specific pins. The specs are NOT freely available, and if the description I've seen so far is to be believed the comms run at 800 bps.

Thanks for the *education* Mark on "manufacturer-specific pins". I just did a little searching and reading.

This could turn into a full-time job! See *Bus Systems* here: :) https://teslatap.com/undocumented/

Best regards,
Paul
www.ControlPascal.com

If it were simple we'd have had our suspension fixed two days ago :-)

as it is GPL, source code availability is required... that author has no choice but to supply it...

as it is GPL, source code availability is required... that author has no choice but to supply it...

Yes, but it looks as though he's been asked in the past and has claimed that "it needed tidying up": that was a couple of years ago. However we're not at all inclined to let him off the hook, since we take very little pleasure in having to dig out a Windows system to run one poxy program... even if it does save us £1000 at a main dealer.

And being able to demonstrate that his VB code could could be made portable without a great deal of work would, I think, be in everybody's interest.

that doesn't matter... you should get the code used to build what you received no matter how ugly it is...

that was a couple of years ago. However we're not at all inclined to let him off the hook, since we take very little pleasure in having to dig out a Windows system to run one poxy program... even if it does save us £1000 at a main dealer.

i hear that :)

And being able to demonstrate that his VB code could could be made portable without a great deal of work would, I think, be in everybody's interest.

seems logical :)

Mark Morgan Lloyd wrote

Can anybody give me a quick summary of the position of FPC on Android etc.?

Works fine like via JNI, you can do most stuff in Pascal using JNI but part still needs to be in Java.

some info here: http://wiki.lazarus.freepascal.org/Android_Programming

Felipe Monteiro de Carvalho wrote

On Sun, May 7, 2017 at 8:33 PM, Mark Morgan Lloyd wrote:> Can anybody give me a quick summary of the position of FPC on Android etc.? Works fine like via JNI, you can do most stuff in Pascal using JNI butpart still needs to be in Java. some info here: http://wiki.lazarus.freepascal.org/Android_Programming

Thanks Felipe, noted. I rather lost track when therewere (at least) two competing approaches.

Yeah. The wiki is cluttered with inaccurate and abandoned information for Android development. It needs a serious scrubbing. And access to needed sources is somewhat hidden. I've combed it for a few years, now, to try and deduce what's real and what's not. I'm not even sure where I got the bits of source I'm using now. I've just been clinging to it like a shipwreck survivor clinging to flotsam.

So, does anyone know, is this the "official" Android dev page?

I can testify that it is possible to write Android apps with FPC 3+. So far its been the most frustrating effort of my programming life. FPC does amazingly well but Android is chalk full of hidden gotchas and things that simply don't work as described.

I finally settled on the approach of using the JVM target to compile my app. I used GNU "make" to coordinate compiling and packaging. I used a few of the CLI tools from the Android SDK and "jarsigner" from the JDK to do the packaging and generating the resource identifiers. I used a stupid simple FPC program to perform a bunch of StringReplace() calls to convert the "aapt" created "R.java" (resource ID constants) file into Pascal. I also threw some headers and cruft-stripping in for good measure.

The biggest problem with doing it this way, besides the Google widgets doing things that I just can't fathom, is the lack of the FPC libraries we all love and have come to expect. You do have to bend your mind to fit the Java paradigm and sift through the Android/Java docs to find the things you normally use. Something as simple as converting a number to a string needed to be found. Actually I think I finally just wrote an IntToStr() because it was quicker than digging through docs.

I was thoroughly frustrated with the experience. Having previously tried to go all native code, which would be my preference anyways, I decided to revisit that idea before I do more with Android. As Graeme mentioned, I decided to try and leverage fpGUI into the Android environment. But with the extreme differences in execution model between Android and everything else, its kind of like fitting a square peg into a round hole. It will be a while. :-/

Speaking of frustrations. I don't envy you with your vehicle issue. I did some experimenting with a USB OBD-II dongle some time back. I was looking at building an FPC/Lazarus based diagnostic system. This was mostly spurred by the fact that my '99 Dodge Dakota ran well... but sometimes it ran REALLY AWESOM! I wanted it the latter way all the time.

In short I found that a huge amount of diagnostic data and interfaces are proprietary. The auto manufacturers don't want us lowly individuals to have it unless we're willing to shell out tons of money. One source I read said Ford was licensing their full PID data for $100K per year! Since I discovered the fpGUI gauges and the PocketCHIP I'm thinking I'd like to tinker with the OBD-II stuff again. But that probably won't help you.

I've never used the serial unit. It seems odd that you would have to patch "serial.pp" if the hardware is capable. Are there some non-OS imposed restrictions in there? I wrote some code back in the Kylix days to manipulate the Linux serial devices and that is my go-to lib for anything serial. Really all it does is provide an interface to ioctl() to set line disciplines. Other than that the serial device is just another file. My only concern with 800 baud is if the clock divider in the serial chip can go that low. Its also an odd step (300, 600, 1200, ... being the standards).

THX - Jon

I don't think the wiki page I posted is inaccurate, all the stuff there is valid AFAIK, but it is simply very incomplete. A lot more should be written, and also note that there are 2 different ways:

1> Via NDK combining native Pascal + Java
2> Via JVM compiler

The wiki I posted is only for approach 1, even a link to a full compilable example is posted there (thought it is for OpenGL). I never used approach 2 and dont plan on using it.

Felipe Monteiro de Carvalho wrote

On Thu, May 11, 2017 at 1:19 AM, Jon Foster wrote:> Yeah. The wiki is cluttered with inaccurate and abandoned information for> Android development. It needs a serious scrubbing. And access to needed> sources is somewhat hidden. I've combed it for a few years, now, to try and> deduce what's real and what's not. I'm not even sure where I got the bits of> source I'm using now. I've just been clinging to it like a shipwreck> survivor clinging to flotsam. I don't think the wiki page I posted is inaccurate, all the stuffthere is valid AFAIK, but it is simply very incomplete. A lot moreshould be written, and also note that there are 2 different ways: 1> Via NDK combining native Pascal + Java2> Via JVM compiler The wiki I posted is only for approach 1, even a link to a fullcompilable example is posted there (thought it is for OpenGL). I neverused approach 2 and dont plan on using it.

Thanks for that, I admit that I found what was on the wiki confusing: it's never clear what's obsolete and what's merely incomplete.

So I think that what you're saying is that both approaches are still viable, but you favour the first.

For anybody else following this saga, I've now talked to the vehicle and the utility I'm using appears to run at 600 bps, not 800 so I'm probably not going to have to modify serial.pp. But some of the results are a bit odd and the author's had to use a lot of carefully tweaked timings which suggests that something's not quite right... 750 Baud, anybody? :-)

I favour the second. I've been using it actively.

Michael.

Thanks for the info Felipe. I'll bookmark that page somewhere. I was also referring to the many other Android pages on the wiki that are misleading. Its hard for us outsiders to know what's authoritative and current.

I would like to hazard there is, yet, another way:

3> #1 w/o Java - pure native.

However that would never be entirely accurate as all "native activities" have to be chaperoned by a Java "Activity". And JNI will have to be used to interface to any Android supplied services as everything else is stuck in Dalvik land. All part of what makes Android so inefficient. But my intent is not to have to do Java once an FPC based activity is launched. Might have to build a better "NativeActivity" class with ppcjvm too... I think that's something Lazarus did/does.

I should also throw out here that it would be *REALLY* nice, and even somewhat needful on the Android front, if FPC could interface directly with C++ libs and use their classes and objects. Besides Java, Google prefers to use C++ (for obvious reasons) and their supplied native code libraries are C++. If you look at Google's software architecture diagram they say they use FreeType2. But, even rooted, if you search the Android file system you won't find a FT2 lib anywhere. Digging through the AOSP source base it turns out that FT2 is statically linked into Skia. Skia is a C++ library used by Dalvik (and other places) to do the usual 2D text/graphics rendering. This acts much like AggPas, used by Graeme's AggCanvas. I did find it exports a limited set FT2 functions in standard C style. But it looks like, for full functionality, I'm going to have to bridge the C++ divide.

Anyhow tips on the FPC->C++ front would be appreciated. I will probably search the list archives as I know this topic comes up repeatedly. I don't understand how ginormous an undertaking this might be but maybe I can contribute something on this front.

"Jon Foster" wrote

I should also throw out here that it would be *REALLY* nice, and even

somewhat needful on the Android front, if FPC could interface directly with C++ libs and use their classes and objects. Besides Java, Google prefers to use C++ (for obvious reasons) and their supplied native code libraries are C++. If you look at Google's software architecture diagram they say they use FreeType2. But, even rooted, if you search the Android file system you won't find a FT2 lib anywhere. Digging through the AOSP source base it turns out that FT2 is statically linked into Skia. Skia is a C++ library used by Dalvik (and other places) to do the usual 2D text/graphics rendering. This acts much like AggPas, used by Graeme's AggCanvas. I did find it exports a limited set FT2 functions in standard C style. But it looks like, for full functionality, I'm going to have to bridge the C++ divide.

Anyhow tips on the FPC->C++ front would be appreciated. I will probably

search the list archives as I know this topic comes up repeatedly. I don't understand how ginormous an undertaking this might be but maybe I can contribute something on this front.

I can't speak for other approaches to interface with C++ code, but patches to the compiler's cppclass support are definitely welcome :D It will never support everything there is in C++, but if we'd manage to interface with most library code that would be something...

Regards,
Sven

@@ <- me being bug eyed

cppclass?!?! Where? When? How? What?

I still can't find any mention of C++ support in the FPC 3.0 doc PDFs. I've just grepped the source and I see something... Still trying to figure out what it means. But to put it more specifically:

What support is there?
How is it used?
Where are the docs, if any?
When did it sneak in? (not really important, just curious)

It's rather old in fact though still in its infancy. Improving it a little bit was one of the first patches I had done for FPC (back in 2009 or so), though not much has happened since then.

The only code of note is the tests that exist in
$fpcdir/tests/test/cg/tcppcl*.pp

Essentially only static methods of GCC C++ code are currently supported. The next step would be instantiation and the vtables.

(Should you want to continue this topic I'd suggest a new thread in fpc-devel)

Regards,
Sven

On 05/11/2017 09:37 AM, Sven Barth via fpc-pascal wrote:>> Am 11.05.2017

Apologies for bad threading here. Sven, can I just go off on a slight tangent before that part of the discussion adjourns to fpc-devel, since this is a user rather than a developer question.

What's the current situation with FPC interface to the Subversion support libraries which I think is something you were looking at at one point?

In extremis, I suppose that it should be possible for a program written in FPC to use Lua as a shim when calling C++.

Am 12.05.2017 11:10 schrieb "Mark Morgan Lloyd" <

tangent before that part of the discussion adjourns to fpc-devel, since this is a user rather than a developer question.

What's the current situation with FPC interface to the Subversion support

libraries which I think is something you were looking at at one point?

Nope, I never looked at the Subversion libraries.

In extremis, I suppose that it should be possible for a program written

in FPC to use Lua as a shim when calling C++.

Before that I'd say the Delphi support for the binding generator SWIG should be checked (at least I thought it already had some).

Regards,
Sven