Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define servo blocks same way as Sonar #23

Open
kristiank opened this issue Jan 20, 2020 · 5 comments
Open

Define servo blocks same way as Sonar #23

kristiank opened this issue Jan 20, 2020 · 5 comments
Assignees

Comments

@kristiank
Copy link
Contributor

I think it would be good to define the servo blocks the same way as sonar blocks, e.g. to abstract the servo pins to use names instead of just the pin number.

I can see this affects some sort of pedagogical statement that we should not abstract components too much. I mean, yes it is nice that users instantly understands that servo controlling is something very simple (just a value set to one output pin). But still, that could be up to the teacher to reveal, that hey, actually you can use the 'set pin variable' block to do the same. In that case it would be even more clear to the user, that not even the text on the block that mentions 'servo' doesn't do any magical tricks.

What do you thitk?

@RichoM
Copy link
Member

RichoM commented Jan 21, 2020

Maybe you're right. We had a similar discussion in our lab a few weeks ago when I added the Buttons pane. If you look at the generated code you'll see that the button blocks are implemented in a library. So it kind of made sense to treat buttons the same way as we did with the sonar library. I thought it was overkill to have to declare each button separately but maybe for servos it makes more sense.

@RichoM RichoM self-assigned this Jan 21, 2020
@kristiank
Copy link
Contributor Author

Yeah, I see this as a clash of many dimensions. One dimension is that "we all know" what's behind those abstractions, but those who are new to the game don't know. Another dimension is the user interface and how coherent it is, from this point of view I really would like to have the 'configure ...' button for all sensors and actuators just out of aesthetical reasons. And a third dimension would be how coherent blocks are with respect to each other, e.g. joystick blocks could also be pin-based, e.g. "Read joystick magnitude on [pin X]" just to make them more similar to other blocks..

I think my motivations for abstracting the Servo block was all the above but also a pragmatic one, that I don't need to change the pin number every time a drag a servo block out on the board. It just felt that I want a name for that servo.

@kristiank
Copy link
Contributor Author

Now thinking about, actually I would like to have a name for the buttons also, instead of needing to name a variable for holding the pin. But I guess there's more work to be done elsewhere first, so this is not a priority. (And while on it, why not have the debounce time overwritable for each button as well, if it doesn't create a too much of an overhead in terms of device memory.)

@kristiank
Copy link
Contributor Author

Have you had any thoughts about this lately? Should I close it as a feature request that never reached through, or is it worth having it open still? I still think the arguments are valid, that a servo deserves a name the same way as a DC motor does.

@RichoM
Copy link
Member

RichoM commented Nov 5, 2020

I think your arguments are convincing but I fear it would generate too much memory overhead. The problem is my awfully inefficient compiler.
You can see how bad it is by adding two sonars and looking at the generated program. You'll notice it includes every sonar function twice, one for each sonar. As you can imagine, that's a terrible thing from a memory usage point of view.

My excuse is that it was the easiest way of implementing it and I was planning on eventually optimize the compiler so that it would be able to detect duplicated functions and remove them from the compiled program. However, I didn't get to do that yet.
So I think I would prefer to leave things as is until that optimization is done. It's high on my TO DO list, though, so don't close the issue yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants