I’ve been working hard on a project. I’ve codenamed it ECMHACK as I’m unoriginal. Might keep it, might not.
I have several datalogging and reflashing tools under my belt now, and all of them took a VERY long time to write, and repurposing them to other ECMs and vehicles is damn near impossible due to how different other vehicles are.
Everyone always wants me to write purpose specific software for interacting with datastreams in one way or another.
So, one night I had a crazy thought, why write a bunch of new tools, when I can write a tool for writing tools, so writing a ‘bunch of tools’ would then be really easy, especially once other hackers learned to use that tool.
The idea is, that by having a language that’s designed around what you would want to do with datastreams most of the time, you can create tools for working with those datastreams much more easily.
So what I’ve done is created this homebrew programming language for datastream handling, which I’ve called SDPL (Serial Datastream Procedure Language)
The language includes working versions of, among other things:
- All the basics of a good language – goto, set, print, etc.
- Heap, stack, and global memory all built around managing large arrays
- Array range specifications wherever you need them. Lots of array-specific operations (take, prepend, append, size…)
- Nested subroutines
- A unique status register implementation
- Simple user interface creation
- Table lookups
- Incremental block mapping
- File load/save
- Fast algorithms for checksums etc
As I developed the language, I also developed the tool that runs programs written in the language at the same time, so they’re at the same stage of development, which ensures that every language feature I wrote is real and functional, not theoretical.
I also wrote chunks of datalogging and flashing routines with it, to ensure that it was possible to create such tools, which I have a decent amount of experience with now.
I decided early on that the SDPL language must not just be capable of defining a flash tool or datalogging tool, but also must be capable of defining the ‘driver’ for the serial interface itself, so you can write a supporting driver for an ELM, OBDXPRO, or any other sane interface with it.
The tool itself has become a massive project.
Instead of being a purely interpretive programming language that slowly interprets a bunch of strings in a table, it quickly executes the SDPL procedures with incredible speed by compiling them to indexed data structures and function pointers. The compiler is also fast, leveraging lists, explicit data prefixes, and hash tables to turn a plain text program into a bunch of computer instructions in milliseconds.
Things are executed in asynchronous threads so procedures cannot block other procedures.
The SDPL language includes features to develop simple user input forms to involve the user in the procedure, so it must be able to handle making controls such as buttons and input fields.
The tool also includes a basic IDE (integrated development environment) for editing and verifying the procedures you write.
Stay tuned!
