Bluetooth communications interupt?

[Robots_Australia]

Hi all, its been 15 years since i played with robotics and last time was a cut down XT 10 mhz mobo, 5 1/4 drives, serial and parallel ports, with interrupt tables in DOS, was in, so pls bare with me.

I am starting small to get use to it all again, so anything I am making at the moment is sensing and measurements.
now using the microchip 16F series.

End Result: To make a generic interface for robots with bluetooth for com's with LapTop BT. Also to Program uC with BT from laptop using ICSP

Modular design with common bus for uC's with Com's with LT (many preprogrammed uC talking to each other with over rides from LapTop similar to Interupt tables in DOS)

Current Attempt
To make 10 channel 10 Bit (multiplexed (4 bit latch) Voltage Monitor for -250ma to +35V Wireless to LapTop (Data Logging) and 2x40 Display.

Current problem
I have alot about the communications chips and protocols.
The problem is once the information is stored at the uC level, how is the information used? (individulal bits or bytes)

Should this (uC) be part of an interrupt table (of sorts) or separate chip to distinguish uC / chip addresses and whether its a command or program (ICSP)?

Volt input > Latch >  |
.                            |
.                            |<-Command-> uC(soft interrupt table) <-> ttl <-> BT <-> Laptop
.                            |                    |
Volt input > Latch >  |                    |-----------> ICSP
                                                  V           
                                              Display   
OR

Volt input > Latch >  |         uC\chip inputs outputs etc
.                            |         |
.                            |---> uC(Addr2)<-command->uC(interrupt table Addr1) <-> ttl <-> BT <-> Laptop
.                            |         ^                            |
.                            |         |                             |
.                                      |                             V
Volt input > Latch >  |          ------------------> ICSP(Addr1\Addr2...)
                                       V           
                                    Display   

Note if the uC doesnt have an a\d then there would be an A\D between the latch and uC.
Cheers

[Graynomad]

Should this (uC) be part of an interrupt table
how is the information used? (individulal bits or bytes)
or separate chip to distinguish uC / chip addresses and whether its a command or program (ICSP)?

Sorry RA but that's a very confusing post, none of these statements make any real sense.

Here's what I understand you want to do.

Read analogue data
Store this info on a uC
Transmit the data to a laptop.

Is that the case?

ICSP has nothing to do with the storage of the data, data is (usually) stored in RAM.

Once stored it can be transmitted (usually via the uC's UART) to a PC using one of many possible comms methods. I haven't used BT but presumably that is an option.

Note if the uC doesnt have an a\d then there would be an A\D between the latch and uC

That may be the case but these days you'd go a long way to find a uC without a few ADCs. Maybe not 10 though, in which case an analogue MUX can be used.

Also to Program uC with BT from laptop using ICSP

That will be a bit trickier but you can put a bootloader into the uC that will self program the chip using data form the serial input (and hense BT).

______
Rob

[Robots_Australia]

Thanks Rob, Maybe I should have slept before posting
Yes your right.

Read analogue data
Store this info on a uC
Transmit the data to a laptop.
BUT also
Allow the laptop to modify code (ICSP) in the uC or uC's, connected on a single bus with BT.
Allow the laptop to Modify the uC program ie change the scale or order of reads, put to sleep, turn off etc on the fly with BT. (Main reason for this is to allow wiring changes or maintenance on particular circuits without shutting down the whole system)

My thinking was that maybe a Master uC would be used for display (2x40) and comms between laptop and other uC's.
This would allow Programming of uC (ICSP recoding) and or uC addressing, for program control changes of uC/s on the fly.
So any chip on the bus can be reprogrammed via BT laptop and or turned off or behavior changed.

I dont think one chip would handle all that work, hence the interrupt type thing.
Hope that clears it up

[Graynomad]

I know nothing about BT, but I'll assume that there are products available that allow simple comms in an async-like manner.

Allow the laptop to modify code (ICSP) in the uC or uC's, connected on a single bus with BT.

To do this you will have to write your own bootloader, there are many examples around but AFAIK none of them allow addressing of uCs, hense writing your own.

Allow the laptop to Modify the uC program ie change the scale or order of reads, put to sleep, turn off etc on the fly with BT.

That's just a matter of writing a protocol that allows the PC to send commands to the uCs and get data from them.This will need some form of addressing as well.

I dont think one chip would handle all that work

From what I can see so far the only reason "all that work" exists in the first place is the fact that you want multiple uCs. If you have a single chip much of the job goes away.

So the only reasons for multiple chips are,
a) The data being read is dispersed such that it's not practical for a single chip to read everything due to the distances involved.
b) The aquisition speed is too fast and/or there are too many inputs for a single uC.

Can you fill us in on the nature and environment of the data being read?
______
Rob

[Robots_Australia]

I live in a 40foot school bus (converted to motor home) with 2 main electrical systems... 12V and 24V.
24V is the bus running gear and 12v is the internal system lights power etc.

The roof has 6 solar panels ((12v 120W each) 0-25v output) divided into 2. 3 on the passenger side and 3 drivers side.
2 Smart chargers/controller each 30 amps with shunts for monitoring loads (not charge) on each.
12V/240v inverter with 250A shunt (250 ma).
24V bus system (20V-28.5V charging system) and future shunt for all electrical except starter motor.

The 2x40 display will be for the monitoring while driving and parking in best place for maximum solar input.(I always park east west but depending on summer or winter, slight changes by degrees, makes a huge difference so its trial and error)
Possibly another display at the rear near the 12 system fuse box and controllers.
Laptop for data logging.

Long term I would like to build a dash to automate, monitor and control most of bus from the drivers seat.
I have a check list of things to lock down, turn off, open and close prior to moving. eg TV aerial, doors, vents, windows, ceiling fans etc.

[Graynomad]

I live in a 40foot school bus (converted to motor home) with 2 main electrical systems... 12V and 24V.
24V is the bus running gear and 12v is the internal system lights power etc.

Well now there's a coincidence, I live in a 6x6 Army truck with 12v truck wiring and 24v house, full solar etc. Have done for10 years now.

Check here if you're interested

http://www.robgray.com/default_2.php

Long term I would like to build a dash to automate, monitor and control most of bus from the drivers seat.

I'm currently designing a system to do this

http://busnet.robgray.com/index.php

Right now I'm desinging the "controller" that will use an ATmega2560 and a QVGA touch screen. I plan to have 2-3 of these controllers in the truck, in the cab, house, and maybe a storage bin or two.

We're over in Perth at present, what neck of the woods are you in?

______
Rob