Converting digital to analog

Started by August 2, 2007
Hi,i'm having problems writing my code to convert digital to analog
values. I am dealing with assembly programming with the 68HC11. I am
trying to read from the output of the temperature sensor (LM34) and
not from the amplifier. the program is written to display the range
of temp. from 0 to 210 degrees fahrenheit and not 0 - FFF on the
segment display. I am getting the 0-FFF range but not the 0-210. I
know it has something to do with the idiv and mul instruction but i
before friday. The calculations are as follows:

Using VS = 6V
I wanted to convert the output voltage of the op-amp to have a range
from 0 5V. In order to do this, I chose appropriate values for Rf
and R1.
The formulae used are as follows:
Vo = 1 + Rf / R1 x Vx
AV = Rf / R1 + 1
Because I want the highest i.e 210oF, 2100mV was used since,
according to the LM34 temperature sensor specifications, 300oF is
equivalent to 3000mV.

5V = AV x 2100mV
AV = 5V/2100mV = 2.38

With the gain, I calculated the Rf and R1 to be 3kohm and 2.2kohm
respectively.

Is it possible you can write the code for that for me. I don't want
the remainder, just the integer part alone. I tried everything, i
also have to use the formula in the code: Vx = Vlref + (range *x) /
(2 power n - 1)

Here's the code:

Project: To design a digital thermometer so that it can measure
temperature
* in the range from 0oF to 210oF

org \$7021
seven_segment rmb 4
base equ \$1000
portb equ \$04
ddrd equ \$09
portd equ \$08
porte equ \$0A
option equ \$39
F equ \$F1 ; bit pattern to display
;the character degrees fahrenheit
temp rmb 3

org \$F000
lds #\$FF

; to enable the seven_segment display

start ldaa #\$FF
ldx #base
staa ddrd,x

; to display the character degrees fahrenheit

here ldaa #F
staa portb,x
ldaa #\$FB ; bit pattern to enable dig0
staa portd,x
jsr delaya
; to turn on the A/D converter
bset option,x \$80 ;enable the charge pump to start A/D conv.
bclr option,x \$40 ;select E clock as the clock source
ldy #30 ;delay for 105us
delay dey
bne delay

; initiate conversion
ldaa #\$01

; wait for ccf

repeat ldaa adctl,x ; check the CCF bit
bpl repeat ;wait until CCF is 1
ldaa adr2,x ; get the first result
anda #\$0F
staa temp ; save it
; display number in the second segment display
jsr seven_segment
staa portb,x
ldaa #\$F7
staa portd,x
jsr delaya
; get the result
lsra
lsra
lsra
lsra

anda #\$0F
staa temp +1
; display the result in the third seven segment
jsr seven_segment
staa portb,x
ldaa #\$EF
staa portd,x
jsr delaya
lsra
lsra
lsra
lsra
anda #\$0F
staa temp +2
; display the result in the fourth seven segment
jsr seven_segment
staa portb,x
ldaa #\$DF
staa portd,x
jsr delaya
jmp here

delaya pshx
ldx #\$0001
again ldy #\$00FC
nop
loop dey
bne loop
dex
pulx
bne again
rts
Just a quick thought - are the sensor characteristics linear/logarithmic - in other words predictable?

Sometimes the characteristic curves are anything but linear, and you have to add formulae to deal with those changes.

Good luck.

----- Original Message -----
From: chryssie0312
To: m...
Sent: Thursday, August 02, 2007 11:34 AM
Subject: [m68HC11] Converting digital to analog
Hi,i'm having problems writing my code to convert digital to analog
values. I am dealing with assembly programming with the 68HC11. I am
trying to read from the output of the temperature sensor (LM34) and
not from the amplifier. the program is written to display the range
of temp. from 0 to 210 degrees fahrenheit and not 0 - FFF on the
segment display. I am getting the 0-FFF range but not the 0-210. I
know it has something to do with the idiv and mul instruction but i
before friday. The calculations are as follows:

