An archive of community.esquilo.io as of Saturday January 26, 2019.

Capture PWM inconsistent documentation

rb1

In the online docs for the Esquilo library, in the links on the left we see "Capture". The heading in the title is "CAPTURE". The example on the right instantiates a class instance using all lower case "capture". This causes all ends of grief.

Given case sensitivity, I think that these should all be consistent.

Using the example on the right:

require("capture");

local capture_dist = capture(0);
capture_dist.edge(4, CAPTURE_EDGE_BOTH);

I get:

%%Runtime error [the index 'capture' does not exist]

Followup - I figured it out. It must be

require("Capture");

Although I don't understand why if the "require" can't be met it doesn't throw an error there instead of when attempting to access a library member.

patrick

Thanks for pointing out the case issue. I have fixed it in the online docs.

You need to first include the Capture library with:

require("Capture");

then instantiate one with a proper PWM (0-3):

local capture_dist = capture(1);

Same goes for DAC and HTTP. You can bring multiple libs by passing an array:

 require(["Capture", "DAC", "HTTPC"]);

We need to update the docs with a clear list of the lib names with case, but you can see them all in the System menu under "Squirrel Libraries".

I agree, we need to add an exception to indicated when require fails. Thanks for the feedback.

rb1

I appreciate it. But this still throws an error:

require("Capture");

local capture_dist = capture(0);
capture_dist.edge(4, CAPTURE_EDGE_BOTH);

%%Runtime error [the index 'CAPTURE_EDGE_BOTH' does not exist]

rb1

I've been trying to find the library source code so I can figure this stuff out myself, but without any luck.

rb1

Pretty sure I'm going to give up on capture and go to another method. I have a device that I used to have hooked to an Arduino, where I used pulseIn. This measured from the rising edge to the falling edge. It doesn't seem that Capture will actually do this, as CAPTURE_EDGE_BOTH doesn't seem to give consistent results. Guessing because it doesn't actually wait for the rising edge before timing. In fact, I'm not exactly sure what this is supposed to do.

"CAPTURE_EDGE_BOTH - capture either a rising or falling edge"

Shouldn't it be capture both a rising and a falling edge? And if so, does the timing start on the actual pulse, the rising edge? I simply can't get consistent results.

patrick

I've reproduced the problem you have with the undefined constants, but don't have a root cause yet. Here are the values to use directly as a work-around:

require("Capture")
print(CAPTURE_EDGE_BOTH + "\n")
0
print(CAPTURE_EDGE_RISING + "\n")
1
print(CAPTURE_EDGE_FALLING + "\n")
2

On your use case: BOTH does behave as an or. It measures the time from the 'read' method call to either a rise or fall. In all cases, the timing starts on the call to the 'read' method.

To measure a high pulse, you could:

cap.edge(3, CAPTURE_EDGE_RISING);
// Wait for a rise
cap.read(3);
cap.edge(3, CAPTURE_EDGE_FALLING);
// Measure microseconds to fall
local pulseWidthUs = cap.read(3);

This may not meet your real-time requirements. Scott may have a better suggestion.

Scott_Shumate

require() not throwing an exception is a bug in the return value of the internal function which we'll fix in the next release.

CAPTURE_* not resolving is a consequence of us moving to dynamic library loading. These constants are defined in the Squirrel const table which is only evaluated at compile time. The libraries are now loaded at run time so they don't resolve the constant symbols. We'll provide a fix. As a workaround, you can either use the numeric numbers or enable the Capture library in the IDE menu so that they are available at compile time.

The read() method of the capture class starts timing from its invocation. With CAPTURE_EDGE_BOTH, the read will return the time from its call to the next rising or falling edge. We have plans to add a method that will time a sequence of pulses in real time so you can measure an arbitrary waveform.

rb1

That last sentence makes the most sense. At this time, an Esquilo emitting a pulse width could not be read by another Esquilo, as a simple example.

Is the library open source? I would rather contribute by debugging and fixing.

Thx

Scott_Shumate

We would certainly like to enable you to contribute by debugging and fixing. All of EOS is open source but there are two components used by EOS whose licensing doesn't allow us to redistribute their open source code. These are Freescale's MQX real-time operating system and Broadcom's WICED WiFi drivers. Everything else including our own code uses BSD or MIT licensing.

Our current plan is to remove MQX and WICED from our source and build EOS with them as static binary libraries. We will then check in all of the nonrestrictive open source into a github repo along with the binary libraries. This would allow one to modify most of our source code and produce builds without having to worry about the licensing restrictions.

The only rub is that EOS is using the MQX build system so we have to strip everything out and produce our own build system. It should be straightforward but we just haven't had enough time to do as of yet.

-Scott