Charles Steinkuehler

On 7/18/2016 8:05 AM, Michael Haberler wrote: > what does not work yet: > - gpios - could be my problem understanding the 7i76 manual vs HAL pin naming >...

On 7/20/2016 3:18 PM, Michael Haberler wrote: > I have updated the FirmwareID message in 7I76_7I76_7I76_7I76 config to num_leds=4 It may be non-obvious, but the num_leds for the 7I76_7I85S_GPIO_GPIO config...

On 7/20/2016 6:56 PM, Michael Haberler wrote: > does this suggest hm2_de0n.0.gpio.000.in reflects IO Pin 000 (GPIO0.P2-01) ? Can > I just use hm2_de0n.0.gpio.0xx.in as general gpios in this case?...

On 7/21/2016 6:05 AM, Michael Haberler wrote: > do I understand correctly: > - no sserial daughter card - SSerialTag-tagged pins fall back to GPIO Mostly. I'd say the sserial...

On 7/24/2016 3:28 AM, Michael Haberler wrote: > the LED issue is solved - numbering: > > CR01/CR02 are GPIO1 pin 19 and 1 > CR02/CR03 are GPIO0 pin 19...

On 8/4/2016 4:56 PM, dkhughes wrote: > I have a small pull request ready to go if you guys are cool with this that I > will submit, I just...

I think of hal parameters like this already: something that is set once (or occasionally) to control operation and is not a dynamically changing signal. Have strings been added as...

Can the length defined strings from protobuf be used, or does that start creating issues with garbage collection? It seems like the string values are unlikely to change often, so...

I wouldn't have thought persistent data subject to change (window size, last opened file, etc) would be stored with this mechanism, but perhaps it should be? If so, that fundamentally...

+1 on using global memory segment, sounds like a great idea! Plus, it seems to me like these values aren't really part of the hard real-time layer like true HAL...