Using VS = 6V
I wanted to convert the output voltage of the op-amp to have a range
from 0 - 5V. In order to do this, I chose appropriate values for Rf
and R1.
The formulae used are as follows:
Vo = 1 + Rf / R1 x Vx
AV = Rf / R1 + 1
Because I want the highest i.e 210oF, 2100mV was used since,
according to the LM34 temperature sensor specifications, 300oF is
equivalent to 3000mV.

5V = AV x 2100mV
AV = 5V/2100mV = 2.38

With the gain, I calculated the Rf and R1 to be 3kohm and 2.2kohm
respectively.

Is it possible you can write the code for that for me. I don't want
the remainder, just the integer part alone. I tried everything, i
also have to use the formula in the code: Vx = Vlref + (range *x) /
(2 power n - 1)

Here's the code:

Project: To design a digital thermometer so that it can measure
temperature
* in the range from 0oF to 210oF

org \$7021
seven_segment rmb 4
base equ \$1000
portb equ \$04
ddrd equ \$09
portd equ \$08
porte equ \$0A
option equ \$39

F equ \$F1 ; bit pattern to display
;the character degrees fahrenheit
temp rmb 3

org \$F000
lds #\$FF

; to enable the seven_segment display

start ldaa #\$FF
ldx #base
staa ddrd,x

; to display the character degrees fahrenheit

here ldaa #F
staa portb,x
ldaa #\$FB ; bit pattern to enable dig0
staa portd,x
jsr delaya

; to turn on the A/D converter
bset option,x \$80 ;enable the charge pump to start A/D conv.
bclr option,x \$40 ;select E clock as the clock source
ldy #30 ;delay for 105us
delay dey
bne delay

; initiate conversion
ldaa #\$01

; wait for ccf

repeat ldaa adctl,x ; check the CCF bit
bpl repeat ;wait until CCF is 1
ldaa adr2,x ; get the first result
anda #\$0F
staa temp ; save it
; display number in the second segment display
jsr seven_segment
staa portb,x
ldaa #\$F7
staa portd,x
jsr delaya
; get the result
lsra
lsra
lsra
lsra

anda #\$0F
staa temp +1
; display the result in the third seven segment
jsr seven_segment
staa portb,x
ldaa #\$EF
staa portd,x
jsr delaya

lsra
lsra
lsra
lsra
anda #\$0F
staa temp +2
; display the result in the fourth seven segment
jsr seven_segment
staa portb,x
ldaa #\$DF
staa portd,x
jsr delaya
jmp here

delaya pshx
ldx #\$0001
again ldy #\$00FC
nop
loop dey
bne loop
dex
pulx
bne again
rts
chryssie0312 wrote:
> Hi,i'm having problems writing my code to convert digital to analog

Actually, it looks like you are trying to display the output
of the A/D converter on the chip, not a D/A conversion.

> values. I am dealing with assembly programming with the 68HC11. I am
> trying to read from the output of the temperature sensor (LM34) and

I am familiar with that chip. It puts out 10 mV / degree F. I've used
it myself.

> not from the amplifier. the program is written to display the range
> of temp. from 0 to 210 degrees fahrenheit and not 0 - FFF on the
> segment display. I am getting the 0-FFF range but not the 0-210. I

Do you mean that you are getting accurate readings? At 210 degrees F
that chip puts out 2.1 VDC. This converts to a reading of \$6C. The
A/D puts out a one-byte reading. \$FFF is not possible. Are you
multiplying after you read or something?

> know it has something to do with the idiv and mul instruction but i
> before friday. The calculations are as follows:
>
> Using VS = 6V
> I wanted to convert the output voltage of the op-amp to have a range
> from 0 5V. In order to do this, I chose appropriate values for Rf
> and R1.
> The formulae used are as follows:
> Vo = 1 + Rf / R1 x Vx
> AV = Rf / R1 + 1

