Feature/runtime sensor selection #26
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Had to add default constructor for Sensor. Also had to make Sensor.name() not purely virtual to allow for static class variables.
…ged in. Can't free the static dummy sensor memory, so fixed that. Had to increase the ES2 on/off interval to get serial from it. Works most of the time, but it is possible to start sending gibberish messages that cause the phone to crash. This seems to occur when you leave a sensor plugged in after it was working and then tell the firmware it is dummy/none. The sensor (or another sensor) may then start sending gibberish very very quickly to the phone, causing it to crash. For example, this occurred when S1 started as DO and S3 started as ES2, and then S1 is set to dummy. This caused S3 to send ridiculous messages much faster than it should. The JSON parsing in the phone is protected by try/catch that works when gibberish is sent that normal rates, but reading.type.toString() will cause an uncaught null pointer exception if it is sent at extreme rates.
The previous commit caused gibberish to appear on other sensor channels when a real sensor was set to dummy, e.g. DO, dummy, ES2 --> dummy, dummy, ES2 could cause the ES2 channel to produce gibberish extremely quickly, overwhelming the phone and crashing it. The serial handlers were stored in a separate global array. Setting the sensor to a dummy did not change what was already set up as a callback reference, and this probably caused the undefined behavior. Now, when a sensor is set back to a dummy, its corresponding serial handler is as well.
|
Do I also need to reset the pin settings for the channel when I set it back to a dummy? That is not included in this pull request. |
|
There is an issue. sensors[0] needs to be left as a ServoSensor. Otherwise the airboat will not turn the fan. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request to be completed simultaneously with platypusllc/server/feature/runtime_sensor_selection, commit 69b0f756, pull request
The firmware now establishes the objects in the platypus::sensors[ ] array at runtime. The array starts with dummy objects and serial handlers. The phone server application sends a JSON that specifies which sensor objects should populate the array. The firmware parses this JSON command and instantiates the appropriate sensor objects, clearing any memory that might have been used by old sensor objects.