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

Simulator needs some way of discovering what sensors are connected #94

Closed
samelhusseini opened this issue Dec 15, 2017 · 15 comments
Closed

Comments

@samelhusseini
Copy link
Contributor

The simulator will act as a virtual VM of the EV3 and responds to the same messages sent between our code and the VM code.

The issue is there is a circular dependency here, we need to know what devices are connected in order to communicate on that channel, but there's no way for the simulator to know what devices are connected without something like a designer or some form of reachability.

https://github.com/Microsoft/pxt-ev3/blob/master/libs/core/input.ts#L86
is the point in the code that we poll every 500ms to detect devices, in the simulator we get a message asking us what is connected on each port, but there's no way for us to tell? so it assumes no devices are connected, and thus no subsequent code will run.

@mmoskal @pelikhan thoughts?

@pelikhan
Copy link
Member

pelikhan commented Dec 15, 2017 via email

@pelikhan
Copy link
Member

Looks like we should mock this line

let conns = analogMM.slice(AnalogOff.InConn, DAL.NUM_INPUTS)

When an device api gets called, it should register itself in the InConn array so that it becomes visible to the simulator. This might need to be an Async operation where you have to wait that the device gets detected on first use.

@samelhusseini
Copy link
Contributor Author

samelhusseini commented Dec 15, 2017

I'll keep digging, but Peli like I said, in order for that method (analogMM.slice) to return the list of connected devices it needs to know the list in advance, and there's a dependency on any functional API, like a colorSensor.color to know that there is a color sensor connected on port X, otherwise it won't call the VM. and in turn won't call the sim methods (that could potentially indicate to us that theres a color sensor on port X)

@samelhusseini
Copy link
Contributor Author

I guess we can always return a CONN_INPUT_UART. Except touch is not uart, so donno how we'll detect that.

@pelikhan
Copy link
Member

When the code calls “colorSensor.color”, it registers the device state and returns the default value. Later on the device gets polled and UartSensor picks up the value.
So it might be that the first read returns the default value.

@samelhusseini
Copy link
Contributor Author

Figured it out. Added a method in the cpp (motorUsed and sensorUsed) and in the constructor of every Sensor and Motor I call markUsed.
markUsed is in turn implemented in the simulator and is a NOP in the cpp. Seems to work :)

@pelikhan
Copy link
Member

How do you handle collisions?

@samelhusseini
Copy link
Contributor Author

Not sure yet. but we'll need to figure out some clever way to do so. At least we now have all the information.

@pelikhan
Copy link
Member

pelikhan commented Dec 15, 2017 via email

@samelhusseini
Copy link
Contributor Author

Yeah, although unlikely, the common scenario is to use event handlers and different ports. All the logic is in the sim, so we can certainly have a timestamp associated with registration and perhaps have a "smarter" way to tell which of two colliding inputs / outputs to discard.

@pelikhan
Copy link
Member

pelikhan commented Dec 15, 2017 via email

@samelhusseini
Copy link
Contributor Author

Okay. Can do.

@samelhusseini
Copy link
Contributor Author

This is all in sim, so perhaps we can even handle it in some nice way. Pop up a message or something.

@pelikhan
Copy link
Member

pelikhan commented Dec 15, 2017 via email

@samelhusseini
Copy link
Contributor Author

Yup! thanks!

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