This sounds like a standard non-inverting op amp signal conditioner.

> Because I want the highest i.e 210oF, 2100mV was used since,
> according to the LM34 temperature sensor specifications, 300oF is
> equivalent to 3000mV.
>
> 5V = AV x 2100mV
> AV = 5V/2100mV = 2.38
>
> With the gain, I calculated the Rf and R1 to be 3kohm and 2.2kohm
> respectively.

Ok, lessee. What accuracy resistors did you use? Anyway, supposing you
use accurate resistors, your gain is 2.3636363... so 2.1V in gives
4.964 volts out. You should get 254 out of the A/D converter, which
is \$FF, not \$FFF as you stated.

> Is it possible you can write the code for that for me. I don't want

Yes, it is possible. No, I will not do it. You paid good money
to go to school, and you should derive benefit from that. I will,
however, point out where you seem to be making mistakes, and help
you figure it out on your own.

Where you are having difficulty seems to be conversion of the
internal number into an external numeral.

> the remainder, just the integer part alone. I tried everything, i

Obviously, you have not tried everything, because you haven't
tried what works. Thinking like this is going to lead to defeatism.
There is something you haven't tried, you just need to figure
out what it is.

> also have to use the formula in the code: Vx = Vlref + (range *x) /
> (2 power n - 1)
>
> Here's the code:
>
> Project: To design a digital thermometer so that it can measure
> temperature
> * in the range from 0oF to 210oF
>
> org \$7021

I take it you have RAM here.

> seven_segment rmb 4
> base equ \$1000
> portb equ \$04
> ddrd equ \$09
> portd equ \$08
> porte equ \$0A
> option equ \$39
> F equ \$F1 ; bit pattern to display
> ;the character degrees fahrenheit

I don't understand the reason for this equate,
and the comment isn't adequate for me to figure
it out. Is this a "pretend sample" of 241? If so,
then it represents a voltage of 1.99V which you'd
get at a temperature of 199 degrees F. So, this
needs to be displayed as 199.

> temp rmb 3
>
> org \$F000

I hope you have some RAM here, too.

> lds #\$FF

Good idea to set up your stack.

> ; to enable the seven_segment display
>
> start ldaa #\$FF
> ldx #base
> staa ddrd,x

Ok, so PORTA is being used as output. I hope this is
an F series chip, or the like. Some of those chips
have fixed direction port bits on PORTA.

[snipped]

> ; wait for ccf
>
> repeat ldaa adctl,x ; check the CCF bit
> bpl repeat ;wait until CCF is 1
> ldaa adr2,x ; get the first result
> anda #\$0F
> staa temp ; save it

Ok, low nybble.

> ; display number in the second segment display
> jsr seven_segment

Not going to work, even if the subroutine is
correct. You want a decimal numeral, not a

> staa portb,x
> ldaa #\$F7
> staa portd,x

What does this do?

> jsr delaya
> ; get the result
> lsra
> lsra
> lsra
> lsra
>
> anda #\$0F
> staa temp +1
> ; display the result in the third seven segment
> jsr seven_segment
> staa portb,x
> ldaa #\$EF
> staa portd,x
> jsr delaya

I can't figure this code out. Anyway, I'm going
to guess that you are able to display three digits
using this code, but that you are getting hex numerals,
not decimal. So, I've snipped it.

This code gives the appearance that it does a correct
conversion from an internal format integer to an external
carefully. When you mask the low order bits, and retain
them, you are taking the remainder after division by 16.
Then, later in your code, you shift the value right by
four bits. This is the same as division by 16. This forms
the core to your system to convert numbers to numerals.

If you want DECIMAL numerals, you must use remainders
after division by 10, not 16. FDIV divides fractional
fixed point numbers by integers. IDIV divides integral
fixed point numbers by integers. So, IDIV is the one you
want.

