ISP of multiple Tiny85s on a PCB

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I'm designing a PCB that will have multiple SOIC8 ATtiny85s, while developing they will of course need to he flashed numerous times but even when finished there will be upgrades, bug fixes etc.

So my question is, how can I implement the ISP for all these chips?

My current circuit looks like this (for 2 chips, this will be replicated 8 times making 16 processors in total).

NOTES:

    1: The application requires all the SPI signals to be in parallel.
    2: There are 16 PGM signals (PGM1-16) running to a header, they can be connected with a flying lead to the RST of the programmer.
    3: The normal RESET function has to be maintained, hense the BAT75 so a system reset gets all chips but a programming reset only affects the chip being programmed.
    4: SS is handled in software, in theory all chips NOT being programmed will hold MISO in tri-state and ignore the activity on the other lines.
    5: If however I get a rogue chip that won't release it's MISO line I will be in trouble, to handle this I might allow each chip's VCC to be disconnected or just flash it to force it to behave. Assuming I can identify the culprit that is.
    6: SPI lines will be buffered so the programmer doesn't have too much loading.
    7: There's almost NO way to add components, the board is chocka block, but for a creative idea I might be able to rearrange a few things, I haven't run traces yet.
    8: I know I should have pullups on RST, I'll have to rely on the internal one.

Any faults in this, or better ideas?

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can't directly connect all those lines together as far as ISP is concerned ( you MIGHT be able to put in buffer ckts. and stuff to isolate them while programming but you say you have no more room ). Why don't you use a big enough AVR ? What's the app ?

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

During verify they will all be responding on MISO...and guess what will happen?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All the SPI lines are buffered so there's only a single load on the programmer, that's already on the board so I think I'm OK there.

As for the app, 16 intelligent "set and forget" IO channels that can handle most types of IO. The theory being that I can run, for example, 7 servos, a few PWMs, several analogue IPs, a handfull of switches, some high-speeed counting, even some serial comms with almost no loading on the main processor.

That could be done with a larger processor but

a) I'm not convinced my coding skills are up to it, and
b) No normal processors have 16 ADCs, and
c) It seemed like a good idea at the time.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
During verify they will all be responding on MISO...and guess what will happen?

True, but only one knows it's being programmed. The others will have both RST and SS high, so their application will ignore the signals, as long as they behave.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should be fine with all SPI in parallel, and put one AVR into RESET at a time.

However, all the other AVRs will be running their regular applications. Quite honestly, there are very few Tiny applications that do not use the USI.

So the other AVRs are very likely to be in anything other than 3-state.

You need to have some method of putting everything into a comatose state. And another to let them run normally. e.g. they all read a certain pin at power-up.

So at power-up all programmed AVRs sit in a loop if this pin is low. Otherwise they run as normal.
A virgin Tiny will not have the pin-test, but it will not do anything either (except execute 0xFFFF's)

Your other alternative is to have each Tiny in debugWire mode.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
there are very few Tiny applications that do not use the USI

As indeed these do.

Here is my logic.

When bootstrapping the system as you say virgin chips will ignore everything.

The application is designed to listen on SPI but only enable MISO when it has been addressed.

Once programmed, if all other 15 apps are running correctly they will see a high on SS and tristate MISO, this is how I plan to daisy-chain them when the app is running so there's no difference when one is being programmed (I think).

The other USIDR regs may get filled with data but it will be ignored.

Quote:
You need to have some method of putting everything into a comatose state.

That would be safer, no method pops immediately to mind but I'll give it some thought.

Quote:
Your other alternative is to have each Tiny in debugWire mode.

I need the reset pin.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would suggest to program a bootloader prior soldering.
And every bootloader was listen on a different password.
So you need only one line, which was connected to all ATtiny in parallel.
Furthermore you can use the reset line as IO and still reprogram.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I would suggest to program a bootloader prior soldering.
And every bootloader was listen on a different password.

Hi Peter,

That's "essentially" what I'm doing, the "bootloader" is the ASM app. It has to talk SPI to a host processor and the "password" is it's address. However I think I get what you're saying, I could write a bootloader that looks at the reset line and loads data into flash if reset is low. I'd lose my hard reset option but that may not matter, my programs never go belly up :D

Then if I'm willing to lose the hard reset I can go back to the debugWire option to.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

b) No normal processors have 16 ADCs, and

Define "normal".

Now, I have a number of apps with remote "modules", typically with a serial link. but that is to address a distance issue, not a channel issue. I can't think of any production apps of mine that have more than one AVR on the same board.

As you have seen, when you start multiplying your "motes" you end up with a number of issues.

All apps are different, and perhaps there is a unique feature of the '85 that makes this all worthwhile. Myself, if it was 16 ADC channels I needed and I'm comfortable with AVRs, I'd put in a Mega640 and save board space and cost and power and a LOT of complexity.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok you got me there, the 640 and a few others have 16 ADCs. They're in TQFP100 packs but I suppose I can learn to solder them.

Each "channel" has to be able to do any of several IO options (dig IO, analogue in, PWM, RC servo, serial, counter/timer and probably a few things I haven't thought of yet) so it's not just the ADCs I need, but you've got me thinking now and I did ask for better ideas as well as thoughts on the multi-processor programming.

A 640 would reduce just about everything including cost and hardware complexity (which is also a recurring cost), most of the issues that prompted me to post this thread in the first place, and a few I know about but haven't mentioned.

The only issue I can see is the complexity of the software that runs all these IO functions at once, possibly more complex than I've done before but doable.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Each "channel" has to be able to do any of several IO options (dig IO, analogue in, PWM, RC servo, serial, counter/timer and probably a few things I haven't thought of yet) so it's not just the ADCs I need, but you've got me thinking now and I did ask for better ideas as well as thoughts on the multi-processor programming.

The '640 has enough channels and timers and ICP and etc. that you can indeed do a kind of "modular" approach. In practice, we've used it very little--as with nearly all of our apps it ends up being a more-or-less fixed configuration.

I ran 4 channels each to "analog" (or GP digital) slots. Each USART goes to a "commo" slot along with an extra pin. That way you can do RS485 WE/~RE, or SPI master.

"Timer" slots have two 16-bit OC channels and a Tn and ICPn.

The result is four "analog" slots, four "commo" slots, and three "timer" slots. Andy can be "general" slots as well, along with three "general" slots.

As I said, I spent quite a bit of time sorting and allocating and routing and in the end we rarely use the inherent flexibility.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done something like this before (though only with 2 AVRs). However,
I did not try to dispatch /RESET but SCK instead. That way, all AVRs
in parallel are still held in reset condition (as asserting /RESET is
always the very first step when starting the ISP sequence), but only the
"current" device gets SCK pulses. Of course, all unused AVRs must not
get anything on SCK, so instead of leaving their SCK inputs floating, I
applied weak pulldown resistors to these pins.

MISO and MOSI can all be connected in parallel, assuming the application
on the respective devices can tolerate that, of course. In my case, both
AVRs were SPI master and slave, respectively, anyway, so connecting their
SPI pins was OK (the device selection jumper had a third position where
master and slave got their SCK signal connected together).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jorg: In my case (with 16 chips) I would have to disconnect 15 of them then reconnect after programming. I'll have a think about that because it does solve the problem of ensuring the other 15 don't try to get in on the act. Did you have reset still coming from the programmer or controlled some other way?

Lee: I just did a quick test layout with a 640, I've gone from both sides of the PCB packed with components to one side with some room. That's got to be a big plus.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Did you have reset still coming from the programmer or controlled some other way?

Yes, /RESET came from the programmer. I don't need it during normal
operation, the builtin power-on reset was good enough.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your input guys. I'm going to go with the single huge chip (640/1280) model rather than the multiple small chips.

I just have to figure out now to solder the sucker. :)

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It normally takes me 1-2 minutes.

- Position the chip aligned to all PCB pads.
- Solder 2 opposite corner pins to PCB pads to firmly keep the chip in place.
- Apply much of liquid neutral flux (e.g. rosin + alcohol) over the pins.
- Get the melted solder drop on the soldertip (iron temperature = 310..320 C)
- Move the tip with this drop across the whole pin line, do not bother about solder bridges.
- Repeat the above for all 4 chip sides, add more solder and flux when necessary.
- When done, apply more flux over the pins.
- Wipe off the excess of solder with a "Solder Wick" braid and flux (iron temperature = 330..350 C).
- Brush away the flux from the PCB with alcohol.
- Enjoy :)

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I just have to figure out now to solder the sucker. Smile


Perhaps you can find an available "carrier" board that brings out all the pins. For your stated app, that might give you the flexibility to attach "modules" to the ports. (In my described app I sorted/routed the signals as described so one of my "slots" might have signals from multiple PORTs.)

This is the Schmartboard EZ version:
http://www.schmartboard.com/inde...

I don't think Olimex has a centipede. I thing there were threads on this; hunt them out.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
It normally takes me 1-2 minutes.
As it has been a while since I tried to solder anything,
I will refrain from reaching through the monitor and strangling you.
There is nothing quite like being told something is easy while one
is struggling and has yet to see the light at the end of the tunnel.
How long did it take you the first time?
Quote:
- Position the chip aligned to all PCB pads.
- Solder 2 opposite corner pins to PCB pads to firmly keep the chip in place.
- Apply much of liquid neutral flux (e.g. rosin + alcohol) over the pins.
How much is enough? How much is too much?
Quote:
- Get the melted solder drop on the soldertip (iron temperature = 310..320 C)
- Move the tip with this drop across the whole pin line, do not bother about solder bridges.
- Repeat the above for all 4 chip sides, add more solder and flux when necessary.
When is necessary?
Quote:
- When done, apply more flux over the pins.
- Wipe off the excess of solder with a "Solder Wick" braid and flux (iron temperature = 330..350 C).
- Brush away the flux from the PCB with alcohol.
- Enjoy :)

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See this tutorial for answers to all of your questions.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I just have to figure out now to solder the sucker.
No, no, no the sucker is for REMOVING the chip.....you want the soldering iron.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've seen those carrier or breakout boards before, minor detail, my entire PCB is only 1.8x1.8", they appear to be 2x2 already :)

Here's a pic of the initial layout.

It will still be pretty tight and there's a heap of components on the other side as well.

As for the soldereing, like everything else I figure if others can do it then so can I. I'll cross that bridge when I come to it.

That SF tute was good, they have another showing the use of stensils and paste as well.

Quote:
sucker is for REMOVING the chip

Oh, this is more confusing than I thought. :?

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'll cross that bridge
Suckers are good for removing bridges too. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A flow type tip, for your soldering iron will make it really easy.