I am new to SSEs, and not clear on the API doc about how to implement a API call to read a value from GPIO pins. Can anyone provide a quick example?
This should be a simple GET, except that the connection is kept open, so the server can send data through the output stream over a long period. See the linked documention in the API docs.
I am able to send and receive events using the example on mozilla, however I am not sure about the GET request in conjunction with the SSE. Can someone post a working example? Maybe how to read whether an LED is on/off.
If the Spark API was currently dishing up data I would work on it… but right now it’s not for SSE’s, so it’s kind of hard to do a “working” example.
Keep an eye on my Node.js wrapper and I’ll be sure to add it as soon as I can:
I don’t want my Arduino to stop processing environmental inputs such as sensors and buttons to receive server messages, but I would like to check at least from 5 to 5 seconds. How would I set that up?
Short answer: it just works, no need to set it up at all. 
At Spark, we’re designing opinionated software in order to make things super easy for you. That means that your sensor/button code will be interrupted occasionally to handle important background tasks and you never have to tune the timing intervals. This is perfectly normal in embedded applications, and if you’re using an Arduino, this is already happening. Arduino does a good job of explaining here: http://arduino.cc/en/Reference/Interrupts
Interrupts allow certain important tasks to happen in the background and are enabled by default. Some functions will not work while interrupts are disabled, and incoming communication may be ignored. Interrupts can slightly disrupt the timing of code, however, and may be disabled for particularly critical sections of code.
Rest assured, you’ll probably never notice. We’re working to determine the best balance between keeping your code running all the time and keeping all systems up-to-date, e.g., checking whether new commands have come down the wire from the server.
And finally, in the unlikely case that you’re really pushing the bounds of the STM32’s computing capabilities, the firmware will be open source, so you can modify the interrupt schedule until your heart’s content. 
This might be getting off-topic, but will there be anything really powerful that the STM32 will do that a ATMEGA would chug along at?
For example, a single cycle hardware multiply / 2-12 cycle divide.
Or is it just emulating a ATmega328P or ATmega32u4 ?
We’re using the STM32F103CBT6 as is, not emulating an ATmega. That means you get:
- 32-bit processing
- 72 MHz => 1.25 DMIPS/MHz (Dhrystone 2.1)
- single cycle multiplication and hardware division
Check the datasheet for more info, but you get all the power; it’s not ramped down in any way.
Thanks for the thorough answer. I’m really looking forward to getting the chance of start writing code and deploying cool projects with the Core, and for getting to know the other revisions of the API you guys said were coming. It’s also quite nice to know that we’ll have the raw power of a 32-bit ARM chip to work with instead of an emulated 8-bit ATmega328, and that you managed to keep syntax the same as the regular Arduino code.
@tsteltzer still in progress! In the meantime, lots of folks are using TCP sockets to send data out to wherever they want it to go. Unfortunately Spark events got deprioritized a bit while we have been working on some lower level firmware bugs. But it’s starting to bubble up towards the top of the backlog again.
1 Like