[evla-sw-discuss] MIB Study Group-Search for the MIB Processor

[Bruce Rowen]

Barry Clark wrote:

> What we have been talking about for a MIB is a pretty powerful machine,
> and it is not clear to me that any modules will need to have a second
> microprocessor in them.  The only one I can think of that might is a
> redesigned ACU.  So I would downgrade the importance of dual ported RAM.

Agreed. Might be a nice high speed interface for some devices though (which I
have no clue)

>
>
> I think a watchdog timer is absolutely critical.  If we don't have one,
> we must build in the capability to remotely cycle power to any MIB.

Yep

>
>
> I don't know what a SPI interface is, nor a JTAG.

Serial Peripheral Interface (serial A/D's etc.) JTAG is a serial programing/ICE
style interface (I think)

>
>
> One timer is a necessity.  Two are occasionally useful.  Three are overkill.
>
> We haven't really discussed the philosophy of loading the particular
> software of the MIB.  Possibilities include:
>     1.  Software for all possible MIBs lives in the on-board flash; MIB
>         decides what sort of MIB it is, starts appropriate tasks.
>     2.  Software lives in on-board flash, OS has routine to easily reload
>         flash if the M/C system detects that it is for the wrong device
>         or the version ID is out of date.
>     3.  On boot, MIB realizes what sort of device it is in and requests
>         M/C system to supply it with the requisite software.

I think more along the lines of 3, except MIB has basic "monitor/debug" routine

for low level register/address access plus config software for the biggies like
the ethernet,
serial ports, and timers.
Module then decides who it is and does a TFTP type boot load (much like the
VxWorks ant computers)
This way lone modules could be tested and played with at a low level on a bench
or "configured" and
run as full blown MIBs depending on the capability of what higher level host
(laptop, Ant control comp, or dumb terminal)
is plugged in.

>
> All have their advantages and disadvantages.  It is quite likely that some
> packages will support one better than the other, so we ought to make up
> our minds which one we want.
>
> But in my mind the driving necessity is ease and compatibility of software
> development.  I suspect that we shall spend as much money on the software
> as on the design and construction put together.

Very true.

>
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss