jadonk
commented
2 years ago I'd like to assign functional meaning to each LED and try to infer the running application from that.
There is a total of 6 LEDs. I believe they are in the order of CHG, 2.4G, 900M, 3V3, LED1 and LED2.
CHG (A)
The mode of this cannot be changed. It is on when an attached battery is being charged.
LED 2.4G (B)
This is the only one available on CC1352. I'd like to use it for things where low-overhead and low-latency matter. I think having it on when some kind of "link" is established and to blink when there is some data transfer. The easiest place I know to hook to is when the TX is active, but I don't want to miss blinking when we have noticed some RX. I may hook in TX initially and RX later. I am not aware of any "link" establishment for IEEE802.15.4 so this will require some research.
900M (C)
Now
I've been using this LED to reflect the UART mux between the MSP430 and CC1352. I might want to add blinking in the case of data transfer. Currently, if gateway is functional, this LED should be on. This doesn't say if gateway is waiting for a connection over USB.
Proposal
I think I'd like to add to the CC1352 something that says it is actively looking for a gateway connection. In the future, this will all be modes rather than different firmware loads. So, if the firmware is not acting as a node and is waiting for a host driver connection to act as a gateway, this LED should toggle slowly based on commands from the CC1352. If the UART mux is flipped to the MSP430, it should turn it on most of the time with short/fast blinks in the case of data transmission either way (not ideal to not have both TX/RX LEDs, but it is what we have. It would not be possible to distinguish between gateway (acting as bcfserial w/o the USB connection) and node operation via this LED.
3V3 (D)
When there is power, this is on. No way to change that.
LED1 (E)
Now
I've been using this for MSP430 debug to indicate an established UART connection (either passthrough or HDLC mode). This would typically be on only when there is a USB connection.
Proposal
Both sensortest and greybus could use this LED. I'll need to think about what they might do with it and how to make up for the loss of debug information for HDLC, but, for now, they can simply turn it on and not have gateway or bcfserial turn it on.
LED2 (F)
Why don't we use this to reflect greybus activity? If blinking slowly, it could mean looking for activity, meaning this is only used in the greybus build. Steady-on could reflect some higher-level activity, such as once a manifest has been fetched. Either after some time-out or if there is some other kind of disconnection event, it could go back to the slowly blinking state. No other firmware load should turn this LED on.
To simplify implementation, the MSP430 should perform the slow-blink operation. Due to the I2C latency, we should likely avoid any quick updates based on individual packets.
Summary
All of this might result in a lot of blinking lights. I think there is a lot of information to consider and dynamic status will help users tell what is going on, given that we have no display for status. Do you think this is overwhelming, or can this be a workable plan?
Currently, all the BCF bin files have the same LED pattern on the node. To make it easier to understand what bin file is programmed on each node, please change the LED pattern for each bin file.
Given that there are 6 LEDs on a node, you could binary encode which bin file it is using the LEDs. For example:
gateway: 000001 sensortest: 000010 greybus: 000011
or you could do a one-hot pattern or something else. When you have updated the bin files, please document what each LED pattern means.