techie66 / libignitech Goto Github PK

This should be 152, right?

tcip4.c line 346

The object still gets created and attempts to use bad file descriptor. I propose keeping track of this better internally, and re-attempting to connect on subsequent method calls.

Sync read version can cause non-exiting loop if connection drops.
Async version would be best suited for this.
Needs to be documented.

To fully support the testing framework, the emulator must be able to toggle the "flags" individually by option

V96 branch is up with basic support for V96 controllers.
Several bugs found and fixed that have been there for a while and never got caught. A little refactoring to make the code more readable/sensible/efficient.
Testing framework needs updating for V96
No regression testing done with V88 controller support yet.

TCIP emulator mostly needs a complete re-write. It doesn't communicate with official software. Looks like its getting hung up on responding before reading the actual command string. An "easy" option to emulate a V96 or V88. It should generate output itself to allow programmatic tests instead of regurgitating a hexdump blindly.

Lots of work to go, but a nice step in the right direction.

From looking at the code, there is the possibility that certain conditions would keep read_sync() from ever returning.
Need to implement a method to detect failure loop, and exit.

Perhaps a non-fatal failure return status whenever a reset occurs, this would signal read_sync() to exit with error and would allow read_async() direct use with more visibility to failure mode.

How about building a TCIP4 to CAN bridge?
Idea is to read out TCIP4 with the known serial protocol an put the read values out on CAN bus in several CAN streams (ISO 11898). This would help to use other CAN enabled app, e.g. RealDash for logging and display and e.g. MegaLogViewer for evaluation.

I think not all member variables are properly initialized. Random data gets returned to callers upon initialization.

Now that the testing framework is coming together, an old bug thought to be on the firmware side showed up in testing.
It was confirmed that the serial device was opened with incorrect attributes and certain byte values were getting transformed by the kernel I/O. This is probably fixed now, but it also probably renders some sections of code completely useless as their intent was to work around this issue.

To support Arduino would require changes to the way the serial port is read. Hopefully find a way to keep the library in one piece.

As a first step to enabling direct programming, need to be able to read current program.

ignitech.cpp

I think
get_advance(2) , get_advance(3), get_advance(4) in sipmle getter section always return ignition.advance_1_deg.

return has to be ignition.advance_2_deg; ignition.advance_3_deg; ignition.advance_4_deg; acordingly

Unchecked NULL argument causes segmentation fault. More research needed.