<purdeaandrei[m]>
whitequark (@_discord_182174208896401419:catircservices.org) what do you think about adding a generic i2c access feature to the protocol? I think a lot code could be moved out of firmware and into python.
<purdeaandrei[m]>
I know it's discouraged to write independent software that directly talks to the firmware. This change would make it even harder to write such software. But it would open up a lot of space for features that _need_ to be in the firmware, and other new features would not need a firmware update, for example reading current, and setting up current limits, as it is right now it would require extra code in firmware
<whitequark[m]>
I don't think the software should know anything about I2C or stuff
<whitequark[m]>
I'm fine with it requiring extra code in firmware
<whitequark[m]>
it's quite deliberate that there's no generic I2C access, it's kind of a real pain in the ass to program firmware that requires this and I strongly dislike it as an engineering practice
<whitequark[m]>
regarding code size concerns, if the control request processing code would be moved to have a single command "control in / control out" request/response style protocol with something closer to how you write TCP based protocols as the application logic, I think that would free up a lot of code space
<whitequark[m]>
I'm also, frankly, not in a place regarding my health that lets me think about and review such big changes in depth
<whitequark[m]>
s/regarding/with/
<whitequark[m]>
to expand on this, I would eventually like to move to a pure stream-based protocol for everything that's happening with the device, so that both control and data plane could be encapsulated in TCP, be network-transparent, and so on
<whitequark[m]>
while this does not inherently preclude packing I2C accesses into a stream-based protocol like this, it makes it a much more closely coupled system to manage, and indeed creates issues for non-glasgow software trying to configure a device
<whitequark[m]>
and in doing so, it counteracts the biggest benefit of moving to a stream-based protocol, which is that it's easier to program
<whitequark[m]>
over time, people have suggested similar changes to the firmware (like shipping three different firmwares, per device version) and I feel like that's just admitting a failure of engineering. we tolerate this in commercial products where cost of development is a major concern, but Glasgow isn't really a commercial product
<whitequark[m]>
in that much of the development isn't driven by market forces
icb_ has joined #glasgow
icb has quit [Ping timeout: 244 seconds]
dustinm` has quit [Quit: Leaving]
Jarrett[m] has joined #glasgow
<Jarrett[m]>
"cool"-based product development is the best thing imo
dustinm` has joined #glasgow
cr1901 has joined #glasgow
bvernoux has quit [Quit: Leaving]
<purdeaandrei[m]>
Thanks, understood. Could you clarify "control in / control out" request/response style protocol would look like? I don't quite understand from just the above description.
<whitequark[m]>
oh, another approach I've been thinking about to reduce code size is to write a simple state machine for I2C access
<whitequark[m]>
and only have one big switch somewhere in i2c.c or whatever that would handle all of the register access
<whitequark[m]>
it's kind of like I2C bytecode
<whitequark[m]>
re: control in/control out style protocol, do you know how a normal type-length-value based protocol is designed?
<whitequark[m]>
you send a packet that says "type: read data, length-in: 2, address: 0x00, 0x00" and then wait for a reply of length 2
<whitequark[m]>
we could have exactly two control requests, SEND and RECV, where anything stuffed into SEND is parsed according to a header, and then where you need a reply, you send a RECV after and it's filled in by the device
<whitequark[m]>
this does mean there is state carried across two distinct control requests, but the flipside is that there is less code involved in validating them, and that it maps much better on something like TCP