You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far, we have had some discussions on platform uniformity and such in various issues (e.g. #115 and ev3dev/ev3dev#412). I think we should get the rest of the platform functionality figured out now to make sure that all platforms are supported.
I would like the same program to run on any platform without having to make any changes.
So, keeping that as a goal, how can we get our API updated?
LEDs
For LEDs, we still need to allow specific control of just single LEDs and colors. However, I imagine that if we could get some default common actions/states implemented cross-platform we could allow programs to run cross-platform without modification (at least until they need more fine-grained control). I am imagining utility methods like this:
Possible name
Meaning
EV3 action
BrickPi action
PiStorms action
success
Success
green
both on solid
green
warning
Warning/danger
amber or red
both flashing (rapidly)
amber or red
progress
Indicate specified %
Fade from red to green
special (see below)
Fade from red to green
I'm imagining the "special" case above to be:
From 0% to 50%, increasing blink rate of 1st LED while 2nd off
From 50% to 95%, Increasing blink rate of 2nd LED while 1st is ON
95% both on
...But that depends on how triggers react to being repeatedly set (we may need to group it in 25% increments).
With a scheme such as this, programs could use these interfaces for simple tasks and wouldn't need to break platform compatibility in the process.
Buttons
I think that it is important to accept up-front that the buttons can't be very universal. Only the EV3 has 6 buttons; the others have 0 and 1. So, I think this just needs to stay separate, unfortunately.
PowerSupply
I think that it's best if we just have the PowerSupply default to using whichever platform device it finds first. That would be legoev3-battery, brickpi-battery, or pistorms-battery.
Ports
Although EV3 and BrickPi are uniform, PiStorms has 4 ports with different labeling. Optimally, we would use OUTPUT_A, INPUT_1, etc. for all platforms, so I think we should use some sort of mapping: Declare that BAS1 is port 1, for example, and handle the internal naming differences with extra code (which would depend on the platform).
PowerSupply: See #131. There is no need to use platform-specific names or even have platform-specific names in the spec. Then it is totally future-proof and one less thing to worry about.
So far, we have had some discussions on platform uniformity and such in various issues (e.g. #115 and ev3dev/ev3dev#412). I think we should get the rest of the platform functionality figured out now to make sure that all platforms are supported.
@dlech said in #115
So, keeping that as a goal, how can we get our API updated?
LEDs
For LEDs, we still need to allow specific control of just single LEDs and colors. However, I imagine that if we could get some default common actions/states implemented cross-platform we could allow programs to run cross-platform without modification (at least until they need more fine-grained control). I am imagining utility methods like this:
I'm imagining the "special" case above to be:
...But that depends on how triggers react to being repeatedly set (we may need to group it in 25% increments).
With a scheme such as this, programs could use these interfaces for simple tasks and wouldn't need to break platform compatibility in the process.
Buttons
I think that it is important to accept up-front that the buttons can't be very universal. Only the EV3 has 6 buttons; the others have 0 and 1. So, I think this just needs to stay separate, unfortunately.
PowerSupply
I think that it's best if we just have the PowerSupply default to using whichever platform device it finds first. That would be
legoev3-battery
,brickpi-battery
, orpistorms-battery
.Ports
Although EV3 and BrickPi are uniform, PiStorms has 4 ports with different labeling. Optimally, we would use
OUTPUT_A
,INPUT_1
, etc. for all platforms, so I think we should use some sort of mapping: Declare that BAS1 is port 1, for example, and handle the internal naming differences with extra code (which would depend on the platform).Display/sound
Platform-agnostic by default, so doesn't matter.
So, what are your thoughts? @ddemidov @rhempel
CC @dlech
And is this something that we want to add before our (hopefully upcoming) release or wait for a subsequent one?
The text was updated successfully, but these errors were encountered: