Interesting ISP solution without a header

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

these look like an interesting isp solution..just got a set today to try on a proto..
http://tag-connect.com/index.html

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

It SHOULD work. Probably a limited number of connect/disconnect cycles due to mechanical wear in the alignment holes on the board.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

It may save an incredibly tiny cost for a pinheader, but adds cost for special layout with those big holes. It sure doesn't save any space at all.
Comparing with an RJ-12 is ridiculous.

I've been using the "standard" 10-pin atmel programming layout, but not mounted any connector, I just have a pin header that I "plug" into the holes when programming. If you hold it a little at an angle, it gives perfect contact with the board. I have programmed several hundreds of boards this way, and it fails maybe once every 30-40 boards. Just realign a little and rerun.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

I looked at it, thought it might be useful, but then saw it's only 10in in length. Too short for comfort in the environment I work in. Probably a result of trying to match microchip's pinout and not giving damn about designing for signal integrity and ergonomics (ie. purely design for the marketing department's foot).

I do sometimes use a pad layout, as I published in https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=61532&highlight=connector about nine months before that silly board they're showing was designed.

And while that probe of theirs might last 100k cycles in the hands of a careful lady, how long will it last in the hands of disillusioned off the street hired help? (not to say that you won't find skill in off the street hired help).

/Kasper
(if damn is considered a swear word, I'll drop a M16 in the jar)

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

For ISP I use a dual row set of spring contacts from mill-max. the tech needs only hold the connector in place. For debugging I would include retention clips.

Anything that we do for production has a full test-jig built, that also has the programming header in place, so the retention clips are the board mounting holes. So there is no special layout, or holes required. The standard 0.1" box header footprint is all that is required. Sometimes I'll reduce the hole size, but it's not necessary.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Now, if you guys want to explore something really useful, how about devising a good method for ISP (and/or bootloader) of an encapsulated AVR? (Think potted, in a plastic case.)

I was thinking of Hall sensors on the AVR, and inductors for the electro-magnets?

RF probably isn't feasible, since the cost per unit needs to be minimal.

I guess putting a carrier on the V+ power wire might be feasible?

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

Could be a problem since it needs to be bidirectional (to get signature, at a minimum).

If magnetic, you would want to run it at a reasonably high clock to minimize inductance (number of turns).

Are surface contacts out? No room for pins to the host board?

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Optical transmission.

Stealing Proteus doesn't make you an engineer.

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

ArnoldB wrote:
Optical transmission.

Some DMM's have this. Little plastic windows with IR LEDs to allow isolated communication with a PC. Seems to work quite well.

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

theusch wrote:
Now, if you guys want to explore something really useful, how about devising a good method for ISP (and/or bootloader) of an encapsulated AVR? (Think potted, in a plastic case.)

I was thinking of Hall sensors on the AVR, and inductors for the electro-magnets?

RF probably isn't feasible, since the cost per unit needs to be minimal.

I guess putting a carrier on the V+ power wire might be feasible?

Lee

simple 1 LED on the device, and one on the programmer, gives you all that you need for full bi-directional communications.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Quote:

simple 1 LED on the device, and one on the programmer, gives you all that you need for full bi-directional communications.

Hmmm--I've never thought about that one. I do have an LED on the encapsulated device I'm thinking of,but it is red-green. I've never done LED communications, though I have used a green LED for ambient light sensing.

Can you give any getting-started links or search terms? As LED persistence is measured in milliseconds (right? from multiplexing 7-seg displays) I'd guess reliable data rates would be measured in a few hundred bits/second?

Oh, this would be the same as IR, only visible?

That would be way cool. At startup you could look for the bootloader "pattern" on the incoming LED...

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

milliseconds is wrong (that's the retina). Microseconds is more likely, as long as we aren't talking about white leds with phosphor, and most of the infrared types are sub-microsecond to low nanoseconds.

The tricky part is finding a LED that works well as a photodiode and (!) is rated for 3.3V or 5V reverse bias. Some of the ultrabright types I tested last time this came up are very inefficient photodiodes.

/Kasper

edit: To avoid gnashing of teeth, remember to use shorter wavelength emitter than receiver. A green led will not detect red light. A red led will detect green light.

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

Any experience with red source, red detector?

As a detector, they could be a bit on the slow side, largely determined by the external circuit. It depends on whether the diode is operating in current mode or voltage mode as a detector. In either mode, they appear to be limited by the normal forward voltage drop of the diode.

It might help if the diode could be read by the comparator.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

I recall something like one-half to one-third. The reason might be that the emitter isn't narrow (16nm half-power bandwidth is typical), so about one half the energy gets detected?

/Kasper

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

I did a quick mock-up. A flashing bike rear light (the kind with one led and two coin cells inside, eur2 in the local supermarket) as transmitter, and the receiver a similar red LED attached to two pins on an AVR. With the measure loop running at 25kHz and just using the led capacitance, I have really good link at 20cm.
One fourth of that, 6kbps, would be a reasonable bit rate. That's 600 bytes per second, or 25 seconds for bootloading a Mega16.

It might be good to have a real photodiode on the programmer end; That way the device getting programmed doesn't need a bright led to get good range.

sample  charge time
  122    30 (30=10us charge time)
  123    30 (the light is on)
  124    30 (distance is 20 cm)
  125    30
  126    30
  127    87
  128   100  (>35 us charge time)
  129   100  (it is dark)

/Kasper

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

IIRC, some european washing machines manufacturer uses this technique not only as bootloader but also as service data link: they use one of the LED's on one of the buttons as the emiter and receiver. They remove the plastic button and replace it with a simple LED with uC that fits exactly on the button hole. It works like a charm. Red LED, BTW.

Once I saw an appnote about this technique, where the uC used two pins to drive the LED, pretty similar to Kasper arrangement. The figures were about the same he posted about data rate and distances.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

theusch wrote:
Quote:

simple 1 LED on the device, and one on the programmer, gives you all that you need for full bi-directional communications.

Hmmm--I've never thought about that one. I do have an LED on the encapsulated device I'm thinking of,but it is red-green. I've never done LED communications, though I have used a green LED for ambient light sensing.

Can you give any getting-started links or search terms? As LED persistence is measured in milliseconds (right? from multiplexing 7-seg displays) I'd guess reliable data rates would be measured in a few hundred bits/second?

Oh, this would be the same as IR, only visible?

That would be way cool. At startup you could look for the bootloader "pattern" on the incoming LED...

Lee

google "tr2003-35"

first hit should be the PDF:
"Very Low-Cost Sensing and Communication Using Bidirectional LEDs"

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Quote:

first hit should be the PDF:
"Very Low-Cost Sensing and Communication Using Bidirectional LEDs"


...
Quote:
... using two identical, generic PIC microcontroller boards ...

:( But thanks anyway.

LOL--that should be a good starting point.

A small complication is that the particular encapsulated app I was thinking of has a red-green LED with single current-limiting resistor. So it may not be practical but I have to think about that.

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

While yes they did their proof of concept using a PIC, it is no problem to do it using an AVR. They are not using any special feature of the PIC to make it work.

I seem to remember another version of the document (or perhaps a supplemental one) where the "iDroppers" were made with AVR's. (or it may have been one of the EE476 projects)

[edit]yes it looks like it was a EE476 project... look for the "SecureLED" project from 2006

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

LOL--While you were responding, I was digging with Google. As is often the case, those Cornell students have already done the legwork for us.

http://courses.cit.cornell.edu/e...

Quote:

While yes they did their proof of concept using a PIC, it is no problem to do it using an AVR. They are not using any special feature of the PIC to make it work.

I knew that. ;)

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

theusch wrote:
As is often the case, those Cornell students have already done the legwork for us.

Good to get some return on our investment. Quite often it is US doing the legwork for them... sometimes even their homework.

oh and I don't think the dual colour LED should be a problem, as long as it isn't one of the 2 pin versions where the LED's are arranged in opposing directions. Just when you enter into the communications mode, you'll only be using one of the two dies in the package.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Quote:

as long as it isn't one of the 2 pin versions where the LED's are arranged in opposing directions.

Of course it is--you didn't expect this to be easy, did you?

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 tried the method some time ago too.

I remember that the sequence should be made so that the internal pull-up is off in all cases, as the direction and value of a pin cannot be changed simultaneously.

For example like this:

Led on:
A=output high
K=output low

Led off high:
A=output high
K=output high

Led off low:
A=output low
K=output low

Led reverse:
A=output low
K=output high

Led input good:
A=input high-z
K=output high

Led input bad:
A=output low
K=input high-z

So this means that it is best to have the output high and change the low output to input and measure until input is high, otherwise you must go through input with pull-up state which messes up things.

Now this left me wondering to which side the LED resistor should be connected so it does not act like an antenna, or no excess noise is coupled there. I bet the bigger LED contact should be the stable output pin and smaller LED contact should be the input pin.

Basically, the generated photovoltaic voltage can be measured with an ADC too, but I guess that is too slow.

I have also been thinking about acoustic communications to upgrade firmware or transfer data, but anything other than ISP connector requires a bootloader. Even a soundcard I/O would be nice, as someone here on AVRfreaks did a soundcard uart.