Exact match. Not showing close matches.
PICList
Thread
'[PIC]: most convoluted way to enter a program into'
2006\02\20@172124
by
Wouter van Ooijen
Recently there was a discussion that ended in a number of very
convoluted ways to enter a program into a PIC. I think I have the idea
about the ultimate convoluted bootloader: the non-electrical contacts
bootloader. It uses temperature cycling to enter the data! The PIC uses
its (temperature dependent) watchdog timeout to measure the temperature.
Reset it at >100C and it enters the bootloader. 90..110 is the idle
temperature, a temperature excursion above 120C is a 1, an excursion
below 80C is a 0. I guess 160 millibaud (= one bit per minute) is easily
done this way.
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
2006\02\20@173736
by
David VanHorn
Gated beta radiation?
Alpha might work but the window thing is a bit fussy.
Not something I'd want in a pocket loader, that's for sure.
You could put the chip in a big-ish magnetic field and rotate it, maybe
using micromachined reed switches.
:)
2006\02\20@173931
by
Byron A Jeff
On Mon, Feb 20, 2006 at 11:19:16PM +0100, Wouter van Ooijen wrote:
> Recently there was a discussion that ended in a number of very
> convoluted ways to enter a program into a PIC. I think I have the idea
> about the ultimate convoluted bootloader: the non-electrical contacts
> bootloader. It uses temperature cycling to enter the data! The PIC uses
> its (temperature dependent) watchdog timeout to measure the temperature.
> Reset it at >100C and it enters the bootloader. 90..110 is the idle
> temperature, a temperature excursion above 120C is a 1, an excursion
> below 80C is a 0. I guess 160 millibaud (= one bit per minute) is easily
> done this way.
Wouter I can hear you chuckling all the way over the ocean.
After the discussion though I do have a serious candidate for consideration:
Blinking keyboard LEDs.
Virtually every PC keyboard has LEDs which can be blinked with some precision.
A phototransistor in an optically isolated environment (my prototype I've
started on uses a dome made of Play-Doh brand modeling clay) should be able
to capture the blinking LED. I plan to use the same dual 555 clock/frame
timers to frame each bit.
I'm planning on testing how precisely a Linux program can blink the LED.
If the precision is sufficient to ensure that the blink length falls between
the clock and frame, then bits can be clocked out to the PIC.
BAJ
2006\02\20@174016
by
olin piclist
Wouter van Ooijen wrote:
> Recently there was a discussion that ended in a number of very
> convoluted ways to enter a program into a PIC. I think I have the idea
> about the ultimate convoluted bootloader: the non-electrical contacts
> bootloader. It uses temperature cycling to enter the data! The PIC
> uses its (temperature dependent) watchdog timeout to measure the
> temperature. Reset it at >100C and it enters the bootloader. 90..110
> is the idle temperature, a temperature excursion above 120C is a 1,
> an excursion below 80C is a 0. I guess 160 millibaud (= one bit per
> minute) is easily done this way.
Certainly novel. That would only take 5 days to get 512 instructions into a
14 bit core part. That'll teach you to hand craft every instruction.
Compilers need not apply.
But how do you get the code into the PIC that controls the temperature
before you have your thermal PIC programmer? I know, maybe I'll run out and
develop the ThermalProg unless you beat me to it with the Wisp-T.
******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC
consultant in 2004 program year. http://www.embedinc.com/products
2006\02\20@213847
by
William Chops Westfield
On Feb 20, 2006, at 2:39 PM, Byron A Jeff wrote:
> Blinking keyboard LEDs.
>
> Virtually every PC keyboard has LEDs which can be blinked
> with some precision.
>
None of my Mac keyboards has blinkable LEDs...
BillW
2006\02\20@214426
by
Herbert Graf
On Mon, 2006-02-20 at 17:40 -0500, Olin Lathrop wrote:
> Certainly novel. That would only take 5 days to get 512 instructions into a
> 14 bit core part. That'll teach you to hand craft every instruction.
> Compilers need not apply.
>
> But how do you get the code into the PIC that controls the temperature
> before you have your thermal PIC programmer? I know, maybe I'll run out and
> develop the ThermalProg unless you beat me to it with the Wisp-T.
All I'm hearing in my mind at this very moment is Homer Simpson
repeatably yelling "Patent Pending!" :)
TTYL
-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/
2006\02\20@215633
by
Ling SM
>>Blinking keyboard LEDs.
>>
>>Virtually every PC keyboard has LEDs which can be blinked
>>with some precision.
>>
>
> None of my Mac keyboards has blinkable LEDs...
or CRT or LCD
Ling SM
2006\02\20@222349
by
blackcat
I am late to this discussion, so maybe my idea has been advanced.
Use nano robots to find the data bits and each robot sets at
bit to zero or one and then destroys itself or leaves the chip
further instructions.
Including time to develop nanobots, programming time should
be about 9 years.
AGSC
2006\02\21@010351
by
Jake Anderson
all optical programmers should be able to work from pretty much any
"blinking" source
if you are using the keyboar LED's then use 2 of them and do some kind of
SPI polled by the PIC
dont have a LED? Get a real computer ;-P alternatly use the screen flashing
thingamajig.
I see no reason you couldnt get at least 1 byte/s through it (in Q-Basic
using peek and poke)
Ok i am tempted now to try making a PWMed heart beat signal on my scroll
lock key ;->
{Original Message removed}
2006\02\21@011524
by
Steve Smith
Serves u right for buying it !!!!
I seem to remember that apples form on trees and have pips
And who else would invent a one buttoned mouse ?
Kind regardz from a pea sea user
Steve
{Original Message removed}
2006\02\21@030315
by
Rob Hamerling
On 2/20/06, Wouter van Ooijen <spam_OUTwouterTakeThisOuT
voti.nl> wrote:
>
> Recently there was a discussion that ended in a number of very
> convoluted ways to enter a program into a PIC. I think I have the idea
> about the ultimate convoluted bootloader: the non-electrical contacts
> bootloader. It uses temperature cycling to enter the data! The PIC uses
> its (temperature dependent) watchdog timeout to measure the temperature.
> Reset it at >100C and it enters the bootloader. 90..110 is the idle
> temperature, a temperature excursion above 120C is a 1, an excursion
> below 80C is a 0. I guess 160 millibaud (= one bit per minute) is easily
> done this way.
Not bad for an artist ... but I had expected that a teacher on a technical
school would be better in math .... 1 bit/min = 16.7 millibaud.
Regards, Rob.
--
Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/
2006\02\21@030933
by
Wouter van Ooijen
> After the discussion though I do have a serious candidate for
> consideration: Blinking keyboard LEDs.
yuk, that's a *serious* candidate :(
> I'm planning on testing how precisely a Linux program can
> blink the LED.
> If the precision is sufficient to ensure that the blink
> length falls between
> the clock and frame, then bits can be clocked out to the PIC.
But there is more than one LED on a keyboard, so why not use separate
ones for clock and data? connect them to an I2C chip and you can do
everything you want!
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
2006\02\21@030938
by
Wouter van Ooijen
> But how do you get the code into the PIC that controls the temperature
> before you have your thermal PIC programmer? I know, maybe
> I'll run out and
> develop the ThermalProg unless you beat me to it with the Wisp-T.
It is a bootloader, so that code needs to be pre-installed. But it is so
obviously useful that I think Microchip will probably put it in an extra
ROM inside every future PIC chip. This would finally put programming in
reach of everyone who has the appropriate tools - in this case: a 5V
battery and an candle. Maybe uChip should add a buil-in thermopile to
eliminate the 5V supply?
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
2006\02\21@035522
by
Alan B. Pearce
>> I think I have the idea
>> about the ultimate convoluted bootloader: the non-electrical
>> contacts bootloader. It uses temperature cycling to enter
>> the data! The PIC uses its (temperature dependent) watchdog
>> timeout to measure the temperature. Reset it at >100C and
>> it enters the bootloader. 90..110 is the idle temperature,
>> a temperature excursion above 120C is a 1, an excursion
>> below 80C is a 0. I guess 160 millibaud (= one bit per
>> minute) is easily done this way.
>
> Certainly novel. That would only take 5 days to get 512
> instructions into a 14 bit core part. That'll teach you
> to hand craft every instruction.Compilers need not apply.
>
> But how do you get the code into the PIC that controls the
> temperature before you have your thermal PIC programmer? I
> know, maybe I'll run out and develop the ThermalProg
> unless you beat me to it with the Wisp-T.
<VBG> I had to laugh over this. I never thought there would be a way of
getting code into a device that was slower than the old set switches and
push button to load mechanism ...
Still I guess a thermal programmer would help with the current weather
conditions in the Northern Hemisphere.
2006\02\21@040402
by
Lindy Mayfield
Aren't there some quantum particles that exist in pairs, and when one turns the other one turns at exactly the same time? Maybe you can hook that up to a Pic in Seattle and program it from Maastricht?
Or what about using photons that are oriented like in quantum encryption? That way it would be secure, too, because no one could eavesdrop on the loading process.
{Original Message removed}
2006\02\21@052646
by
Jason
|
Linked particles can't be used to transmit information (if they could, it
would throw General Relativity out the window).
Without getting too deep into quantum physics under the PIC tag, the
particles have properities that don't have values until you try to measure
them (think Schrodinger's cat), but as soon as you measure the value of one
of the particles, both take on the same value. So in Seattle and
Maastricht, you'll both *see* the same bit, but you can't set what that bit
is so it's not useful to transmit data.
From: "Lindy Mayfield" <.....Lindy.MayfieldKILLspam@spam@ssf.sas.com>
Sent: Tuesday, February 21, 2006 1:03 AM
> Aren't there some quantum particles that exist in pairs, and when one
> turns the other one turns at exactly the same time? Maybe you can hook
> that up to a Pic in Seattle and program it from Maastricht?
>
> Or what about using photons that are oriented like in quantum encryption?
> That way it would be secure, too, because no one could eavesdrop on the
> loading process.
2006\02\21@054612
by
Russell McMahon
> Linked particles can't be used to transmit information (if they
> could, it
> would throw General Relativity out the window).
Give them time ... :-)
Ah, what an entangled web we weave.
RM
2006\02\21@064633
by
Lindy Mayfield
What about the rotating photons that were successfully used in quantum encryption? I heard that was actually done.
Or is that different from the particles that are linked?
I gotta read up on this stuff. I'm always fascinated how smart the Pic list people are. You guys know everything.
-----Original Message-----
From: piclist-bouncesKILLspammit.edu [.....piclist-bouncesKILLspam.....mit.edu] On Behalf Of Russell McMahon
Sent: Tuesday, February 21, 2006 12:42 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC]: most convoluted way to enter a program into a PIC
> Linked particles can't be used to transmit information (if they
> could, it
> would throw General Relativity out the window).
Give them time ... :-)
Ah, what an entangled web we weave.
RM
2006\02\21@092118
by
Byron A Jeff
On Tue, Feb 21, 2006 at 09:07:25AM +0100, Wouter van Ooijen wrote:
> > After the discussion though I do have a serious candidate for
> > consideration: Blinking keyboard LEDs.
>
> yuk, that's a *serious* candidate :(
>
Yes. It's a serious candidate. This whole discussion started a long
time ago with the premise that simple PC interfaces will disappear
and that USB will be the only periperal interface left. So how can
one bootstrap programming a PIC, especially a USB PIC not.
> > I'm planning on testing how precisely a Linux program can
> > blink the LED.
> > If the precision is sufficient to ensure that the blink
> > length falls between
> > the clock and frame, then bits can be clocked out to the PIC.
>
> But there is more than one LED on a keyboard, so why not use separate
> ones for clock and data? connect them to an I2C chip and you can do
> everything you want!
That's a possibility. However, one thing that I've noticed on my KB is
that there is optical crosstalk between the LEDs. Using only one makes
it more likely to work.
BAJ
2006\02\21@092303
by
Byron A Jeff
On Tue, Feb 21, 2006 at 05:03:51PM +1100, Jake Anderson wrote:
> all optical programmers should be able to work from pretty much any
> "blinking" source
> if you are using the keyboar LED's then use 2 of them and do some kind of
> SPI polled by the PIC
I find optical crosstalk in my LEDs. When one lights, you can see some of
the light through the others.
BAJ
2006\02\21@103629
by
Sergey Dryga
Ling SM <ipal11 <at> singnet.com.sg> writes:
>
> >>Blinking keyboard LEDs.
> >>
> >>Virtually every PC keyboard has LEDs which can be blinked
> >>with some precision.
> >>
> >
> > None of my Mac keyboards has blinkable LEDs...
>
> or CRT or LCD
>
> Ling SM
There was a Timex watch with calendar function, that can be syncronized with PC-
based calendar using "blinking screen". The CRT screen would blink, and the
watch had photodetector. I believe it was MS schedule+, so that got to be
patented already, although it might be close to patent expiration by now. This
was in the DOS days.
Sergey
2006\02\21@120924
by
Byron A Jeff
On Tue, Feb 21, 2006 at 03:35:25PM +0000, Sergey Dryga wrote:
{Quote hidden}> Ling SM <ipal11 <at> singnet.com.sg> writes:
>
> >
> > >>Blinking keyboard LEDs.
> > >>
> > >>Virtually every PC keyboard has LEDs which can be blinked
> > >>with some precision.
> > >>
> > >
> > > None of my Mac keyboards has blinkable LEDs...
> >
> > or CRT or LCD
> >
> > Ling SM
>
>
> There was a Timex watch with calendar function, that can be syncronized with PC-
> based calendar using "blinking screen". The CRT screen would blink, and the
> watch had photodetector. I believe it was MS schedule+, so that got to be
> patented already, although it might be close to patent expiration by now. This
> was in the DOS days.
That discussion occured in this thread a while ago. I believe the consensus was
that with the unknown update frquencies of today's LCD screens, that such a
system would by unreliable.
BAJ
2006\02\21@123348
by
M. Adam Davis
It wouldn't have to be if the photosensor was dumbed down enough to
approximate the human eye's response time.
Worst case you can send 10 bits per second. Given computer timing
issues you may want to limit it to that.
But you've also got the ability to do analog signaling. Four to 16
brightness levels should be achievable and sensable depending on the
transmission algorithm, sensing distance and error
detection/correction used. This gives 40 bits per second.
Lastly, you've got three colors. At minimum you could use one for
clock and one for data, and let the data go faster - have the unit
beep when it's getting too many errors, and the user can click "-" on
the computer to slow down the data rate.
At maximum you can use all three colors (three sensors) with a good
manchester algorithm, 16 levels of brightness on each, and little user
feedback to give up to 300 bits per second.
This could even be accomplished with a javascript program running in
the browser.
Given that USB is bit-bangable, and bluetooth is cheap, however, I
doubt such a system would be much more than an interesting side
project.
-Adam
On 2/21/06, Byron A Jeff <EraseMEbyronspam_OUTTakeThisOuTcc.gatech.edu> wrote:
> That discussion occured in this thread a while ago. I believe the consensus was
> that with the unknown update frquencies of today's LCD screens, that such a
> system would by unreliable.
2006\02\21@151514
by
Peter
On Mon, 20 Feb 2006, Wouter van Ooijen wrote:
> Recently there was a discussion that ended in a number of very
> convoluted ways to enter a program into a PIC. I think I have the idea
> about the ultimate convoluted bootloader: the non-electrical contacts
> bootloader. It uses temperature cycling to enter the data! The PIC uses
> its (temperature dependent) watchdog timeout to measure the temperature.
> Reset it at >100C and it enters the bootloader. 90..110 is the idle
> temperature, a temperature excursion above 120C is a 1, an excursion
> below 80C is a 0. I guess 160 millibaud (= one bit per minute) is easily
> done this way.
And the tool used to affect the heating is a magnifying glass, using the
sun as power source ;-)
Peter
2006\02\21@153843
by
Hazelwood Lyle
> > about the ultimate convoluted bootloader: the
> > non-electrical contacts
> > bootloader. It uses temperature cycling to enter the data!
> And the tool used to affect the heating is a magnifying
> glass, using the
> sun as power source ;-)
>
OK, I like the heating idea, but let's try to make our existing
tools more useful.
Some members here have hacked better temp controls into toaster
ovens for soldering work..
Would that oven now qualify as a "gang programmer"?
just shove a bunch of boards into the oven and download the
code into the oven controller..?
Maybe even write up procedures for doing field upgrades with
a propane torch and a stopwatch.
:-)
I like it, it passes the "suitably insane" criteria nicely.
Lyle
2006\02\21@160622
by
Peter
On Tue, 21 Feb 2006, Lindy Mayfield wrote:
> What about the rotating photons that were successfully used in quantum
> encryption? I heard that was actually done.
>
> Or is that different from the particles that are linked?
>
> I gotta read up on this stuff. I'm always fascinated how smart the Pic
> list people are. You guys know everything.
The encryption stuff relies on the paired (called annealed) photons.
Each pair is separated and sent through a different optical fiber, one
photon to A and one to B, where they create identical randum number
streams in their receivers. Then A uses the random number stream to code
and send data to B using a third fiber. Because no-one can duplicate the
random stream of photons the communication is secure.
Peter
2006\02\21@161536
by
Peter
On Tue, 21 Feb 2006, Byron A Jeff wrote:
> On Tue, Feb 21, 2006 at 05:03:51PM +1100, Jake Anderson wrote:
>> all optical programmers should be able to work from pretty much any
>> "blinking" source
>> if you are using the keyboar LED's then use 2 of them and do some kind of
>> SPI polled by the PIC
>
> I find optical crosstalk in my LEDs. When one lights, you can see some of
> the light through the others.
How about music ? R2D2 style multifrequency (or at least two-tone) ? 2 x
LM565 or similar should be able to decode this and it could be fairly
fast. Timing is ok too, one can do some fairly accurate timing relying
on the dsp sample rate. Good idea ?
Peter
2006\02\21@163642
by
Richard Prosser
This intorduces the possibility of whistling at it to update the code!
- unless you're tone deaf like me!
RP
> How about music ? R2D2 style multifrequency (or at least two-tone) ? 2 x
> LM565 or similar should be able to decode this and it could be fairly
> fast. Timing is ok too, one can do some fairly accurate timing relying
> on the dsp sample rate. Good idea ?
>
> Peter
> -
2006\02\21@165945
by
andrew kelley
Actually that is most likely very do-able because the sound card
better be able to reproduce any sound from 0 - 22 khz with 16 bit
accuracy.... Hrmmm.. Stereo channels.. Two DAC's.... seems easy enough
to be able program it using the audio channels.. use an op amp to
boost the levels to 0/5 and you should be good.. Just write a program
to output +32767 and -32767 on each channel..
andrew
> > How about music ? R2D2 style multifrequency (or at least two-tone) ? 2 x
> > LM565 or similar should be able to decode this and it could be fairly
> > fast. Timing is ok too, one can do some fairly accurate timing relying
> > on the dsp sample rate. Good idea ?
> >
> > Peter
2006\02\21@170705
by
William Killian
|
> -----Original Message-----
> From: piclist-bouncesspam_OUTmit.edu [@spam@piclist-bouncesKILLspammit.edu] On
Behalf
> Of Peter
> Sent: Tuesday, February 21, 2006 4:16 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC]: most convoluted way to enter a program into a PIC
>
[...]
> How about music ? R2D2 style multifrequency (or at least two-tone) ? 2
x
> LM565 or similar should be able to decode this and it could be fairly
> fast. Timing is ok too, one can do some fairly accurate timing relying
> on the dsp sample rate. Good idea ?
Shades of the old acoustic coupler modems that held the old fashioned
phone handsets.
Or the tone dialers of modern phones.
------------------------------------- Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
KILLspampostmasterKILLspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.
2006\02\21@171218
by
Maarten Hofman
Rochester, 21 februari 2006.
Hm... I still have several boxes of cassette tapes that were filled
with data in a similar manner... Some with Z80A and some with 6510
compatible code...
Greetings,
Maarten Hofman.
2006\02\21@184248
by
olin piclist
William Killian wrote:
>> LM565 or similar should be able to decode this and it could be fairly
>> fast. Timing is ok too, one can do some fairly accurate timing
>> relying
>> on the dsp sample rate. Good idea ?
>
> Shades of the old acoustic coupler modems that held the old fashioned
> phone handsets.
>
> Or the tone dialers of modern phones.
How about PC sound card output into a DTMF decoder chip. There should be
enough lines coming out one of those to find two that can be independently
wiggled.
******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC
consultant in 2004 program year. http://www.embedinc.com/products
2006\02\21@200708
by
Bob Axtell
Olin Lathrop wrote:
{Quote hidden}>William Killian wrote:
>
>
>>>LM565 or similar should be able to decode this and it could be fairly
>>>fast. Timing is ok too, one can do some fairly accurate timing
>>>relying
>>>on the dsp sample rate. Good idea ?
>>>
>>>
>>Shades of the old acoustic coupler modems that held the old fashioned
>>phone handsets.
>>
>>Or the tone dialers of modern phones.
>>
>>
>
>How about PC sound card output into a DTMF decoder chip. There should be
>enough lines coming out one of those to find two that can be independently
>wiggled.
>
>
>******************************************************************
>Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC
>consultant in 2004 program year.
http://www.embedinc.com/products
>
>
I like that. It would work easily.
I have sent robot control info as pulses ABOVE the power line feeding
the robot.
The robot expects to see say 80VDC on the cable, if I pulse it 2 volts
ABOVE 80
volts, the robot extracts it as information...
--
Note: To protect our network,
attachments must be sent to
RemoveMEattachTakeThisOuTengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer
2006\02\21@205729
by
Howard Winter
On Wed, 22 Feb 2006 10:36:34 +1300, Richard Prosser
wrote:
> This intorduces the possibility of whistling at it to
update the code!
> - unless you're tone deaf like me!
Easily solved - get it to decode DTMF tones, so you can
type in the code on the phone, holding the earpiece over
the PIC!
Cheers,
Howard Winter
St.Albans, England
2006\02\21@211736
by
Bob Axtell
Ok, Ok, how about double-use of the always present LED?
I read somewhere that few people know that visible LEDs
are also receivers of visible light; especially GREEN leds.
Simply connect it up to an amplifier and feed it into a PIC
pin. The light source can be almost anything, even a switched
incandescent lamp.
--Bob
--
Note: To protect our network,
attachments must be sent to
spamBeGoneattachspamBeGoneengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer
2006\02\21@215115
by
Jake Brownson
> Ok, Ok, how about double-use of the always present LED?
> I read somewhere that few people know that visible LEDs
> are also receivers of visible light; especially GREEN leds.
> Simply connect it up to an amplifier and feed it into a PIC
> pin. The light source can be almost anything, even a switched
> incandescent lamp.
I was just reading about this this morning, pretty neat looking.
http://www.merl.com/papers/docs/TR2003-35.pdf
~Jake B
2006\02\21@230225
by
Bob Axtell
Jake Brownson wrote:
>>Ok, Ok, how about double-use of the always present LED?
>>I read somewhere that few people know that visible LEDs
>>are also receivers of visible light; especially GREEN leds.
>>Simply connect it up to an amplifier and feed it into a PIC
>>pin. The light source can be almost anything, even a switched
>>incandescent lamp.
>>
>>
>
>I was just reading about this this morning, pretty neat looking.
>http://www.merl.com/papers/docs/TR2003-35.pdf
>
>~Jake B
>
>
>
Darn it, Jake... You beat us all.
This is a VERY good way to transfer data easily.
It could also make simple switches... two LEDs sit at a 30degree angle
of each other.
When a (reflective) finger passes in front, the other LED senses it. To
the casual
observer, it appears to be simply two LEDs providing indicators. They
are switched
on alternatively, so testing occurs all the time...
--
Note: To protect our network,
attachments must be sent to
TakeThisOuTattachEraseMEspam_OUTengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer
2006\02\22@042523
by
Alan B. Pearce
>OK, I like the heating idea, but let's try to make
>our existing tools more useful. Some members here
>have hacked better temp controls into toaster
>ovens for soldering work..
>Would that oven now qualify as a "gang programmer"?
>
>just shove a bunch of boards into the oven and
>download the code into the oven controller..?
Hey I like it - solder the chips in and program them in one operation ...
Now where is that patent attorney ...
2006\02\22@095835
by
Matthew Twomey
Why not just hook up a tiny mic and "clap it in"?
-Matt
{Quote hidden}> -----Original Message-----
> From:
RemoveMEpiclist-bouncesTakeThisOuTmit.edu [
piclist-bouncesEraseME.....mit.edu] On Behalf
> Of Richard Prosser
> Sent: Tuesday, February 21, 2006 3:37 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC]: most convoluted way to enter a program into a PIC
>
> This intorduces the possibility of whistling at it to update the code!
> - unless you're tone deaf like me!
>
> RP
>
> > How about music ? R2D2 style multifrequency (or at least two-tone) ? 2 x
> > LM565 or similar should be able to decode this and it could be fairly
> > fast. Timing is ok too, one can do some fairly accurate timing relying
> > on the dsp sample rate. Good idea ?
> >
> > Peter
> > --
2006\02\22@104413
by
Alan B. Pearce
>Why not just hook up a tiny mic and "clap it in"?
Using "Amen" for end of block markers ? ;))))
2006\02\22@105924
by
Wouter van Ooijen
> >Why not just hook up a tiny mic and "clap it in"?
>
> Using "Amen" for end of block markers ? ;))))
And say "AVR" to wipe the flash and erase the bootlader!
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
2006\02\22@111739
by
Sean Schouten
LOL!
2006\02\22@114128
by
David VanHorn
On 2/22/06, Wouter van Ooijen <EraseMEwoutervoti.nl> wrote:
>
> > >Why not just hook up a tiny mic and "clap it in"?
> >
> > Using "Amen" for end of block markers ? ;))))
>
> And say "AVR" to wipe the flash and erase the bootlader!
???
2006\02\22@120122
by
Juan Cubillo
Open your keyboard and paint the sides of the leds black.
Juan cubillo
-----Original Message-----
From: "Byron A Jeff"<RemoveMEbyronEraseMEEraseMEcc.gatech.edu>
Sent: 2/21/2006 8:23:02 AM
To: "Microcontroller discussion list - Public."<RemoveMEpiclistspam_OUTKILLspammit.edu>
Cc:
Subject: Re: [PIC]: most convoluted way to enter a program into a PIC
On Tue, Feb 21, 2006 at 05:03:51PM +1100, Jake Anderson wrote:
> all optical programmers should be able to work from pretty much any
> "blinking" source
> if you are using the keyboar LED's then use 2 of them and do some kind of
> SPI polled by the PIC
I find optical crosstalk in my LEDs. When one lights, you can see some of
the light through the others.
BAJ
2006\02\22@125241
by
William Couture
Hmmm... since a lot of projects have status LEDs connected to
the PICs pins, and LEDs can be used as light sensors, why not
have the status LED be the input to the bootloader?
Power up the chip and run a (self-clocking) "barcode" across the
LED to program it?
Bill
--
Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org
2006\02\22@132547
by
Steve Smith
>Power up the chip and run a (self-clocking) "barcode" across the
>LED to program it?
No this sounds like its going somewhere !!
It should read EAN codes and then it could be programmed while shopping
Beans
Beans
Soap powder
Toothpaste
Bacon (0.5kg)
This has the advantage that it can be done by the wife on a weekly basis
thus making shopping a useful task it would make for better time management
Steve..
{Original Message removed}
2006\02\22@133700
by
andrew kelley
Well, if you have the keyboard open, tack a few wires on and add
buffers and you have logic lines that can control whatever you wish...
andrew
On 2/22/06, Juan Cubillo <RemoveMEjacubilloroTakeThisOuTspamcostarricense.cr> wrote:
> Open your keyboard and paint the sides of the leds black.
> Juan cubillo
> {Original Message removed}
2006\02\22@143304
by
Byron A Jeff
On Wed, Feb 22, 2006 at 01:36:59PM -0500, andrew kelley wrote:
> Well, if you have the keyboard open, tack a few wires on and add
> buffers and you have logic lines that can control whatever you wish...
The whole point is not to open the keyboard. We're talking about a single
use bootloader dumper. Xioufan has pointed out a couple of bootloaders for
USB based PIC chips that work very well. The challenge is the bridge between
a completely empty chip and one with a bootloader. Presuming that bootloading
is your primary development method, as it is for me, then the bootloader
dumper serves as the required traditional programmer that up to now have
been served by Tait/JDM style programmers in the past.
It's an occasional use programmer.
BAJ
>
> andrew
>
> On 2/22/06, Juan Cubillo <EraseMEjacubillorospamspamBeGonecostarricense.cr> wrote:
> > Open your keyboard and paint the sides of the leds black.
> > Juan cubillo
> > {Original Message removed}
2006\02\22@150402
by
Peter
On Wed, 22 Feb 2006, Richard Prosser wrote:
> This intorduces the possibility of whistling at it to update the code!
> - unless you're tone deaf like me!
Hmm, whistle data and tap the rhythm (clock) (on the same mike) ? Or
clap ? This is fairly easy to do (in a way).
Peter
2006\02\22@151858
by
Spehro Pefhany
At 10:03 PM 2/22/2006 +0200, you wrote:
>On Wed, 22 Feb 2006, Richard Prosser wrote:
>
> > This intorduces the possibility of whistling at it to update the code!
> > - unless you're tone deaf like me!
>
>Hmm, whistle data and tap the rhythm (clock) (on the same mike) ? Or
>clap ? This is fairly easy to do (in a way).
Maybe a rolling ball sensor and you could do as the old-fashioned parents
did and "shake some sense" into the PIC (they did until it was found to
cause brain damage).
>Best regards,
Spehro Pefhany --"it's the network..." "The Journey is the reward"
RemoveMEspeffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff
2006\02\22@153957
by
Peter Todd
On Wed, Feb 22, 2006 at 10:03:59PM +0200, Peter wrote:
>
>
> On Wed, 22 Feb 2006, Richard Prosser wrote:
>
> > This intorduces the possibility of whistling at it to update the code!
> > - unless you're tone deaf like me!
>
> Hmm, whistle data and tap the rhythm (clock) (on the same mike) ? Or
> clap ? This is fairly easy to do (in a way).
And write a program that results in an easy to remember rhythm...
This reminds me of a really simple assembler I once saw back in the dos
days where every instruction was picked such that it was a valid
keyboard enterable character. So you were told to copy and paste this
set of code into a text editor, save it, and run that as a program. The
assembler could then assemble a more complete copy of itself from that.
Bootstrapping in software.
--
peteSTOPspamspam_OUTpetertodd.ca http://www.petertodd.ca
2006\02\22@154154
by
Peter
On Tue, 21 Feb 2006, Olin Lathrop wrote:
{Quote hidden}> William Killian wrote:
>>> LM565 or similar should be able to decode this and it could be fairly
>>> fast. Timing is ok too, one can do some fairly accurate timing
>>> relying
>>> on the dsp sample rate. Good idea ?
>>
>> Shades of the old acoustic coupler modems that held the old fashioned
>> phone handsets.
>>
>> Or the tone dialers of modern phones.
>
> How about PC sound card output into a DTMF decoder chip. There should be
> enough lines coming out one of those to find two that can be independently
> wiggled.
Hmm, good! MT8870 with strobe wired to clock and one output to data. And
acoustical phone coupler (programming is done remotely by calling a
1-800 number ...)
Peter
2006\02\22@215829
by
Gerhard Fiedler
|
Byron A Jeff wrote:
> On Wed, Feb 22, 2006 at 01:36:59PM -0500, andrew kelley wrote:
>> Well, if you have the keyboard open, tack a few wires on and add
>> buffers and you have logic lines that can control whatever you wish...
>
> The whole point is not to open the keyboard. [...] It's an occasional
> use programmer.
Well, yes, but a keyboard is less than $10. (At least for a PC, and whoever
has a Mac has the money to buy a real programmer from Olin -- just joking,
really :) An old keyboard practically classifies as "junkbox part". Raise
your hands who hasn't one......... don't see many hands up in the air :)
It could be a nice project to open the keyboard and put in a small
connector that supplies power and two logic signals to the rest of the
"occasional use programmer". Doesn't sound too un-DIY to me... you probably
could fit the whole programmer inside the keyboard, if you want to. Add a
keyboard switch to it, and you have the second keyboard on the bench that
you always wanted, with programmer built-in.
Gerhard
2006\02\23@032449
by
Chen Xiao Fan
> -----Original Message-----
> From: spamBeGonepiclist-bouncesSTOPspamEraseMEmit.edu
> [KILLspampiclist-bouncesspamBeGonemit.edu] On Behalf Of Byron A Jeff
>
> The whole point is not to open the keyboard. We're talking
> about a single use bootloader dumper. Xiaofan has pointed out
> a couple of bootloaders for USB based PIC chips that work
> very well. The challenge is the bridge between a completely
> empty chip and one with a bootloader. Presuming
> that bootloading is your primary development method, as
> it is for me, then the bootloader dumper serves as the
> required traditional programmer that up to now have
> been served by Tait/JDM style programmers in the past.
>
> It's an occasional use programmer.
>
The beauty of PIClist is that often the topics raised by the
original post are evolved into many different things. I will
say this is healthy. Still sometimes we need to go back to
read the original topics to if necessary...
Regards,
Xiaofan
2006\02\23@133941
by
Juan Cubillo
I do really like the flashing screen idea.
"sourcecode is not public, but just place your (optical) programmer facing the screen and click on program now"
hmmm...
for the hardware you only need 3 phototransistors , 3 transistors, 3 resistors, and a power supply with vpp, vcc, and gnd.
phototransistors control vpp, clock and data in.
Juan Cubillo
{Original Message removed}
2006\02\24@014352
by
Chen Xiao Fan
|
> From: EraseMEpiclist-bouncesEraseMEmit.edu
> On Behalf Of Byron A Jeff
>
> The whole point is not to open the keyboard. We're talking
> about a single use bootloader dumper. Xiaofan has pointed out
> a couple of bootloaders for USB based PIC chips that work
> very well. The challenge is the bridge between a completely
> empty chip and one with a bootloader. Presuming
> that bootloading is your primary development method, as
> it is for me, then the bootloader dumper serves as the
> required traditional programmer that up to now have
> been served by Tait/JDM style programmers in the past.
>
> It's an occasional use programmer.
By the way, now there are quite some bootloaders for PIC16F
and PIC18F. For PIC18F USB PICs, at least there are bootloaders
from Microchip PICDEM FS USB (vendor specific class) and PICkit 2
(HID class). Both bootloaders are supported under Windows and
Linux. I think other bootloaders can also be ported to the
18F USB PICs.
Even for dsPICs, there are some bootloaders available now.
1) ingenia dsPIC bootloader http://www.ingenia-cat.com
2) Tiny PIC Bootloader supports dsPIC
www.etc.ugal.ro/cchiculita/software/picbootloader.htm
3) Daniel Chia's dsPIC30F4011 bootloader
http://www.beaglerobotics.com/community
Therefore I think BAJ's effort to use the easily available
USB/Serial converter to develop a code dumper is useful.
By the way, I went out to some electronics shops here in
Singapore. I could find many USB/serial converters and
USB/parallel converters. However the USB/parallel
converters I found are all designed for the printer and
thus not using DB25.
Regards,
Xiaofan
2006\02\24@033554
by
Alan B. Pearce
>This reminds me of a really simple assembler I once
>saw back in the dos days where every instruction was
>picked such that it was a valid keyboard enterable
>character. So you were told to copy and paste this
>set of code into a text editor, save it, and run that
>as a program. The assembler could then assemble a
>more complete copy of itself from that.
Sounds like a way to make a secure downloader ...
2006\02\24@102326
by
Byron A Jeff
On Fri, Feb 24, 2006 at 02:43:49PM +0800, Chen Xiao Fan wrote:
{Quote hidden}>
> > From:
@spam@piclist-bounces@spam@spam_OUTmit.edu
> > On Behalf Of Byron A Jeff
> >
> > The whole point is not to open the keyboard. We're talking
> > about a single use bootloader dumper. Xiaofan has pointed out
> > a couple of bootloaders for USB based PIC chips that work
> > very well. The challenge is the bridge between a completely
> > empty chip and one with a bootloader. Presuming
> > that bootloading is your primary development method, as
> > it is for me, then the bootloader dumper serves as the
> > required traditional programmer that up to now have
> > been served by Tait/JDM style programmers in the past.
> >
> > It's an occasional use programmer.
>
> By the way, now there are quite some bootloaders for PIC16F
> and PIC18F. For PIC18F USB PICs, at least there are bootloaders
> from Microchip PICDEM FS USB (vendor specific class) and PICkit 2
> (HID class). Both bootloaders are supported under Windows and
> Linux. I think other bootloaders can also be ported to the
> 18F USB PICs.
Excellent. I'm still working on Yet Another Bootloader based on
Tato's 16F819 bootloader that supports some of the transparancy
and safety issues that I feel need to be addressed.
> Even for dsPICs, there are some bootloaders available now.
> 1) ingenia dsPIC bootloader http://www.ingenia-cat.com
> 2) Tiny PIC Bootloader supports dsPIC
> www.etc.ugal.ro/cchiculita/software/picbootloader.htm
> 3) Daniel Chia's dsPIC30F4011 bootloader
> http://www.beaglerobotics.com/community
Thanks for the list. I'll be saving this post. Do any of these
have open protocol specs? What about Linux based host loaders?
> Therefore I think BAJ's effort to use the easily available
> USB/Serial converter to develop a code dumper is useful.
I've detoured slightly in investigating using keyboard LEDs
as an interface. This would save the cost of the USB/serial
cable especially when programming a USB based PIC.
At the end of the day it's all just basic research to see if
a development basis can be established without having to
commit to an outside programmer.
I'm currently considering the suggestion of a couple of days
ago to actually crack open a keyboard and replace the LEDs
with wired electronics. It's somewhat interesting because it
would eliminate optical crosstalk issues and as that poster
pointed out, everyone has keyboards in their junk box.
In all of this the only problem I see is the transparancy
issue for the bootloader. If the focus is a USB part, then
to be effective the bootloader would have to share the USB
interface with the application. If USB isn't used, or the
PIC doesn't have USB, then some external component, like a
USB to serial cable, would still be needed to interface to
the bootloader.
>
> By the way, I went out to some electronics shops here in
> Singapore. I could find many USB/serial converters and
> USB/parallel converters. However the USB/parallel
> converters I found are all designed for the printer and
> thus not using DB25.
Bingo. I've seen a few on Ebay and pricewatch that had the
DB25 on the end. It's unclear if the driver can be used as a
bidirectional bit twiddler.
BAJ
2006\02\24@120753
by
Gerhard Fiedler
|
|
Byron A Jeff wrote:
> I'm currently considering the suggestion of a couple of days ago to
> actually crack open a keyboard and replace the LEDs with wired
> electronics. It's somewhat interesting because it would eliminate
> optical crosstalk issues and as that poster pointed out, everyone has
> keyboards in their junk box.
>
> In all of this the only problem I see is the transparancy issue for the
> bootloader. If the focus is a USB part, then to be effective the
> bootloader would have to share the USB interface with the application.
> If USB isn't used, or the PIC doesn't have USB, then some external
> component, like a USB to serial cable, would still be needed to
> interface to the bootloader.
I'm not sure this leads somewhere, but once you open a keyboard (none of
the keyboards I've owned needed to be cracked, BTW, all had nice screws)
you basically can go bidirectional. May not fit the bill for a bootloader,
but you can trigger characters probably fairly easily.
Gerhard
2006\02\24@184011
by
Xiaofan Chen
More... (looser matching)
- Last day of these posts
- In 2006
, 2007 only
- Today
- New search...