That's the first problem you've got. The other one is
that you are displaying internal codes, not temperatures.
IOW, you have an internal value of 241. This should be
displayed as 199.

So, here are the steps your code needs to perform.

(1) Convert the internal code into a number representing
the actual temperature by rescaling.

(2) convert the numerical temperature into an external
numeral by dividing by 10 repeatedly, and displaying
the remainders, using IDIV.

For example, you need to display 199 = \$C7. Divide
\$C7 by \$0A to get \$13 as the quotient and remainder
of \$09. Display a digit '9' as the least significant
digit. Then divide \$13 by \$0A to get a quotient of \$01
and a remainder of 9. Display the digit '9' as the
next more significant digit. Then display the quotient
\$01 (which is also the remainder after the next division)
as the most significant digit '1'.

Now, how to rescale? You multiply your voltage by
2.363636..., divide by 5.000V, then multiply by 256,
and round to the nearest integer. That's what we get
out of the A/D. We need to reverse this. So, we
divide by 256, multiply by 5, and divide by 2.3636...
This gives us the original voltage.

But, we need to multiply this number by 100 in order
to get temperature, to account for the 10 mV/oF relation.
Net result: We need to multiply by 0.826322115...
That makes a reading of 241 from the A/D come out as 199.14
as we want, since it corresponds to 199 degrees F.

So, how do we multiply by 0.826322115...? We can do this
with reasonable accuracy by multiplying by 212 and dividing
by 256, because 212/256 = 0.828125. The error is 0.2%, and
we've already committed greater error (0.5% roughly) by
A/D conversion.

So, take your A/D result, multiply by 212, round off by
adding \$0080 (1/2 of 256) and divide by 256 by using only the
upper 8 bits (in A). Then convert to decimal digits by
repeated division by 10 using IDIV and the remainders.
These are what you display.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
What an extremely cool and detailed answer Mike - kudos to you. :)

I'm just observing by the way, the answer doesn't interest me.

----- Original Message -----
From: "Mike McCarty"
To:
Sent: Thursday, August 02, 2007 7:16 PM
Subject: Re: [m68HC11] Converting digital to analog
> chryssie0312 wrote:
>> Hi,i'm having problems writing my code to convert digital to analog
>
> Actually, it looks like you are trying to display the output
> of the A/D converter on the chip, not a D/A conversion.
>
>> values. I am dealing with assembly programming with the 68HC11. I am
>> trying to read from the output of the temperature sensor (LM34) and
>
> I am familiar with that chip. It puts out 10 mV / degree F. I've used
> it myself.
>
>> not from the amplifier. the program is written to display the range
>> of temp. from 0 to 210 degrees fahrenheit and not 0 - FFF on the
>> segment display. I am getting the 0-FFF range but not the 0-210. I
>
> Do you mean that you are getting accurate readings? At 210 degrees F
> that chip puts out 2.1 VDC. This converts to a reading of \$6C. The
> A/D puts out a one-byte reading. \$FFF is not possible. Are you
> multiplying after you read or something?
>
>> know it has something to do with the idiv and mul instruction but i
>> before friday. The calculations are as follows:
>>
>> Using VS = 6V
>> I wanted to convert the output voltage of the op-amp to have a range
>> from 0 5V. In order to do this, I chose appropriate values for Rf
>> and R1.
>> The formulae used are as follows:
>> Vo = 1 + Rf / R1 x Vx
>> AV = Rf / R1 + 1
>
> This sounds like a standard non-inverting op amp signal conditioner.
>
>> Because I want the highest i.e 210oF, 2100mV was used since,
>> according to the LM34 temperature sensor specifications, 300oF is
>> equivalent to 3000mV.
>>
>> 5V = AV x 2100mV
>> AV = 5V/2100mV = 2.38
>>
>> With the gain, I calculated the Rf and R1 to be 3kohm and 2.2kohm
>> respectively.
>
> Ok, lessee. What accuracy resistors did you use? Anyway, supposing you
> use accurate resistors, your gain is 2.3636363... so 2.1V in gives
> 4.964 volts out. You should get 254 out of the A/D converter, which
> is \$FF, not \$FFF as you stated.
>
>> Is it possible you can write the code for that for me. I don't want
>
> Yes, it is possible. No, I will not do it. You paid good money
> to go to school, and you should derive benefit from that. I will,
> however, point out where you seem to be making mistakes, and help
> you figure it out on your own.
>
>
> Where you are having difficulty seems to be conversion of the
> internal number into an external numeral.
>
>> the remainder, just the integer part alone. I tried everything, i
>
> Obviously, you have not tried everything, because you haven't
> tried what works. Thinking like this is going to lead to defeatism.
> There is something you haven't tried, you just need to figure
> out what it is.
>
>> also have to use the formula in the code: Vx = Vlref + (range *x) /
>> (2 power n - 1)
>>
>> Here's the code:
>>
>> Project: To design a digital thermometer so that it can measure
>> temperature
>> * in the range from 0oF to 210oF
>>
>> org \$7021
>
> I take it you have RAM here.
>
>> seven_segment rmb 4
>> base equ \$1000
>> portb equ \$04
>> ddrd equ \$09
>> portd equ \$08
>> porte equ \$0A
>> option equ \$39
>> F equ \$F1 ; bit pattern to display
>> ;the character degrees fahrenheit
>
> I don't understand the reason for this equate,
> and the comment isn't adequate for me to figure
> it out. Is this a "pretend sample" of 241? If so,
> then it represents a voltage of 1.99V which you'd
> get at a temperature of 199 degrees F. So, this
> needs to be displayed as 199.
>
>> temp rmb 3
>>
>> org \$F000
>
> I hope you have some RAM here, too.
>
>> lds #\$FF
>
> Good idea to set up your stack.
>
>> ; to enable the seven_segment display
>>
>> start ldaa #\$FF
>> ldx #base
>> staa ddrd,x
>
> Ok, so PORTA is being used as output. I hope this is
> an F series chip, or the like. Some of those chips
> have fixed direction port bits on PORTA.
>
> [snipped]
>
>> ; wait for ccf
>>
>> repeat ldaa adctl,x ; check the CCF bit
>> bpl repeat ;wait until CCF is 1
>> ldaa adr2,x ; get the first result
>> anda #\$0F
>> staa temp ; save it
>
> Ok, low nybble.
>
>> ; display number in the second segment display
>> jsr seven_segment
>
> Not going to work, even if the subroutine is
> correct. You want a decimal numeral, not a
>
>> staa portb,x
>> ldaa #\$F7
>> staa portd,x
>
> What does this do?
>
>> jsr delaya
>> ; get the result
>> lsra
>> lsra
>> lsra
>> lsra
>>
>> anda #\$0F
>> staa temp +1
>> ; display the result in the third seven segment
>> jsr seven_segment
>> staa portb,x
>> ldaa #\$EF
>> staa portd,x
>> jsr delaya
>
> I can't figure this code out. Anyway, I'm going
> to guess that you are able to display three digits
> using this code, but that you are getting hex numerals,
> not decimal. So, I've snipped it.
>
> This code gives the appearance that it does a correct
> conversion from an internal format integer to an external
> carefully. When you mask the low order bits, and retain
> them, you are taking the remainder after division by 16.
> Then, later in your code, you shift the value right by
> four bits. This is the same as division by 16. This forms
> the core to your system to convert numbers to numerals.
>
> If you want DECIMAL numerals, you must use remainders
> after division by 10, not 16. FDIV divides fractional
> fixed point numbers by integers. IDIV divides integral
> fixed point numbers by integers. So, IDIV is the one you
> want.
>
> That's the first problem you've got. The other one is
> that you are displaying internal codes, not temperatures.
> IOW, you have an internal value of 241. This should be
> displayed as 199.
>
> So, here are the steps your code needs to perform.
>
> (1) Convert the internal code into a number representing
> the actual temperature by rescaling.
>
> (2) convert the numerical temperature into an external
> numeral by dividing by 10 repeatedly, and displaying
> the remainders, using IDIV.
>
> For example, you need to display 199 = \$C7. Divide
> \$C7 by \$0A to get \$13 as the quotient and remainder
> of \$09. Display a digit '9' as the least significant
> digit. Then divide \$13 by \$0A to get a quotient of \$01
> and a remainder of 9. Display the digit '9' as the
> next more significant digit. Then display the quotient
> \$01 (which is also the remainder after the next division)
> as the most significant digit '1'.
>
> Now, how to rescale? You multiply your voltage by
> 2.363636..., divide by 5.000V, then multiply by 256,
> and round to the nearest integer. That's what we get
> out of the A/D. We need to reverse this. So, we
> divide by 256, multiply by 5, and divide by 2.3636...
> This gives us the original voltage.
>
> But, we need to multiply this number by 100 in order
> to get temperature, to account for the 10 mV/oF relation.
> Net result: We need to multiply by 0.826322115...
> That makes a reading of 241 from the A/D come out as 199.14
> as we want, since it corresponds to 199 degrees F.
>
> So, how do we multiply by 0.826322115...? We can do this
> with reasonable accuracy by multiplying by 212 and dividing
> by 256, because 212/256 = 0.828125. The error is 0.2%, and
> we've already committed greater error (0.5% roughly) by
> A/D conversion.
>
> So, take your A/D result, multiply by 212, round off by
> adding \$0080 (1/2 of 256) and divide by 256 by using only the
> upper 8 bits (in A). Then convert to decimal digits by
> repeated division by 10 using IDIV and the remainders.
> These are what you display.
>
> Mike
> --
> p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> Oppose globalization and One World Governments like the UN.
> This message made from 100% recycled bits.
> You have found the bank of Larn.
> I can explain it for you, but I can't understand it for you.
> I speak only for myself, and I am unanimous in that!
tj wrote:
> What an extremely cool and detailed answer Mike - kudos to you. :)

Thanks. The trick is, of course, to give enough detail to
point the way, without giving out the answer. I may have gone
too far in actually pointing out what the factor is (0.826)
and how to multiply by it.

> I'm just observing by the way, the answer doesn't interest me.

Well, it's obviously a class project. But, it's also a very
realistic kind of thing. Many embedded applications are just
this sort of thing. It's obviously not an entire device,
because a uC is overkill for just a thermometer. But scaling
and using values from external sensors is very much a part
of most embedded devices, and conversion to external display
format is usually important somewhere along the line, even
in something like a microwave or automotive or industrial
controller. So, while it's not particularly interesting in
and of itself, it is very much the kind of thing that has
to be done in real life.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Yes, I can see you were cautious aboutjust flatly giving the answer, and
that's okay, people don't learn like that.

Tell me, is there any point in using the 68HC11 - I got the impression it
was obsolete or hard to come by?
----- Original Message -----
From: "Mike McCarty"
To:
Sent: Thursday, August 02, 2007 9:27 PM
Subject: Re: [m68HC11] Converting digital to analog
> tj wrote:
>> What an extremely cool and detailed answer Mike - kudos to you. :)
>
> Thanks. The trick is, of course, to give enough detail to
> point the way, without giving out the answer. I may have gone
> too far in actually pointing out what the factor is (0.826)
> and how to multiply by it.
>
>> I'm just observing by the way, the answer doesn't interest me.
>
> Well, it's obviously a class project. But, it's also a very
> realistic kind of thing. Many embedded applications are just
> this sort of thing. It's obviously not an entire device,
> because a uC is overkill for just a thermometer. But scaling
> and using values from external sensors is very much a part
> of most embedded devices, and conversion to external display
> format is usually important somewhere along the line, even
> in something like a microwave or automotive or industrial
> controller. So, while it's not particularly interesting in
> and of itself, it is very much the kind of thing that has
> to be done in real life.
>
> Mike
> --
> p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> Oppose globalization and One World Governments like the UN.
> This message made from 100% recycled bits.
> You have found the bank of Larn.
> I can explain it for you, but I can't understand it for you.
> I speak only for myself, and I am unanimous in that!
tj wrote:
> Yes, I can see you were cautious aboutjust flatly giving the answer, and
> that's okay, people don't learn like that.
>
> Tell me, is there any point in using the 68HC11 - I got the impression it
> was obsolete or hard to come by?

