Skip to content

Instantly share code, notes, and snippets.

Zach Supalla zsup

Block or report user

Report or block zsup

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View gist:f325c09b3ecc205376cf
npm install serialport
-
> serialport@1.5.0 install /Users/zsupalla/Dropbox (Spark)/Software/Code/spark-cli/node_modules/serialport
> node-pre-gyp install --fallback-to-build
child_process: customFds option is deprecated, use stdio instead.
CXX(target) Release/obj.target/serialport/src/serialport.o
CXX(target) Release/obj.target/serialport/src/serialport_unix.o
../src/serialport_unix.cpp:663:20: warning: comparison of array 'device.locationId' not equal to a null pointer is always true [-Wtautological-pointer-compare]
if (device.locationId != NULL) {
@zsup
zsup / warsting.ino
Last active Mar 17, 2019
A snippet of firmware for WarSting, a wardriving sword for Hobbits
View warsting.ino
/**
* Slay and pillage an unprotected network! ...oh, we can't do that?
* Ok, let's publish an event instead, to a backdrop of flashing lights and
* clashing of metal on metal.
*/
void vanquishOpenNetwork() {
if (!openNetworkCount || !strongest.rssi)
return;
RGB.control(false); // allow the system to control the LED so we can see cloud connection progress
makeSound();
View gist:12859c28b4ed88b268fa
### Keybase proof
I hereby claim:
* I am zsup on github.
* I am zs (https://keybase.io/zs) on keybase.
* I have a public key whose fingerprint is 392A 4266 55AC 9C51 4A1A 8ABA ADD8 05EB 53FC DDC1
To claim this, I am signing this object:
@zsup
zsup / connectivity.md
Last active Aug 29, 2015
Documentation for controlling connectivity on the Spark Core
View connectivity.md

By default, the Spark Core connects to the Cloud and processes messages automatically. However there are many cases where a user will want to take control over that connection. The following methods are available to control the connectivity of the Spark Core.

System modes

There are three available system modes: AUTOMATIC, MANUAL_CONNECT, and MANUAL. These modes describe how connectivity is handled.

System modes must be called before the setup() function.

System.mode(AUTOMATIC)

@zsup
zsup / motion.cpp
Last active Sep 27, 2017
Spark.publish() + PIR motion sensor
View motion.cpp
/*
* Connected sensor
* Spark.publish() + PIR motion sensor = awesome
* Thanks to Adafruit for the reference and inspiration
*/
int inputPin = D0; // choose the input pin (for PIR sensor)
int pirState = LOW; // we start, assuming no motion detected
int val = 0; // variable for reading the pin status
int calibrateTime = 10000; // wait for the thingy to calibrate
@zsup
zsup / publish.cpp
Created Mar 11, 2014
Basic Spark.publish() usage
View publish.cpp
// The most basic event, without data.
Spark.publish("motion-detected");
// Some events require additional data.
Spark.publish("temperature", "19 F");
// You can set a TTL to persist data in the cloud...
Spark.publish("lake-depth/1", "28", 21600);
// ...and make events private for secure applications.
@zsup
zsup / ddd.md
Last active Aug 18, 2019
Documentation-Driven Development (DDD)
View ddd.md

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

  • Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
  • Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
  • Once documentation has been written, development should commence, and test-driven development is preferred.
  • Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
  • When a feature is being modified, it should be modified documentation-first.
  • When documentation is modified, so should be the tests.
View gist:8034992
TCPClient client;
void setup() {
Serial.begin(9600);
Spark.function("connect", connect_to_my_server);
for (int pin = D0; pin <= D7; ++pin) {
pinMode(pin, OUTPUT);
}
View gist:8034902
TCPClient client;
void setup() {
Serial.begin(9600);
Spark.function("connect", connect_to_my_server);
for (int pin = D0; pin <= D7; ++pin) {
pinMode(pin, OUTPUT);
}
View gist:8034763
TCPClient client;
void setup() {
Serial.begin(9600);
Spark.function("connect", connect_to_my_server);
for (int pin = D0; pin <= D7; ++pin) {
pinMode(pin, OUTPUT);
}
You can’t perform that action at this time.