Art Interface Device logo   Project description  Development   Mailing List  Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AID: AID and the Orpheus Filter

From: Stefan Wiechula   stfn_aidpzooid.org
Date: Fri, 15 Oct 2004 09:27:40 -0700

: Sent via the Art Interface Device mailing list: aid@interaccess.org
: Use your "Reply All" to  reply to the list, "Reply" for private response

Hi Steven,  I'll jump straight to your questions..

On Fri, Oct 15, 2004 at 04:34:25AM -0400, Steven Wood wrote:
 .
 .
 .
> To that end, a few questions:
> ----------------------------
> 
> 1) We may be interested in running the entire program on board.
> Documentation says this is part of Level 2, and Mel Wilson makes mention
> of this in  http://interaccess.org/aid/list/msg00740.html, citing
> 'pretty heavy programming'.  Could someone quantify 'pretty heavy' in
> this context?  Would this change the hardware requirements, or is the
> transition strictly firmware?

I can never keep the user levels straight but for AID to operate
untethered (not connected through a serial port to a workstation) and do
something useful, you would have to rewrite some parts of the firmware
that runs on the PIC.  This firmware is written in C and spread across 3
files:  main.c, aid_cmd.c, and aid_lib.c.

  http://cvs.sourceforge.net/viewcvs.py/artinterface/Core/Code-Firmware/MAIN.C?rev=HEAD
  http://cvs.sourceforge.net/viewcvs.py/artinterface/Core/Code-Firmware/aid_cmd.c?rev=HEAD
  http://cvs.sourceforge.net/viewcvs.py/artinterface/Core/Code-Firmware/AID_LIB.C?rev=HEAD

The main function in main.c does a little bit of setup, then starts
polling the serial port and feeding received characters to the command
processor (contained in aid_cmd.c).  The command processor calls
functions in aid_lib.c that do useful things on the PIC.

To operate AID untethered, you would want to replace main.c and
aid_cmd.c with your own program that calls the functions in aid_lib.c
directly.  It should have a main loop that runs "forever" e.g.:

	for(;;)
	{
		sensation = get_whisker_inputs();
		action = some_algorithm(sensation);
		set_whisker_outputs(action);
	}

where get_whisker_inputs and set_whisker_outputs use the functions in
aid_lib to do A/D conversions, set up PWM outputs, or communicate on the
AID bus.

> 2) Assuming (1) is possible, would the bus be in a state where one AID
> mainboard could send commands to several other mainboards?  I assume at
> the very least some pinout and cabling changes would have to be made,
> but are there deeper bus limitations that would limit the total number
> of boards attached to such a bus?

This isn't part of the bus design but I'm sure you could make a cable
that connects several mainboard together.  All but one mainboard would
need to have it's firmware modified to act as a bus slave.  In the
current AID bus design there is one master (the mainboard) and up to 16
slaves (the peripherals).

You are limited to 16 peripheral cards since there are just 4 bits
allocated for addressing (giving 2^4 = 16 possible addresses).  However,
the read and write signals are wired seperately so the card that
"listens" at an address need not be the same as the card that "speaks"
at that address.  In short, you can have up to 16 input peripherals and
up to 16 output peripherals at the same time.

> 3) Assuming (1) is possible, is it possible to upload user mode code to
> AID using the serial port, or will we need to re-cook the chip in a PIC
> programmer each time a change is made?

We have been using a bootloader so you only have to cook the chip once,
thereafter you just hook up a serial cable and run some software on MS
Windows to download new code.

> 4) What is the greatest number of A/D channels available in one unit.  I
> seem to remember the number was eight.  Can these be done directly on
> board or is the analog breakout mentioned by Rob in
> http://interaccess.org/aid/list/msg00687.html necessary?

There are 8 A/D inputs on the PIC 16f877.  All of these are wired to
pins on the 40 pin socket (header).  The breakout board simply brings
these pins, plus power (+5V) and ground, out to screw terminals for
convenience.  You won't need this board as you will want to build your
own wiring harness I'm sure.

Another option would be to multiplex the analog signals coming into the
PIC.  I haven't tried it, but you might get away with something like the
HEF4067B that Rob used in the audio switcher peripheral.

  http://aid.interaccess.org/drupal/?q=node/view/148

With 8 of these 16-into-1 multiplexors you could measure 8*16=128 analog
signals, although it would take you some time to scan through them all.

An 8 channel 16-into-1 analog multiplexor AID peripheral would be nice
to have in the recipe book (worked solutions library) too.

> 5) Related to (4): How about total number of I/O channels if we go with
> simpler open/close switch sensors and actuators?  This may be sufficient
> if we reduce the current to the motors via hardware.

I don't quite understand this question but I'll give some examples.  

If you want to do everything through peripherals attached to the bus,
the 2^4=16 addresses times 8 bits data to each address gives you
16*8=128 single bit digital inputs and the same number of single bit
digital outputs.

What sort of control do you need over the motors?  If you'd like to
stop, start and change direction then you'll want an H-bridge circuit
such as Rob's motor driver board.  If you want variable speed control,
then you'll need to use the PWM outputs from the PIC or some other D/A
method.  If you only want to start and stop the motor (not breaking to a
stop, just removing power) then you can get away with a single bit
digital output per motor.

> 7) Related to (5): The motors we are prototyping with so far are very
> small 1.3V 10mm pager motors.  Could these be run straight off the main
> board logic power?  Rob mentions a motor driver board in
> http://interaccess.org/aid/list/msg00694.html, and I see references to
> it elsewhere also.  Is it complete?  Necessary?

What happened to (6)?  ;-)

It might be possible to run 1 of those motors off the board logic power
but certainly not 100 to 200 of them!  It's a good idea to isolate such
things from the microcontroller as much as possible anyways.  As above,
use an H-bridge such as the LS293 or, in the single bit output case, a
transistor (someone else can advise you which type).

> 8) Is there a current mainboard PCB image?  All links at
> http://aid.interaccess.org/drupal/?q=book/view/17 are dead.

Mike, John, any idea what happened there?

Steve, you might be able to pull some from here:  

  http://cvs.sourceforge.net/viewcvs.py/artinterface/Core/Schematics-and-PCB/

> 9) What is the break-even point in effort required for DIY etching vs.
> using a blank board?  Pending the outcome of questions 1-8, we may want
> to fabricate several of these.  If perhipheral I/O cards are needed
> we'll wish to etch those onto the same PCB.

In my opinion, the break-even point in terms of human time and effort is
about one board.  Wiring by hand takes *ages* whereas PCB layout is
quick if you're handy with the drafting software and etching takes less
than an hour on a sunny day, for most of which you can twiddle your
thumbs while the etching solution works away.

> The last and most important question is, will the support be there when
> we need it?Ý I realise AID is a volunteer project and the last thing I
> wish to do is stress a community that has already contributed so much.
> At the same time, I'd like to know that at least a couple of people
> would be available to answer questions where necessary and that the
> knowledge pool isn't completely unavailable this month.

I can't speak for others but I am quite busy in Waterloo these days.  I
can answer questions about the firmware by email perhaps but I won't be
in Toronto much.

Hope that helps,

Stefan.

:      messages saved at http://www.interaccess.org/aid/list
:      unsubscribe/help requests to mailto:Majordomo@interaccess.org