Combined

[btsimonh]

Sensor rework based on assumption that 0x1xx represents the START of the message to the sensor boards.
use with the similar pull request on hbprotocol.

[lalalandrus]

you are missing the sensorcoms.h file as per #10

[btsimonh]

ok, so we need the reading code to process the packet if it hits another 0x1xx, and fill from what it has. (I think this is similar to what I had originally :). But I like the start of read trigger. Torn....
Will have changes in a few minutes.
For lights sending, my sensor board lights are now 'slow' (we don't send continually like the original, and I think it triggers read complete from the 0x1xx) - so I will re-instate double send, which causes the lights to trigger immediately.

[lalalandrus]

at some point we should move the background taskers into their own interrupt driven SM double sending makes me feel unclean.
as long as code offers the most compatibility that is desirable to get as many people contributing. the extra data you had wasnt being used even though your sensor board was sending it.

[btsimonh]

the extra data includes Roll and Acceleration. I use Roll (angle end-to-end) to indicate that the hoverboard should not operate if not on the floor - e.g. if you lift one end quite far :). I MAY use acceleration as an aid to motion control, but less likely now if you don't have it :(.
Ref double send - wanted to keep traffic to the sensor boards to a minimum - i.e. not continuous data.

[btsimonh]

@lalalandrus - please test.
should work on your board using normal build using:
#define CONTROL_TYPE HOVERBOARD_WITH_SOFTWARE_SERIAL_B2_C9_6WORDSENSOR
in config.h
or; by using platformio env hoverboard_6word -> build
br, s

[btsimonh]

p.s. when you get it going, will be interesting to know if you get the occasional click (100ms interruption on a wheel). I'm thinking this could be a misread of sensors for me - maybe my baud rate is off by a small amount.

[lalalandrus]

seems to work, the quick test i did with pads and angle data is OK. those define names are getting long :D.

[btsimonh]

doing some light diagnosis - something seems to be overwriting sensorlights :(.

[btsimonh]

ok, that's all for this morning. pls test again. If all good we'll pull.

[lalalandrus]

the code works but looking into the frame decoder, it seems like you implemented processing extra frames, while i dont see much value i think it has a memory bug where you dont guard against running out of data. in addition you dont latch the data, you may run into a race condition where the buffer indexes have changed after your 0x100 test but before your memcpy. it is late and i am doing the analysis in my head without testing so i may be completely wrong. also does process decrement anywhere?

[btsimonh]

the intent is to eat all the bytes available. But the copy from the buffer should ONLY occur with a 'complete' buffer. Partial buffers left at the end are added to next time the routine is called by main( ).
By eating all the bytes, we MAY absorb more than one frame before process is set, and only the LAST complete frame is processed (but this processing only does step on, step off, timeout).
Note that 'remaining' is read before the do/while, so we'll ignore any bytes which arrive after we start, and can't run out of input.
Note process is always zero before the while.... the increment is just equivalent to 'set to non zero' (but we could use the value to put into the structure as an indication of the number of frames seen...).

p.s. the main loop runs at nominal 5ms intervals, so we could expect 1-2 frames each poll (assuming my ~2.5ms calculation was right :) ).
We SHOULD improve the time accuracy of the main loop, and also instrument how long it is taking.
I'll start a new issue for that.

[lalalandrus]

i finally get what you are doing. a couple notes: first there are some if statements that are redundant, second processing the data multiple times is pretty inefficient and i really cant seem to find the root cause of why you sometimes dont get a good frame.

however, the code works well enough and compiles, we should just do the merge and optimize later as we know more changes are coming down the pipe

[btsimonh]

on the bad frame; thinking of adding some real time tuning on the baud rate; mine is obviously also an estimate..... but wife is getting pretty pissed off with my time spent at the moment :(.
Was thinking that the firmware could be capable of searching the sensor baud rate, so basically it auto-configures to the sensor boards in use. I don't know if we can get framing errors from the usarts.

[btsimonh]

@p-h-a-i-l - your thoughts on this pull are required.... it should not affect you two, so if you have tested, let me know or merge.
Want to move on to 'next'....

[lalalandrus]

on the bad frame; thinking of adding some real time tuning on the baud rate; mine is obviously also an estimate..... but wife is getting pretty pissed off with my time spent at the moment :(.
Was thinking that the firmware could be capable of searching the sensor baud rate, so basically it auto-configures to the sensor boards in use. I don't know if we can get framing errors from the usarts.

if we have precise timing as you pointed out in the other thread we just have to do a min time of a bunch of pulse interrupts to equate the uart baud.

haha same here with my wife, i just justify it with that a 3rd hoverboard i got for free is destined for the daughters powerwheel jeep

[btsimonh]

@lalalandrus - fixes to console output and timeout code.

[p-h-a-i-l]

I'm not using this fork "in production" since it was a bit unstable for me (ouch..)
But I'm working hard to merge our two forks back together ;) (hbprotocol was an important step for that)

Since I'm also spending way too much time on this project at the moment, I'll flash this branch quickly.. Sitting in front of a bench test setup anyways :)

[lalalandrus]

I'm not using this fork "in production" since it was a bit unstable for me (ouch..)

cost of progress, i think things will calm down once we get over a few more merges

[p-h-a-i-l]

Tested bot UARTs with protocol, looking good!