AFAIK they are in full production, but Freescale is not pushing
them for new designs. They want to sell lots of '12s. I use them
for personal projects because I have quite a few on hand, like
a hundred or so, and several, like a few tens, with BUFFALO in
the ROM.

As far as "hard to come by", even when they were the pushed item
by Motorola, they were hard to come by in small quantity. They were
used by the 10,000 in automobiles, and that's where most of them
two or three.

I came across a bunch of the A series being thrown away at a place where
I worked, and grabbed them up several years ago, when a board was
discontinued. I also grabbed a few tubes of sockets. I've also
got a few F series, but never have actually put together a circuit
using them.

The '12 is harder to use than the '11 because of physical mounting
issues. The '11Ax in the 52 pin package is great for hand construction.
The '12 has close pin spacing, and no sockets AFAIK.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Mike McCarty wrote:

> > Tell me, is there any point in using the 68HC11 - I got the impression it
> > was obsolete or hard to come by?
>
> AFAIK they are in full production, but Freescale is not pushing
> them for new designs. They want to sell lots of '12s. I use them

automotive applications.

Coldfire is the way to go, much more computing power for the same
money.

> for personal projects because I have quite a few on hand, like
> a hundred or so, and several, like a few tens, with BUFFALO in
> the ROM.
>
> As far as "hard to come by", even when they were the pushed item
> by Motorola, they were hard to come by in small quantity. They were
> used by the 10,000 in automobiles, and that's where most of them
> two or three.

Ack, and still true for other Freescale controllers. If you want
"easy to get" parts, look for Atmel ARM7, e.g. AT91SAM7X128.

[...]

> The '12 is harder to use than the '11 because of physical mounting
> issues. The '11Ax in the 52 pin package is great for hand construction.
> The '12 has close pin spacing, and no sockets AFAIK.

No problem to solder even 0,5mm pitch by hand.

Oliver
--
Oliver Betz, Muenchen
Oliver Betz wrote:
> Mike McCarty wrote:
>

[snip]

>
>>The '12 is harder to use than the '11 because of physical mounting
>>issues. The '11Ax in the 52 pin package is great for hand construction.
>>The '12 has close pin spacing, and no sockets AFAIK.
> No problem to solder even 0,5mm pitch by hand.

Umm, you aren't the same age I am, I trow. My eyesight isn't what
it was. Also, you didn't contradict anything I said. It is harder.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Mike McCarty wrote:

[...]

> >>The '12 is harder to use than the '11 because of physical mounting
> >>issues. The '11Ax in the 52 pin package is great for hand construction.
> >>The '12 has close pin spacing, and no sockets AFAIK.
> >
> > No problem to solder even 0,5mm pitch by hand.
>
> Umm, you aren't the same age I am, I trow. My eyesight isn't what

Uptime is approx. 380000h, and my arms also become too short . I
_love_ our Mantis stereo microscope.

> it was. Also, you didn't contradict anything I said. It is harder.

Ack. But with a bit of flux and the appropriate tip, it's acceptable.

And a QFP100 with 0,5mm pitch is so neat compared to PLCC.

Really evil are those packages with hidden solder pads like QFN or
BGAs. Gladly I could avoid them.

Oliver
--
Oliver Betz, Muenchen