search

lancaster-university / microbit-dal

http://lancaster-university.github.io/microbit-docs
Other
259 stars 131 forks source link

More advanced events #235

Open jaustin opened 8 years ago

jaustin commented 8 years ago

I'd like some more advanced events that we could use with the accelerometer, such as

...I'm sure there are many more!

The idea here would be to build these events into the DAL and then work with the PXT team to have them exposed in the higher level languages

remay commented 8 years ago

Most of those examples can be done already by code on top of the existing DAL. For me this raises a question of how we continue to add features given the memory constraints we are under. Currently we add features to the DAL with an ever increasing complexity in configuring which ones we want to use. Should we be thinking about how we implement some of the features as separate libraries/modules (that build on the DAL) and that we can pull in at build time?

If we continue to extend the DAL, then I think we should have a good think about whether we can simplify the configuration needed.

jaustin commented 8 years ago

Sure, we can look at better configuration, perhaps that's another 'upforgrabs' task? At the moment I'm really concerned more about RAM than flash, so I think we should add the requirement to these new features/mechanisms that they only increase memory consumption of they're actively used (something the DAL already does well).

On 1 November 2016 at 08:40, Robert May notifications@github.com wrote:

Most of those examples can be done already by code on top of the existing DAL. For me this raises a question of how we continue to add features given the memory constraints we are under. Currently we add features to the DAL with an ever increasing complexity in configuring which ones we want to use. Should we be thinking about how we implement some of the features as separate libraries/modules (that build on the DAL) and that we can pull in at build time?

If we continue to extend the DAL, then I think we should have a good think about whether we can simplify the configuration needed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lancaster-university/microbit-dal/issues/235#issuecomment-257600875, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI-qZF530RQN_mwqC3gSQoks3htiuy-ks5q5118gaJpZM4KmMSV .

finneyj commented 8 years ago

@remay @jaustin Agree completely. Since 2.0, microbit-dal is effectively like an SDK, so adding code in here no longer automatically increase memory footprint (either RAM or FLASH). Unless reference is made to the relevant class, there's no impact... and keeping it that way is a big win.

If/when we add a feature that we think has a lot of scope, we could consider adding it to the MicroBit class (which is essentially a bag of the most commonly used components in a precanned configuration, designed to promote accessibility and visibility). This is something we should do sparingly though.

Since 2.0 there's no dependency between microbit-dal and the MicroBit class, so for folks who want a more tailored build, they can simply not use MicroBit.cpp, edit it to reduce/add components, or write their own using that as a template.

dpgeorge commented 8 years ago

Adding things like this makes it harder and harder for MicroPython to be compatible with the other languages, for a few reasons: 1) we need to compile everything into the firmware from the beginning so that all features are available; 2) it takes us time to come up with a nice Pythonic API to wrap these new features; 3) we don't really support on-XXX event handling because we don't have thread support.

I agree with @remay that things that can already be done by a little bit of code on the user side (eg in PXT, uPy) should remain that way. IMO the DAL should be a toolkit of fundamental components that expose unique features for things you couldn't otherwise use. Then it's up to the higher-level language to allow you to compose these components to do cool stuff.

If the DAL becomes a big flat API of components with overlapping features then it becomes harder and harder to port to other targets (eg microbit clones around the world).

rharbird commented 7 years ago

FWIW, I agree with @dpgeorge. If you want the higher level abstractions, use the javaScript and blocks interfaces. Use C++ when you want to use what's under the hood.

From a teaching perspective, it's good to be able to teach using those fundamental components when students are ready to use C / C++. Students can learn about how to program a microprocessor, how the different sensors work and what the sensor readings mean. For example: what is onShake actually doing? Sensors produce noisy data, how will you filter the readings? how will you calibrate the sensor?

We should also use caution with abstraction! Sometimes, those higher level abstractions may be too general, making them ideal for initial learning activities but excluding opportunities to do something slightly more complex. For example: most of the pin-related blocks automatically switch the pin into "touch" mode, effectively making the pin behave like a button. A positive outcome is that there are projects like the love-meter that you can use with very young students; debouncing features make the output from the pin appear nice and regular. A negative outcome is that if you want to attach sensors to the pin for digital input, the abstraction doesn't allow you to see that you need to configure the pin in a completely different way. As these use cases crop up, the JavaScript top layer may need some remodeling but the underlying C++ primitives should remain the same.