Re: [Firmata-devel] ShiftIn and ShfitOut

[Jeff H. <sou...@gm...>]

I wasn't aware that the compiler/linker would not include unused functions.
If that's the case then there would be not need for a separate 'lite'
library. At some point I'll post some examples to firmata.org demonstrating
the structured 'object' or 'event' scheme I've been dreaming up for passing
data between an arduino and a client application. If only Arduino libraries
were built on abstract base classes (that would be part of the Arduino
core... like AbstractButton, AbstractAccelerometer, AbstractServo, etc),
there would be so many more possibilities. Take the Android platform for
example... there's no requirement that all hardware developers have to use
the exact same accelerometer, but there is an accelerometer base of some
sort that they must implement. That way anyone writing code using an
accelerometer on an Android device does not have to account for a specific
accelerometer, but simply the general idea of an accelerometer. Anyway...
going off on a tangent.

-jeff

On Tue, Oct 25, 2011 at 3:21 PM, Hans-Christoph Steiner <ha...@at...>wrote:

>
> The central idea of the Firmata library is so that people can write any
> kind of firmware and just use the Firmata library for the communications, so
> Chris, sounds like exactly what your advanced users want to do with it. That
> is why there are the included example firmwares, to demonstrate that idea.
>  I've written a few custom Firmata firmwares and its worked well for me, and
> I've seen others write their own as well.  I've done a bunch that started as
> prototypes with StandardFirmata, then were stripped down to only what was
> needed (never touching Firmata.h or Firmata.cpp).  I've also written some
> for specific hardware, like the DMX shield, etc.
>
> As for Jeff's FirmataLite, why not just use the same Firmata library, but
> then in your sketch, don't use any of the functions besides sysex and
> string?  The compiler/linker should be smart enough to not include the code
> that is not used.
>
> Having a separate library like FirmataLite seems like a recipe for lots of
> incompatibilities and a multitude of different versions of the protocol,
> making the Firmata space much more confusing.  For example, if FirmataLike
> doesn't include the standard message definitions like I2C_CONFIG and
> SHIFT_DATA, and someone uses the same numeric code, that creates an
> incompatibility.  The user then needs to be aware of both the arduino and
> host software in order to make it work.
>
> I could see having a FirmataLite spec documented on a wiki page that is
> just a subset of the full Firmata, but then it still uses the same Firmata.h
> and Firmata.cpp.  Something like "you can use these functions and these
> message IDs and ignore everything else".
>
> .hc
>
> On Oct 20, 2011, at 1:12 PM, Christopher Coleman wrote:
>
> Jeff, love the idea of having the lite version, we might just need to write
> a good instructional page for it.  I just returned from presenting Maxuino
> (firmata -> Max/MSP) and the more advanced users were looking for something
> to fill such a niche....didnt want to write a protocol from scratch, but
> needed more flexability than the standardFirmata, and wanted to be able to
> add their specific device libraries into the mix, like a motor shield, or
> bluetooth....
> Chris
>
> []  [  ]  [  ]  [  ]  [  ]  [  ]  [  ]  [  ]  [  ]   [  ]  [  ]  [  ]  []
>
> Christopher Coleman
>
> chr...@gm...
>
> Associate Professor, Digital Media Studies
>
> University of Denver
>
> www.digitalcoleman.com
>
> www.co-lab.info/
>
>
>
> On Thu, Oct 20, 2011 at 11:06 AM, Jeff Hoefs <sou...@gm...>wrote:
>
>> sorry sent last email accidentally (damn tab to get focus on send button
>> in gmail) ...
>>
>> continuing...
>>
>> this is off the top of my head so it may not be accurate for this sensor,
>> but you should get the general idea here:
>>
>> #define SHT15 0x03
>> sensorData[0] = sensorID // may not be necessary for this particular
>> sensor
>> sensorData[1] = tempDataLSB
>> sensorData[2] = tempDataMSB
>> sensorData[3] = humidityLSB
>> sensorData[4] = humidityMSB
>>
>> Firmata.sendSysex(SHT15, 5, sensorData);
>>
>> #define BUTTON 0x02   // this is the SYSEX command (the first few numbers
>> should be reserved for this purpose)
>> buttonData[0] = buttonID; // so you can sort out which button the data
>> belongs to
>> buttonData[1] = state; // PRESSED, RELEASED, LONG_PRESS, etc.
>> Firmata.sendSysex(BUTTON, 2, buttonData);
>>
>> That way you could handle debounce on the arduino side as well instead of
>> in a client application.
>>
>> another hypothetical example:
>>
>> #define ACCELEROMETER 0x04
>> accelData[0] = accelID
>> accelData[1] = xAxisLSB
>> accelData[2] = xAxisMSB
>> accelData[3] = yAxisLSB
>> accelData[4] = yAxisMSB
>> accelData[5] = zAxisLSB
>> accelData[6] = zAxisMSB
>>
>> Firmata.sendSysex(ACCELEROMETER, 7, accelData);
>>
>>
>> for receiving data:
>>
>> void sysexCallback(byte command, byte argc, byte *argv)
>>
>> {
>>
>>
>>
>>   shift {command}
>>      case SHT15:
>>          sht15ID = argv[0];
>>          request = argv[1]; // get data or other request you need for this device
>>
>>
>>          if (request == GET_DATA) {
>>              readSht15(id);
>>          }
>>
>>
>>
>>          // or you may only need the command and call readSht15 if there are not
>>
>>
>>
>>          // different types of requests
>>
>>          break;
>>      case SOME_OTHER_THING:
>>          // handle data
>>
>>
>>
>>          break;
>>   }
>>
>>
>>
>> }
>>
>>
>> You could send any kind of 'object' or 'event' this way and simply have a
>> matching 'object' in the client application. You don't need to care about
>> pins at all or even which type of board you are using, rather you are
>> sending only the data you need back and forth, abstracting the
>> implementation of the hardware on the Arduino side and only sending data for
>> the interface. So basically you define an interface that is shared by the
>> arduino and your client application. I think this would be a much more
>> efficient way to deal with complex interfaces rather than trying to use
>> StandardFirmata (with the major difference being that the methods I'm
>> describing require you to maintain code on both the arduino and the client
>> application). StandardFirmata is good for basic digital and analog I/O and
>> various devices that conform to standard protocols that are somewhat easy to
>> incorporate in StandardFirmata. Firmata is at its root a communication
>> protocol (based on midi) so it's pretty flexible.
>>
>> I started a project called "FirmataLite" in my github for the
>> interface-based direction I'm describing. It basically strips out everthing
>> from Firmata except the firmataSysex and firmataString functionality. I'll
>> add some concrete examples at some point.
>>
>> -jeff
>>
>>
>> On Thu, Oct 20, 2011 at 12:32 PM, Jeff Hoefs <sou...@gm...>wrote:
>>
>>> Hi Julian,
>>>
>>> I have looked more closely at your js code for the sht15 sensor. It's an
>>> interesting sensor in that the protocol it uses is very similar to I2C, yet
>>> different enough that you have to bit bang the data. This is where in my
>>> opinion, Firmata becomes very inefficient. However Firmata as a protocol can
>>> be used in many ways, you are not constrained to StandardFirmata. If your
>>> application only needs data from the sht15 sensor and no other physical
>>> inputs or outputs, it's easiest (and much more reliable) to create a simple
>>> sketch that uses the custom sysex firmata protocol. You can find an example
>>> here:
>>> https://github.com/soundanalogous/IDxRFIDReader/blob/master/Examples/IDx_Reader_Firmata_Example/IDx_Reader_Firmata_Example.ino
>>>
>>> This way you read the sensor entirely on the arduino and only send the
>>> data you need back and forth. If you needed additional input and outputs
>>> such as buttons and LEDs, you could create 'objects' for them in you sketch
>>> such as:
>>>
>>> #define BUTTON 0x02
>>> buttonData[0] = buttonID; // so you can sort out which button the data
>>> belongs to
>>> buttonData[1] = state; // PRESSED, RELEASED, LONG_PRESS, etc.
>>>
>>>     tagDataFirmata[0] = READ_TAG;
>>>     tagDataFirmata[1] = tagValue[0];
>>>     tagDataFirmata[2] = tagValue[1];
>>>     tagDataFirmata[3] = tagValue[2];
>>>     tagDataFirmata[4] = tagValue[3];
>>>     tagDataFirmata[5] = tagValue[4];
>>>
>>>
>>> Firmata.sendSysex(BUTTON, 6, tagDataFirmata);
>>>
>>>
>>> On Thu, Oct 20, 2011 at 12:39 AM, Julian Gautier <
>>> jul...@al...> wrote:
>>>
>>>> Hi Jeff,
>>>>
>>>> I updated my code to follow your idea as seen here:
>>>>
>>>>
>>>> https://github.com/jgautier/Arduino/commit/4e2b8ee387b4b11323267a65646372a01415db0b
>>>>
>>>> Note I had to define the shiftValue array at the top of the
>>>> sysexCallback function.  I did this so I did not have to use braces is
>>>> in the case, and its probably best to define it once anyways.  I
>>>> tested this out with the temp sensor and it works fine.
>>>>
>>>> I did not add anything around the SHIFT pin mode.  In the temperature
>>>> sensor i am using I actually do a digitalRead on the dataPin.  I am
>>>> not familiar enough with the temp sensor communication or the arduino
>>>> code for the temp sensor to know if it is needed or not.  If the temp
>>>> sensor does need to digitalRead on the dataPin than it does not seem
>>>> appropriate to add a new SHIFT pin mode.  I am not sure if there would
>>>> ever be a use to do any reads on the clockPin.
>>>>
>>>> I also did not change anything around with the number of bytes you can
>>>> send or the latchPin.  I did this for two reasons, one it was easier
>>>> to code :p, but also when programming directly on the arduino you can
>>>> only shiftIn or shiftOut one byte at a time and you also control the
>>>> latchPin manually.  I figured it might be easier to implement the
>>>> protocol if we kept in align with the how arduino language works.
>>>>
>>>> I also did some crude code for a shift register as seen here:
>>>>
>>>> https://github.com/jgautier/firmata/blob/dev/examples/74hc595.js
>>>>
>>>> Overall I dont really feel experienced enough to say this is the
>>>> "right" or "best" way to implement this feature so I am definitely
>>>> open to suggestions.  Let me know what you guys think.
>>>>
>>>> Thanks,
>>>>
>>>> Julian
>>>>
>>>> On Sun, Oct 16, 2011 at 6:17 PM, Jeff Hoefs <sou...@gm...>
>>>> wrote:
>>>> > Hi Julian,
>>>> > This seems like a convenient addition (especially since there is not
>>>> current
>>>> > way to shift bits in or out using firmata). Shiftin/Shiftout should
>>>> also be
>>>> > able to work with a shift register so I don't think what you're trying
>>>> to
>>>> > accomplish requires a separate protocol that what is already in the
>>>> wiki on
>>>> > Firmata.org (however since that particular protocol has not been
>>>> implemented
>>>> > it's also open to revision). The particular device you are interfacing
>>>> with
>>>> > doesn't require a latch, but other components may so it should
>>>> > be accommodated somehow. One option is to require users to handle the
>>>> latch
>>>> > separately by setting the latch pin high or low by setting the digital
>>>> pin
>>>> > high or low through firmata. Another option is to add a flag to the
>>>> protocol
>>>> > that indicates whether or not to use a latch pin (although at that
>>>> point you
>>>> > start to send more data than should be necessary).
>>>> > Another thing to decide is if a shiftin/out command should only shift
>>>> 8 bits
>>>> > at a time (so the user would have to call shift in or out multiple
>>>> times to
>>>> > handle all of the data, or to send or receive up to x number of bits
>>>> with a
>>>> > single call to shiftin or shiftout in which case you'd handle the
>>>> reading or
>>>> > writing of multiple bytes in your code in StandardFirmata.
>>>> >
>>>> > Assuming latch is handled separately and you can only send or receive
>>>> a
>>>> > single byte at a time, you can simplify your code as follows (since
>>>> LSBFIRST
>>>> > is defined as 0 and MSBFIRST is defined as 1 in Arduino.h). Note that
>>>> the
>>>> > LSBFIRST (0) and MSBFIRST (1) values need to be defined in the
>>>> protocol.
>>>> >
>>>> >   case SHIFT_OUT:
>>>> >
>>>>     shiftOut(PIN_TO_DIGITAL(argv[0]),PIN_TO_DIGITAL(argv[1]),argv[2],argv[3]);
>>>> >     break;
>>>> >   case SHIFT_IN:
>>>> >     byte shiftValue[] =
>>>> > {shiftIn(PIN_TO_DIGITAL(argv[0]),PIN_TO_DIGITAL(argv[1]),argv[2])};
>>>> >     Firmata.sendSysex(SHIFT_IN,1,shiftValue);
>>>> >     break;
>>>> >
>>>> > to use this with a component requiring a latch pin a user could send
>>>> > something like this from a client application:
>>>> > LSBFIRST = 0;
>>>> > MSBFIRST = 1;
>>>> > for (i=0; i<numBytes;i++) {
>>>> >     sendDigital(latchPin, LOW);
>>>> >     sendShiftOut(dataPin, clockPin, LSBFIRST, data[i]);
>>>> >     sendDigital(latchPin, HIGH);
>>>> > }
>>>> > You may also need to set the pin type to SHIFT for the clock and data
>>>> pins
>>>> > so that they are ignored by digital reporting in Firmata since it's
>>>> the
>>>> > value returned by sysex you are looking for, not the pin changes that
>>>> will
>>>> > happen while shifting bits. You'll probably need to add a SHIFT_CONFIG
>>>> > command to set the pins to type SHIFT (and you can also set the
>>>> digital
>>>> > input and output appropriately at that time).
>>>> > best,
>>>> > -jeff
>>>> > On Thu, Oct 13, 2011 at 12:23 AM, Julian Gautier
>>>> > <jul...@al...> wrote:
>>>> >>
>>>> >> Hi All,
>>>> >>
>>>> >> I took a crack at implementing shiftIn and shiftOut in Firmata.  I
>>>> >> implemented this so I could utilize the shiftIn and shiftOut function
>>>> >> directly, this was needed to use the sht15 temp+humidity sensor
>>>> >> according to this code
>>>> >> http://wiring.org.co/learning/basics/humiditytemperaturesht15.html.
>>>>  I
>>>> >> did not follow what was in the protocol spec because that appeared to
>>>> >> be geared towards controlling a shift register.  Quick summary of the
>>>> >> changes.
>>>> >>
>>>> >>
>>>> >>
>>>> https://github.com/jgautier/Arduino/blob/new-extension/libraries/Firmata/Firmata.h
>>>> >>
>>>> >> Added two variables for SHIFT_IN=0x72 and SHIFT_OUT=0x73.  I did not
>>>> >> use the SHIFT_DATA command because I figured we may still want to use
>>>> >> it for a shift register in the future.
>>>> >>
>>>> >>
>>>> >>
>>>> https://github.com/jgautier/Arduino/blob/new-extension/libraries/Firmata/examples/StandardFirmata/StandardFirmata.ino
>>>> >>
>>>> >> New code starts at around 439.  I basically added two cases to the
>>>> >> switch to handle the two new commands.
>>>> >>
>>>> >> Here is my javascript library that implements this:
>>>> >>
>>>> >> https://github.com/jgautier/firmata/blob/dev/lib/firmata.js
>>>> >>
>>>> >> code at line 235 handles data coming back from a SHIFT_IN command.
>>>> >> code after line 517 is what sends the commands to the board.
>>>> >>
>>>> >> Finally here is some code controlling the temp sensor via JS (code
>>>> >> needs to be cleaned up).
>>>> >>
>>>> >> https://github.com/jgautier/firmata/blob/dev/examples/sht15.js
>>>> >>
>>>> >> Let me know what you guys think.
>>>> >>
>>>> >> Thanks,
>>>> >>
>>>> >> Julian
>>>> >>
>>>> >>
>>>> >>
>>>> ------------------------------------------------------------------------------
>>>> >> All the data continuously generated in your IT infrastructure
>>>> contains a
>>>> >> definitive record of customers, application performance, security
>>>> >> threats, fraudulent activity and more. Splunk takes this data and
>>>> makes
>>>> >> sense of it. Business sense. IT sense. Common sense.
>>>> >> http://p.sf.net/sfu/splunk-d2d-oct
>>>> >> _______________________________________________
>>>> >> Firmata-devel mailing list
>>>> >> Fir...@li...
>>>> >> https://lists.sourceforge.net/lists/listinfo/firmata-devel
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning@Ciosco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>> _______________________________________________
>> Firmata-devel mailing list
>> Fir...@li...
>> https://lists.sourceforge.net/lists/listinfo/firmata-devel
>>
>>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
>
> http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
> Firmata-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firmata-devel
>
>
>
>
>
>
> ----------------------------------------------------------------------------
>
> I have always wished for my computer to be as easy to use as my telephone;
> my wish has come true because I can no longer figure out how to use my
> telephone."  --Bjarne Stroustrup (creator of C++)
>
>