-
Notifications
You must be signed in to change notification settings - Fork 33
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
[WIP] Adds delay command to firmware #217
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -600,6 +600,15 @@ Tessel.Port.prototype._txrx = function(buf, cb) { | |
this.uncork(); | ||
}; | ||
|
||
Tessel.Port.prototype.delay = function(delayUs) { | ||
// Create a four byte buffer for the delay time | ||
var microseconds = new Buffer(4); | ||
// Pack the buffer with delay bytes | ||
microseconds.writeUInt32BE(delayUs); | ||
// Send off the delay command | ||
this.sock.write(Buffer.concat([new Buffer([CMD.WAIT]), microseconds])); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Instead of making two buffers, create a single 5 byte buffer and write the bytes into it: var frame = new Buffer(5);
frame.writeUInt8(0xFF);
frame.writeUInt32BE(delayUs, 1);
this.sock.write(frame); Here's the difference when running on a Tessel 2 (1 execution each time):
(https://gist.github.com/rwaldron/23a0ea37641138f7bf0d04cc9bda6d34) More importantly, this code must not be reachable if the delay is zero. |
||
} | ||
|
||
Tessel.Port.PATH = { | ||
'A': '/var/run/tessel/port_a', | ||
'B': '/var/run/tessel/port_b' | ||
|
@@ -954,6 +963,8 @@ Tessel.SPI = function(params, port) { | |
|
||
this.chipSelectActive = params.chipSelectActive === 'high' || params.chipSelectActive === 1 ? 1 : 0; | ||
|
||
this.chipSelectDelayUs = params.chipSelectDelayUs || 0; | ||
|
||
if (this.chipSelectActive) { | ||
// active high, pull low for now | ||
this.chipSelect.low(); | ||
|
@@ -1006,11 +1017,15 @@ Tessel.SPI = function(params, port) { | |
}; | ||
|
||
Tessel.SPI.prototype.send = function(data, callback) { | ||
this._port.cork(); | ||
|
||
this.chipSelect.low(); | ||
this._port.delay(this.chipSelectDelayUs); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wrap both of these in a condition, because if the delay is zero, we definitely do not want to waste the 3ms sending a message that effectively means "don't do anything" |
||
this._port.cork(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. no need to cork and uncork around the delay -- submit it all as one batch There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Take a look at this gist: https://gist.github.com/rwaldron/4609336bb152388260c753d8e176fa8a The average execution of _port.cork(), over 10 measurements is about 2.74ms, which means that an SPI object created with a chipSelectDelayUs that has any value less than 2740μs is always unnecessary (and indeed detrimental), because the call to cork has already taken that amount of time. I add that it's detrimental, because it's adding 2.5-3ms to the execution—even when the delay is zero. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This might also be why your logic analyzer results are coming up inconsistent |
||
this._port._tx(data, callback); | ||
this._port.delay(this.chipSelectDelayUs); | ||
this.chipSelect.high(); | ||
this._port.uncork(); | ||
|
||
}; | ||
|
||
Tessel.SPI.prototype.disable = function() { | ||
|
@@ -1021,17 +1036,24 @@ Tessel.SPI.prototype.disable = function() { | |
}; | ||
|
||
Tessel.SPI.prototype.receive = function(data_len, callback) { | ||
this._port.cork(); | ||
|
||
this.chipSelect.low(); | ||
this._port.delay(this.chipSelectDelayUs); | ||
this._port.cork(); | ||
this._port._rx(data_len, callback); | ||
this._port.delay(this.chipSelectDelayUs); | ||
this.chipSelect.high(); | ||
|
||
this._port.uncork(); | ||
}; | ||
|
||
Tessel.SPI.prototype.transfer = function(data, callback) { | ||
this._port.cork(); | ||
|
||
this.chipSelect.low(); | ||
this._port.delay(this.chipSelectDelayUs); | ||
this._port.cork(); | ||
this._port._txrx(data, callback); | ||
this._port.delay(this.chipSelectDelayUs); | ||
this.chipSelect.high(); | ||
this._port.uncork(); | ||
}; | ||
|
@@ -1095,12 +1117,12 @@ var CMD = { | |
NOP: 0, | ||
FLUSH: 1, | ||
ECHO: 2, | ||
WAIT: 7, | ||
GPIO_IN: 3, | ||
GPIO_HIGH: 4, | ||
GPIO_LOW: 5, | ||
GPIO_TOGGLE: 21, | ||
GPIO_CFG: 6, | ||
GPIO_WAIT: 7, | ||
GPIO_INT: 8, | ||
GPIO_INPUT: 22, | ||
GPIO_RAW_READ: 23, | ||
|
@@ -1546,7 +1568,7 @@ function getWifiInfo() { | |
if (bcastMatches === null) { | ||
recursiveWifi(network); | ||
} else { | ||
// Successful matches will have a result that looks like: | ||
// Successful matches will have a result that looks like: | ||
// ["Bcast:0.0.0.0", "Bcast", "0.0.0.0"] | ||
if (bcastMatches.length === 3) { | ||
network.ip = bcastMatches[2]; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are the TC and TCC compatible enough to use the same function and register struct for both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good question. I'm not sure why I made that assumption. I'll look into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kevinmehall is there any reason we can't re-use the TC_BOOT TC for port B? Then they could both use
TC
s instead of having to implement switching logic for TCs and TCCs.