Show Posts
Pages: [1]
1  Community / Exhibition / Gallery / Re: NanoCloudLogger - Simple cloud based logger for devices on: August 17, 2013, 12:30:55 pm
Is this moving ahead, abandoned, or is there another newer project of similar intent?
Thanks
Bruce
2  Development / Suggestions for the Arduino Project / Re: Wire library behavior and documentation corrections on: February 06, 2013, 10:49:26 am
OK in my Wire.h from 1.0.3 here are lines 60..63 -There is nothing in the header about mods or versions newer than "Modified 2012 by Todd Krein...".

    uint8_t requestFrom(uint8_t, uint8_t);
    uint8_t requestFrom(uint8_t, uint8_t, uint8_t); << line 61, this is what I am trying to use
    uint8_t requestFrom(int, int);
    uint8_t requestFrom(int, int, int);

So I am confused (which doesn't take much!)... how does Arduino and the compiler know which declaration to use? The 2nd would be the closest...  so I first wonder how my line numbers can differ?

If I open the Wire.h from within the Arduino 1.0.3 zip, and compare: whoa! They are not the same. It would appear Teensyduino has quietly modified the libraries without leaving any comments that it did so.
Here is my Teensyduino-modified version:
#include <inttypes.h>
#include "Arduino.h" <-- line 26
...
extern "C" void i2c0_isr(void); <-- line 30, not present in original version

Original version:
#include <inttypes.h>
#include "Stream.h" <-- line 26

This begs the obvious question: when another utility (in this case Teensy) has a need to modify standard libraries like Wire.h, what is the accepted protocol? I would imagine a comment at every change, or at least in the header? Or?? As more Arduino variations are introduced how is this to be dealt with as sanely as possible?

Continuing on, there is no declaration with the "stop" parameter of type boolean as stated in the reference doc at arduino-1.0.3/reference/WireRequestFrom.html. The data type of address and quantity is not specified in the document.

Out of curiosity I try:

Wire.requestFrom(TMP102_ADDR, (uint8_t)2, (uint8_t)true);  << 3rd param cast violates the ref but not Wire.h

and this seems to make my call unambiguous enough for the compiler to match up correctly.

So I am not sure why I have learned here since I don't know if this error comes from the core Wire library or the modified version. But the Wire docs also aren't consistent with the source files. So there's plenty of ambiguity...

It would seem that the included references should describe the correct data types of each function parameter. In Java, the javadoc tool takes your appropriately written source files and creates a nice clear reference doc which describes the type, use, bounds, defaults and other aspects of each parameter and return type. Is there a similar, widely accepted tool for C docs? If so I would like to write my library to utilize it and then publish the document with it.
3  Development / Suggestions for the Arduino Project / Re: Wire library behavior and documentation corrections on: February 05, 2013, 07:20:08 pm
In Arduino 1.0.3, it seems Wire.requestFrom(address, quantity, stop) insists that address (7 bits)  must be cast to int. Wire.beginTransmission(address) has no such requirement.
In my case I declare address as:

const uint8_t TMP102_ADDR = 0x48;  // base address (four possible values)

and get this error:

TMP102_proof:344: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
D:\arduino-1.0.3\libraries\Wire/Wire.h:63: note: candidate 1: uint8_t TwoWire::requestFrom(int, int, int)
D:\arduino-1.0.3\libraries\Wire/Wire.h:61: note: candidate 2: uint8_t TwoWire::requestFrom(uint8_t, uint8_t, uint8_t)

If I declare the TMP102_ADDR as int the error goes away.

I have not looked at the Wire source code (yet).
4  Development / Suggestions for the Arduino Project / Re: Does Arduino need a real-time scheduler? on: February 05, 2013, 12:19:33 pm
Interesting thread. I have been working on commercial hard- and soft- real-time control systems for a number of years. Since those terms are commonly misused and misunderstood here is an example of a hard-time system we did a few years ago: a mud-pump controller driving two pistons with 2-meter stroke, controlled with about 500 HP of hydraulic pumps (at 10,000 psi, the manifold pipe is something like 200 mm in dia), through a servovalve for each piston. Each piston moves by a polynomial equation and their outputs are summed through a check valve so that the flow is constant, and adjustable over a wide range. LVDTs with 2-meter stroke monitor each piston. Smooth startup and shutdown and several considerations of fail-safe behavior were used. We achieved this on an 8051 with external ADCs and DACs, and interrupt handlers (two levels, pre-emptive) with re-entrant libraries. We almost ran out of code space. In our case the time interval was not tiny, but we had hard completion deadlines. The piston profile came out of a lookup table (actually 1/4 of the entire profile, mirrored and phase-shifted as needed), the actual piston position was read, and that was all fed into a firmware PID routine which then calculated the next value for the servovalves. That had to be completed before the timer tick to update the valves. That timer got faster as the flow rate was increased. Then in the background was interrupt-driven serial I/O for the machine interface to control the mud pump and to monitor critical performance values (such as the current error value vs target position). This I/O had to be safely pre-empted by the piston routines with due consideration of atomicity of variables which might be in the midst of being updated by the control interface. In the end it all worked well, we delivered complete documentation and source code, and I have not heard of any problems. I went to Japan to help install and tune the system and then our part of the project was complete.

Where execution deadlines got tight I would set and clear some spare I/O bits and watch them on an oscilloscope or logic analyzer, something like High when active in a critical routine and Low when in safe extra time margin. As the flow rate ramped up you could see the bit transitions coming closer together. If they ever collided that would be potentially catastrophic since the control loop could not correctly function. We set the scope to trigger on the smallest safe interval and left it running overnight (without driving the actual pumps - simulated input). There was also simple instrumentation in the code to log deadline violations.

The project engineer was a delight to work with: a very experienced, practical guy. One example: we had to monitor the end-of travel limit clearance of the pistons (which weighed over 1000 kg as I recall) since we didn't ever want to drive them into their stops. No one knew what would happen if that occurred. Safe clearance was something like 5-10 mm, and it could not be observed easily by eye while running. His brilliant idea was to use an empty aluminum soft drink can in the gap and measure the crushed thickness. Worked great and no risk of harm to the pistons.

In this project a simple RTOS might have been a huge timesaver. But we also had to have timer interrupts and serial I/O interrupts and I am not aware of how easily RTOSes can fit with those. If it is possible to weave RTOS features into your own needed I/O hardware support, that could be helpful but also could get a bit complex.

I am using Teensy++2 on a project now and just got the ARM Teensy 3, and there is enough code and data space on these new Arduino devices. My concern would be: is the RTOS granular so we only need to use what fits our case, and can it co-exist with I/O device interrupt handlers?

Thanks
5  Development / Suggestions for the Arduino Project / Wire library behavior and documentation corrections on: February 05, 2013, 11:25:52 am
Hi everyone... Spent a big part of yesterday working on a TMP102 precision temperature sensor library and, in the process, fixing my own bugs and tripping over the Wire library subtleties and documentation issues. I'm wondering where to post corrections and enhancements to the documentation? The Wire reference says: Corrections, suggestions, and new documentation should be posted to the Forum but I can't find a specific place appropriate for that task. I tried searching "Wire" and "Wire documentation" (with quotes) but came up with nothing relevant.

How about here, I guess? In the meantime I will write an off-line document and then link to it here, or if someone can point to a better place to post this stuff so that the documentation gets improved, that would be great.

BTW I do intend to release the TMP102 library when it's complete. I did find some OS library starts out there but the ones I found were incomplete or had major bugs so it seemed easier to just write one. It's a pretty cool, 13-bit, direct to digital temperature transducer which can convert over -55C to 150C! We need to measure up to and past 125C so it's good for that. It's a tiny SOT563 package so we can fit it next to a high power LED heatsink pad to monitor it's temperature. Resolution is 0.0625 deg C. See http://www.ti.com/product/tmp102
6  Using Arduino / Networking, Protocols, and Devices / Re: [SOLVED] Writing to specific register of I2C device on: February 05, 2013, 11:10:50 am
It's really nice to see useful comments in your code. You might want to check the return values to see if the writes actually happened, especially if you count on the results later on.'

Wire.endTransmission() returns four different NAK type failures.
Wire.write() returns the number of bytes written.

Here's a snippet:
  int8_t flag=-1;  // signed flag, init to invalid result so we know if it has changed
  byte written;  // number of bytes written
  Wire.beginTransmission(TMP102_ADDR);  // base address
  written = Wire.write(pointer);        // pointer in 2 lsb
  flag = Wire.endTransmission();    // flag is zero if no error
  Serial.print ("wrote:");
  Serial.print (written);
  Serial.print (" ");
return (flag);  // zero if no error, 1..4 are NAK errors
7  Forum 2005-2010 (read only) / Interfacing / FIO protyping or other shields on: September 25, 2010, 03:07:55 pm
Hi, just got some FIO boards (which I plan to use with XBee 2.5) and want to add some prototype circuits but can't google a prototyping shield.

If it doesn't already exist, I would make one. Anyone else interested?

Thanks

Bruce :-?
Pages: [1]