[Gghc-discuss] Erich's software questions

[Brian Duggan]

More responses below. I'm coming up with a lot of questions now, so we
should discuss these more tonight.

On 4/25/11 11:44 AM, Jonathan Manton wrote:
> Responses below:
> 
> On Apr 25, 2011, at 11:12 AM, Erich Heine wrote:
> 
>> Thanks! There are more responses inline below. First tho, can you
>> please put the relevant info in the wiki also? It needs to be there
>> anyway and having a good single, canonical, reference point is always
>> a good thing.
>>
> 
> Yes, when I get a chance.
> 
> 
>> On Mon, Apr 25, 2011 at 10:42 AM, Jonathan Manton
>> <jmanton at illinois.edu> wrote:
>> The connection between the User Arduino and the Duinolab Controller is
>> intended to be some sort of serial protocol using the NewSoftSer
>> Arduino library.  I have defined the pins that are used for that (on
>> the pinouts wiki page, for the shields), but have done nothing with
>> software to implement that connection.
>>
>> Can those pins use the build int UART? Are they buffered? Do we need
>> to use a special library?
>>
> 
> You *can* use the hardware UART, but then you are sharing it with the
> USB interface, and you will get junk you don't expect going both ways,
> which is probably not a good thing.  Lots of people (on forums, blog
> posts, etc.) recommend against using the hardware UART it if you will
> ever have both USB and your peripheral in use (or even plugged in) at
> the same time.  So you *can* use it if you want, but then you would have
> to physically unplug the connection between the User Arduino and
> Duinolab Controller every time you change and download some code, which
> would probably be kind of a pain.  You would also lose the use of the
> serial console on the PC for debugging.
> 
> My recommendation is to try out the NewSoftSerial library described
> here:  http://arduiniana.org/libraries/newsoftserial/
> 
More on this below, but if multiple polling libraries interfere with
each other, might it be prudent to use the UART for version 1.0 and
insist that the user unplug from the lab? Far from ideal, but easier to
implement.
>>
>>
>> So you are now writing the api on top of I2C as well as all the
>> hardware? Instead, why don't you just provide a pointer to the
>> controller documentation, and a list of which pins connect which
>> LEDs/peripherals. The software can be written and debugged by others
>> that way, and take some work load off you.
>>
> 
> I have to do that work (and indeed, have already done that work) to make
> sure the wiring is correct.  It is already done, and in git
> (testcode/SAA1064test/SAA1064test.pde - despite the name, also has code
> for the I/O expander).
> 
> It *would* be nice if someone can take that code and package it into a
> library, and create the appropriate #defines for each of the
> LEDs/peripherals based on the pinouts in the wiki.
> 
> The parts being used are the SAA1064 (LED controller) and PCA9535 (I/O)
> expander.  The analog switching is done with a 4066B analog switch (but
> that is not an I2C peripheral - it is controlled via pins on the
> PCA9535).  I linked datasheets to those on the resources page.
> 
> 
>>
>>
>> This API will be on the Duinolab Controller.  There still has to be
>> some sort of communications protocol between the User Arduino and
>> Duinolab Controller (I am not implementing that - I think Brian was
>> working on it).
>>
>> Yeah, there needs to be that, but there are a lot of things to work
>> out aside from that. The end user API is not the same as internal
>> interfaces  to use between components we are in charge of. This is
>> they type of stuff I am talking about.
>>
> 
> Yep, I haven't done any of that (and don't plan to, at least in the
> timeframe for GGHC).
> 
>>
>> Can they be put on an interrupt (eg pushing the button changes the
>> state of both the pin representative of the button and the interrupt
>> pin)?  This makes life much, much easier from a software pespective.
>> Doubly so if the non-standard serial pins also don't cause interrupts
>> to be fired.
>>
> 
> Two of the three buttons could be put on interrupts (pins 2 and 3).  But
> there are only 2 external interrupts mapped to pins on the Arduino Uno. 
> So if you want to use more than 2 buttons, you'll have to do polling
> anyway for at least one, and it is probably easier to just treat all
> buttons the same.
> 
> You *can* put the polling routine on a timer interrupt.  And I believe
> there are already Arduino libraries out there that do that (e.g.,
> http://arduino.cc/playground/Code/Buttons though there are 4 or 5
> different button libraries referenced at
> http://arduino.cc/playground/Main/InterfacingWithHardware#Input ).
> 
So these would put us up to at least three libraries polling and
accessing the timer? Maybe there's a way to reduce the risk of a
trainwreck. We should take a look at methods to reduce the number of
libraries that poll I/O or at least cooperate to do preliminary work to
determine whether these libs play nice together.

Let's talk more tonight. I feel like there's probably more ways to
handle all this hardware at once.

Brian

> 
> _______________________________________________
> Gghc-discuss mailing list
> Gghc-discuss at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/gghc-discuss

-- 
Brian Duggan
Technical Projects Developer
UC Independent Media Center
http://www.ucimc.org | 631 223 8442