[fpc-pascal] Vehicle management

[Jon Foster]

On 05/08/2017 11:34 AM, Mark Morgan Lloyd wrote:
> On 08/05/17 18:30, Felipe Monteiro de Carvalho wrote:
>> On Sun, May 7, 2017 at 8:33 PM, Mark Morgan 
>> Lloyd<markMLl.fpc-pascal at telemetry.co.uk> 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

-- 
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
jon at jfpossibilities.com