so i just thought i'd take a minute to talk about a project i'm working on in case anyone wants to follow along.
a bunch of people keep harassing me to help with building flash tools for obd-ii based platforms. one problem i have is i don't really own any obd-ii vehicles that i care about. another problem i've witnessed is that all the free obd-ii datalogging tools are total crap. the GM ecms have lots of advanced high speed datalogging features, and barely anything uses those features.
anyway as you probably know i wrote flashhack, which works great for flashing the 'obd 1.5' era ECMs, but to be honest it's really hard to adapt to OBD-ii, because it lives in a world where you ask a question and receive an answer. in the obd-ii world, there could be lots of messages on the bus. also there are lots of different types of interfaces, and lots of different types of ECMs.
i could write a lot of different subclasses in flashhack and maybe make it work, but every new thing would result in a ton of work, it wouldn't be maintainable. i started working on that but i got really BORED.
so i decided to write a new tool that is a bit more generic, kind of like the tunerpro approach.
the tool itself wont do much on its own, but rely on definition files for everything.
imagine for a sec that tunerpro RTs ADX datastream macro thing was good enough to implement something like a flash tool, or a datalogging tool...but also good enough to implement the interface level stuff (ELM, obdxpro, AVT, even homemade tools.) so you wouldn't need a plugin to support something like an ELM interface.
so that's what i'm trying to do right now
i started writing a language that is really basic and fundamental to do all the things that are required, and making a compiler and execution routines for it.
basically a language to manipulate input and output streams, and arrays.
everything in it is centered around 8 bit arrays of data being shuffled between file(s) and a serial interface in various ways, and the design concept of 'send something and wait for possible replies'.
here's the current status of it, everything in the language is currently implemented and working well enough http://fbodytech.com/misc/sdpl-language/
i've implemented the language in a tool that i've proven is good enough to basically 'define' an ELM and obdxpro interface in a simple text file, which means pretty much any interface could be defined in this langauge.
it loads files and can access segments in sequence, which means it does have the fundamentals of a reflashing routine including a kernel and a bin, but there's some more development to do in that area...... and of course a user interface for everything.
more to come soon
Reply With Quote
Bookmarks