Great question @emc2—It sounds like you want to do something with the Tinker mobile app that it was not intended to do. However, what you’re trying to accomplish is possible, and I can imagine that others might have a similar confusion about read and write, embedded and mobile, and how Spark ties these things together. So, I’m going to walk through the solution here to help make the whole system’s interactions clear.
It sounds like you want to:
- Use 3 analog sliders in the Tinker mobile app
- One pin should represent red, another green, another blue
- These sliders should not control the pins they’re actually hooked to in the Tinker firmware app—instead they should control the color of the RGB LED
If I’m right about all that, then you don’t need to call
analogWrite() anywhere in firmware because you do not actually care about reading or writing electrical values on the pins sticking out of the Core.
When you finish dragging an analogWrite slider in the Tinker mobile app, it sends a web request to our API. The request endpoint looks like this:
The request body contains two parameters.
- Your access token (since only you can control your Core)
- The string argument that will be passed to the firmware function, for example:
Because the end of the URL is
analogwrite, the Core will run whatever
Spark.function is registered with that key in
setup(). For example, if the function is registered like this:
then any web request to to
analogwrite will call the firmware function
updateRGBLEDColor. This also means you actually have to define that function so that it does whatever you want it to do with the incoming string.
In your code above, you register but don’t define any of
tinkerAnalogWrite. If you’re successfully flashing and running that code, it must be linking with the versions defined in the standard Spark firmware, so this is the code that runs when you move your sliders:
Also, side note—If you were trying to write an analog PWM value to pin A2, it wouldn’t work. If the mobile app gives you analogWrite as an option for A2, then that’s a bug. The android app definitely doesn’t allow this, but the iOS app might. As the Analog Outputs section of the Spark Core Hardware Reference says,
is only available on the following pins: A0, A1, A4, A5, A6, A7, D0 and D1.
So let’s plan to do this with A4 as red, A5 as green, and A6 as blue.
Here’s a gist that you can copy-paste into the Spark web IDE that will do exactly what I describe above. It defaults to a pinkish color when the app first starts. After that you can change the color using analogWrite on A4, A5, or A6 in the Tinker mobile app. After each change, the color will remain for a few seconds (until
loop() has been called a thousand times), then it will relinquish control of the RGB LED so it goes back to breathing cyan.
If you just want to see the color without changing it, do analogWrite on some other pin. This will still call
updateRGBLEDColor, but none of the if statements will match.
Hope that clarifies how the Tinker mobile app and your firmware work together!