ec-test-app: Add serial source #38
Conversation
kurtjd
requested review from
dymk,
felipebalbi,
philgweber,
tullom and
williampMSFT
philgweber
left a comment
philgweber
left a comment
There was a problem hiding this comment.
Will have to think about the transport and integrating with FFA and secure world so we have the ability to redirect messages through either path.
So I was thinking this can be used as an alternative to going through FFA when someone jsut wants to quickly connect to a board and do some testing of the services. In my mind I imagined this app will just select the |
kurtjd
force-pushed
the
add-serial-source
branch
from
72c2645 to
75bdfa4
Compare
kurtjd
force-pushed
the
add-serial-source
branch
from
75bdfa4 to
00a491e
Compare
kurtjd
force-pushed
the
add-serial-source
branch
from
00a491e to
291ab9f
Compare
| fn charge_state_as_str(state: BatteryState) -> &'static str { | ||
| if state.contains(BatteryState::DISCHARGING) { | ||
| "Discharging" | ||
| } else { | ||
| "Charging" |
There was a problem hiding this comment.
impl Display for BatteryState?
There was a problem hiding this comment.
BatteryState is a foreign type and Display is a foreign trait so orphan rule wouldn't allow that, right? But can give it a try.
There was a problem hiding this comment.
Where is battery state defined? Could impl Display on that crate and just rely on it here.
There was a problem hiding this comment.
It's defined by the embedded-batteries crate which is reexported by the battery-service-messages crate. Was also missing a couple TryFrom<u32>s in there which I opened a PR for so I can do that for these as well. However, initial attempts to update embedded-batteries throughout caused a lot of issues so ideally would like this to get in first then can take the time to fix everything that an embedded-batteries update will cause.
|
Will wait for #41 to merge, then update this PR to implement |
4 participants
This PR does a few things:
Source, which allows the app to talk directly to a dev platform in user-space (over a COM port for example). Can be useful for testing services without needing to worry about FFA and whatnot.Tested this on the
dev-imxrtplatform and works pretty well. I was running into some issues where I occasionally receive bytes that shouldn't be coming in for reasons I haven't been able to figure out yet, but if we drain the incoming bytes and just return an error it leaves things in a good state for the next attempt and we quickly recover.