27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

HI

I'm currently writing a program for the 68hc11 on my Thrism11
simulator. The program uses the irq interrupt.

What I don't understand is how you can edit the interrupt vector when
it is in the ROM? I thought ROM could only be configured in the
factory.
For example, here is my code for the first part of the program:

STACK EQU $00FF
PROGRAM EQU $FF00
IRQ EQU $FFF2
DDRC EQU $07
REGBAS EQU $1000
PORTC EQU $03
MEMORY EQU $04
PORTD EQU $08

*************************************************
* SETUP *
*************************************************

ORG IRQ
FDB IRQHERE

ORG PROGRAM
*MAIN PROGRAM
START SEI ;MASK IRQ
LDS #STACK ;SETUP STACK POINTER
LDX #REGBAS ;SET REGISTER BASE
LDAA #$03 ;LOAD A WITH 01 FOR PORT C SETUP

STAA DDRC,X ;SET PC0 AND PC1 AS OUTPUT AND PC2-
PC7 AS INPUTS
LDAA PORTC,X
ANDA #$80
STAA PORTC,X ;CLEAR PORT C
LDAA #$00 ;LOAD A WITH 00 TO RESET MEMORY
STAA MEMORY,X ;CLEAR MEMORY
CLI ;CLEAR INTERRUPT MASK

*************************************************
* MAIN PROGRAM *
*************************************************

LOOP BRA LOOP ;WAIT HERE FOR DEBOUNCED IRQ SIGNAL

**************************************************
* IRQ Request *
**************************************************

IRQHERE LDAA MEMORY,X ;LOAD ACCUMULATOR A WITH THE MEMORY D
Now, when I assemble this the irq address of $fff2 contains the hex
$ff16. This differs from the default which was $ffff.

The reason I ask this is because I want to transfer this program to a
real chip and run the program in EEPROM, but I'm not sure if the
interrupt vector will work.

In summary, can you change the contents of $fff2 in real life, or is
this only something you can do at the factory and in a simulator.

Any help appreciated.

Thank you

Nathan


______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

I am not familiar with the Thrism11 simulator. Generally speaking, with a
real 68HC11, you can put the hc11 in expanded-multiplexed mode and then use
an external device like your eeprom for your interrupt vectors and program
memory. The exceptions to this are certain items on-chip which if enabled
would take precedent for the addresses they occupy i.e. registers, eeprom, ram.

At 06:05 AM 7/7/2005 +0000, you wrote:
>HI
>
>I'm currently writing a program for the 68hc11 on my Thrism11
>simulator. The program uses the irq interrupt.
>
>What I don't understand is how you can edit the interrupt vector when
>it is in the ROM? I thought ROM could only be configured in the
>factory. >
>For example, here is my code for the first part of the program:
>
>STACK EQU $00FF
>PROGRAM EQU $FF00
>IRQ EQU $FFF2
>DDRC EQU $07
>REGBAS EQU $1000
>PORTC EQU $03
>MEMORY EQU $04
>PORTD EQU $08
>
>*************************************************
>* SETUP *
>*************************************************
>
> ORG IRQ
> FDB IRQHERE
>
> ORG PROGRAM
>*MAIN PROGRAM
>START SEI ;MASK IRQ
> LDS #STACK ;SETUP STACK POINTER
> LDX #REGBAS ;SET REGISTER BASE
> LDAA #$03 ;LOAD A WITH 01 FOR PORT C SETUP
>
> STAA DDRC,X ;SET PC0 AND PC1 AS OUTPUT AND PC2-
>PC7 AS INPUTS
> LDAA PORTC,X
> ANDA #$80
> STAA PORTC,X ;CLEAR PORT C
> LDAA #$00 ;LOAD A WITH 00 TO RESET MEMORY
> STAA MEMORY,X ;CLEAR MEMORY
> CLI ;CLEAR INTERRUPT MASK
>
>*************************************************
>* MAIN PROGRAM *
>*************************************************
>
>LOOP BRA LOOP ;WAIT HERE FOR DEBOUNCED IRQ SIGNAL
>
>**************************************************
>* IRQ Request *
>**************************************************
>
>IRQHERE LDAA MEMORY,X ;LOAD ACCUMULATOR A WITH THE MEMORY D >
>Now, when I assemble this the irq address of $fff2 contains the hex
>$ff16. This differs from the default which was $ffff.
>
>The reason I ask this is because I want to transfer this program to a
>real chip and run the program in EEPROM, but I'm not sure if the
>interrupt vector will work.
>
>In summary, can you change the contents of $fff2 in real life, or is
>this only something you can do at the factory and in a simulator.
>
>Any help appreciated.
>
>Thank you
>
>Nathan >Yahoo! Groups Links



______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Thu, 2005-07-07 at 06:05 +0000, nathan_b_a wrote:
> What I don't understand is how you can edit the interrupt vector when
> it is in the ROM? I thought ROM could only be configured in the
> factory.

The answer to this is perhaps circuitous - the interrupt vector is
actually part of the program itself. If you have a ROM-based MCU, then
not only is the IRQ vector in ROM, but so is the program itself! They
are inseparable.

So - where is your program? If it is in RAM, then the *same*
mechanism which you use to place and start the program, is used to set
the IRQ vector. You see the *START* (reset) vector is adjacent to the
IRQ vector, so both are defined in the same manner.

If you are running a bootstrap or "monitor" - which is in ROM, then it
generally pre-sets the IRQ vector to jump to a RAM location which it
initialises to a default, but which you can re-allocate in the same
action as you load program code to be executed.

So, if you understand what your system is doing in general, the answer
will follow.

--
Cheers,
Paul B.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Dear Paul

Thank you for taking the time to reply.

I am trying to write a program that will keep track of external signals. The signals come from a microswitch in a clock tower once every hour. The applied signals will be recorded/analysed/reset in memory then transferred to portc.

So my problem is that I have just developed and tested a program that works in my simulator (THRISM11), but am wondering if it will actually work in the physical chip when I download it.

The reason for my concern is that the simulator uses ROM, and I belive that ROM is only programmable in the factory, and that I need to use EEPROM.

So this is why I was asking about Interrupts. The IRQ interrupt vector is located in $FFF2, so when you make the IRQ line low, the data contained in this address is inserted into the program counter and is used as the address for the next instruction. So if the data located at $FFF2 is in ROM, then how do you change it?

Thanks again for taking the time to reply

Kind Regards

Nathan (Electronics Student)
"Paul B. Webster VK2BZC" <paulb@paul...> wrote:
On Thu, 2005-07-07 at 06:05 +0000, nathan_b_a wrote:
> What I don't understand is how you can edit the interrupt vector when
> it is in the ROM? I thought ROM could only be configured in the
> factory.

The answer to this is perhaps circuitous - the interrupt vector is
actually part of the program itself. If you have a ROM-based MCU, then
not only is the IRQ vector in ROM, but so is the program itself! They
are inseparable.

So - where is your program? If it is in RAM, then the *same*
mechanism which you use to place and start the program, is used to set
the IRQ vector. You see the *START* (reset) vector is adjacent to the
IRQ vector, so both are defined in the same manner.

If you are running a bootstrap or "monitor" - which is in ROM, then it
generally pre-sets the IRQ vector to jump to a RAM location which it
initialises to a default, but which you can re-allocate in the same
action as you load program code to be executed.

So, if you understand what your system is doing in general, the answer
will follow.

--
Cheers,
Paul B.
---------------------------------
YAHOO! GROUPS LINKS --------------------------------- ---------------------------------
Sell on Yahoo! Auctions - No fees. Bid on great items.

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Dear Steve

Thank you for taking the time to reply.

I am trying to write a program that will keep track of external signals. The signals come from a microswitch in a clock tower once every hour. The applied signals will be recorded/analysed/reset in memory then transferred to portc.

So my problem is that I have just developed and tested a program that works in my simulator (THRISM11), but am wondering if it will actually work in the physical chip when I download it.

The reason for my concern is that the simulator uses ROM, and I belive that ROM is only programmable in the factory, and that I need to use EEPROM.

So this is why I was asking about Interrupts. The IRQ interrupt vector is located in $FFF2, so when you make the IRQ line low, the data contained in this address is inserted into the program counter and is used as the address for the next instruction. So if the data located at $FFF2 is in ROM, then how do you change it?

Thanks again for taking the time to reply

Kind Regards

Nathan (Electronics Student) Steve Tabler <stevetabler@stev...> wrote:I am not familiar with the Thrism11 simulator. Generally speaking, with a
real 68HC11, you can put the hc11 in expanded-multiplexed mode and then use
an external device like your eeprom for your interrupt vectors and program
memory. The exceptions to this are certain items on-chip which if enabled
would take precedent for the addresses they occupy i.e. registers, eeprom, ram.

At 06:05 AM 7/7/2005 +0000, you wrote:
>HI
>
>I'm currently writing a program for the 68hc11 on my Thrism11
>simulator. The program uses the irq interrupt.
>
>What I don't understand is how you can edit the interrupt vector when
>it is in the ROM? I thought ROM could only be configured in the
>factory. >
>For example, here is my code for the first part of the program:
>
>STACK EQU $00FF
>PROGRAM EQU $FF00
>IRQ EQU $FFF2
>DDRC EQU $07
>REGBAS EQU $1000
>PORTC EQU $03
>MEMORY EQU $04
>PORTD EQU $08
>
>*************************************************
>* SETUP *
>*************************************************
>
> ORG IRQ
> FDB IRQHERE
>
> ORG PROGRAM
>*MAIN PROGRAM
>START SEI ;MASK IRQ
> LDS #STACK ;SETUP STACK POINTER
> LDX #REGBAS ;SET REGISTER BASE
> LDAA #$03 ;LOAD A WITH 01 FOR PORT C SETUP
>
> STAA DDRC,X ;SET PC0 AND PC1 AS OUTPUT AND PC2-
>PC7 AS INPUTS
> LDAA PORTC,X
> ANDA #$80
> STAA PORTC,X ;CLEAR PORT C
> LDAA #$00 ;LOAD A WITH 00 TO RESET MEMORY
> STAA MEMORY,X ;CLEAR MEMORY
> CLI ;CLEAR INTERRUPT MASK
>
>*************************************************
>* MAIN PROGRAM *
>*************************************************
>
>LOOP BRA LOOP ;WAIT HERE FOR DEBOUNCED IRQ SIGNAL
>
>**************************************************
>* IRQ Request *
>**************************************************
>
>IRQHERE LDAA MEMORY,X ;LOAD ACCUMULATOR A WITH THE MEMORY D >
>Now, when I assemble this the irq address of $fff2 contains the hex
>$ff16. This differs from the default which was $ffff.
>
>The reason I ask this is because I want to transfer this program to a
>real chip and run the program in EEPROM, but I'm not sure if the
>interrupt vector will work.
>
>In summary, can you change the contents of $fff2 in real life, or is
>this only something you can do at the factory and in a simulator.
>
>Any help appreciated.
>
>Thank you
>
>Nathan >Yahoo! Groups Links ---------------------------------
YAHOO! GROUPS LINKS --------------------------------- ---------------------------------
Sell on Yahoo! Auctions - No fees. Bid on great items.

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

It's nice to see some activity on this group for a change.

nathan_b_a wrote:

>HI
>
>I'm currently writing a program for the 68hc11 on my Thrism11
>simulator. The program uses the irq interrupt.
>
>What I don't understand is how you can edit the interrupt vector when
>it is in the ROM? I thought ROM could only be configured in the
>factory. [snip]

There are several answers to your question, some of which have already
been given.

I know nothing about your simulator, however supposing it to be
a program running on some other computer (like a PC), then there
is no actual ROM in the simulator connected with the simulated
MC68HC11.

OTOH, it is important to remember that a simulator is, after all, a
simulator. It is not actually the hardware you will run with. The
simulator may actually only use a small ROM located where you
can't see it, and run all your programs out of RAM, including your
interrupt vectors. This can be done, even if the actual processor
is an MC68HC11, by relocating the address range of the RAM
dynamically. When you first boot, the ROM is in the address
space, and it is used to download your program into RAM, which
has been decoded to different addresses. When you tell it to GO,
then the RAM is relocated to its run address, and a different kind
of reset is done.

Another answer is that when you develop a new program, and
send it to Motorola, they make a special version of the MC68HC11
for you, with your program in the ROM.

Another answer is that you blow an EPROM or EEPROM, and
boot in an expanded mode, so that the internal ROM is not part
of the address map. >
>
>For example, here is my code for the first part of the program:
>
>STACK EQU $00FF
>PROGRAM EQU $FF00
>IRQ EQU $FFF2
>DDRC EQU $07
>REGBAS EQU $1000
>PORTC EQU $03
>MEMORY EQU $04
>PORTD EQU $08
>
>*************************************************
>* SETUP *
>*************************************************
>
> ORG IRQ
> FDB IRQHERE
>
> ORG PROGRAM
>*MAIN PROGRAM [snip]

>IRQHERE LDAA MEMORY,X ;LOAD ACCUMULATOR A WITH THE MEMORY D >
>Now, when I assemble this the irq address of $fff2 contains the hex
>$ff16. This differs from the default which was $ffff. It contains the value of IRQHERE. In other words, the vector address $FFF2
"points" to your routine IRQHERE, which is at address $FF16.

>The reason I ask this is because I want to transfer this program to a
>real chip and run the program in EEPROM, but I'm not sure if the
>interrupt vector will work. It sure will, if you decode your EEPROM to start at $FF00.

>In summary, can you change the contents of $fff2 in real life, or is
>this only something you can do at the factory and in a simulator. If you run in an expanded multiplex mode, and decode your EEPROM correctly,
when you reset your program will execute as written. (NOT necessarily
correctly, however :-)

You will need, however to pay close attention to the differences between the
addresses IN THE ROM versus addresses CALCULATED BY THE
PROCESSOR.

For example, suppose you use an 8K EEPROM, say a 2864. You decode
it so it covers the address range $C000-$FFFF. Fine, this looks good.
But you need to realize that the addresses the ROM sees are only the
low order bits, the high order bits are used to create chip select. So the
EEPROM sees addresses $0000-$1FFF. Your EEPROM programmer
must be properly instructed concerning how to do the programming to
account for this. I have found that this is sometimes a point of confusion
for beginners.

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Normally, you would have a changeable vector in RAM and the $FFF2 vector
would point to a routine in 'ROM' such as:

IRQV:
ldx ramvector
jsr 0,x ;or jmp 0,x if the rti is in the routine
rti ----- Original Message -----
From: "nathan apps" <nathan_b_a@nath...>
To: <m68HC11@m68H...>
Sent: Thursday, July 07, 2005 6:41 AM
Subject: Re: [m68HC11] Interrupts > Dear Steve
>
> Thank you for taking the time to reply.
>
> I am trying to write a program that will keep track of external signals.
> The signals come from a microswitch in a clock tower once every hour. The
> applied signals will be recorded/analysed/reset in memory then transferred
> to portc.
>
> So my problem is that I have just developed and tested a program that
> works in my simulator (THRISM11), but am wondering if it will actually
> work in the physical chip when I download it.
>
> The reason for my concern is that the simulator uses ROM, and I belive
> that ROM is only programmable in the factory, and that I need to use
> EEPROM.
>
> So this is why I was asking about Interrupts. The IRQ interrupt vector is
> located in $FFF2, so when you make the IRQ line low, the data contained in
> this address is inserted into the program counter and is used as the
> address for the next instruction. So if the data located at $FFF2 is in
> ROM, then how do you change it?
>
> Thanks again for taking the time to reply
>
> Kind Regards
>
> Nathan (Electronics Student) > Steve Tabler <stevetabler@stev...> wrote:I am not familiar with the
> Thrism11 simulator. Generally speaking, with a
> real 68HC11, you can put the hc11 in expanded-multiplexed mode and then
> use
> an external device like your eeprom for your interrupt vectors and program
> memory. The exceptions to this are certain items on-chip which if enabled
> would take precedent for the addresses they occupy i.e. registers, eeprom,
> ram.
>
> At 06:05 AM 7/7/2005 +0000, you wrote:
>>HI
>>
>>I'm currently writing a program for the 68hc11 on my Thrism11
>>simulator. The program uses the irq interrupt.
>>
>>What I don't understand is how you can edit the interrupt vector when
>>it is in the ROM? I thought ROM could only be configured in the
>>factory.
>>
>>
>>
>>For example, here is my code for the first part of the program:
>>
>>STACK EQU $00FF
>>PROGRAM EQU $FF00
>>IRQ EQU $FFF2
>>DDRC EQU $07
>>REGBAS EQU $1000
>>PORTC EQU $03
>>MEMORY EQU $04
>>PORTD EQU $08
>>
>>*************************************************
>>* SETUP *
>>*************************************************
>>
>> ORG IRQ
>> FDB IRQHERE
>>
>> ORG PROGRAM
>>*MAIN PROGRAM
>>START SEI ;MASK IRQ
>> LDS #STACK ;SETUP STACK POINTER
>> LDX #REGBAS ;SET REGISTER BASE
>> LDAA #$03 ;LOAD A WITH 01 FOR PORT C SETUP
>>
>> STAA DDRC,X ;SET PC0 AND PC1 AS OUTPUT AND PC2-
>>PC7 AS INPUTS
>> LDAA PORTC,X
>> ANDA #$80
>> STAA PORTC,X ;CLEAR PORT C
>> LDAA #$00 ;LOAD A WITH 00 TO RESET MEMORY
>> STAA MEMORY,X ;CLEAR MEMORY
>> CLI ;CLEAR INTERRUPT MASK
>>
>>*************************************************
>>* MAIN PROGRAM *
>>*************************************************
>>
>>LOOP BRA LOOP ;WAIT HERE FOR DEBOUNCED IRQ SIGNAL
>>
>>**************************************************
>>* IRQ Request *
>>**************************************************
>>
>>IRQHERE LDAA MEMORY,X ;LOAD ACCUMULATOR A WITH THE MEMORY D
>>
>>
>>
>>Now, when I assemble this the irq address of $fff2 contains the hex
>>$ff16. This differs from the default which was $ffff.
>>
>>The reason I ask this is because I want to transfer this program to a
>>real chip and run the program in EEPROM, but I'm not sure if the
>>interrupt vector will work.
>>
>>In summary, can you change the contents of $fff2 in real life, or is
>>this only something you can do at the factory and in a simulator.
>>
>>Any help appreciated.
>>
>>Thank you
>>
>>Nathan
>>
>>
>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
> >
>
> ---------------------------------
> YAHOO! GROUPS LINKS > --------------------------------- > ---------------------------------
> Sell on Yahoo! Auctions - No fees. Bid on great items.
>
> [Non-text portions of this message have been removed] >
>
> Yahoo! Groups Links





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Please don't use HTML.
Please don't use long lines.
Please don't top-post.
Please don't quote the entire message you reply
to, unless it is necessary.
OK?

Thanks.

nathan apps wrote:

[snip] >I am trying to write a program that will keep track of external signals. The signals come from a microswitch in a clock tower once every hour. The applied signals will be recorded/analysed/reset in memory then transferred to portc. >
How can an applied signal be reset in memory?

[snip] >So this is why I was asking about Interrupts. The IRQ interrupt vector is located in $FFF2, so when you make the IRQ line low, the data contained in this address is inserted into the program counter and is used as the address for the next instruction. So if the data located at $FFF2 is in ROM, then how do you change it? I'm not sure I understand your question properly. Are you attempting
to save the data you get from PORTC to ROM? That is not possible,
in general. With EEPROM, you can do it, but your program cannot
be running out of the same EEPROM you are programming.

I don't think that is what you mean, however. I think you are wondering
how on Earth you will ever get to your program out of RESET.

The answer is the infamous ROMON bit in the CONFIG register.

If ROMON is a 1, then when the processor boots in any normal mode,
the reset vector comes from the internal ROM. But if ROMON is 0, then
in expanded multiplexed mode the reset vector and all other vectors
come from external memory, not the internal ROM. If your circuit
is designed and constructed properly, this external memory is you
EEPROM.

The way the EEPROM gets changed is that you program it before you
put it into the circuit.

[snip]

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

nathan apps wrote:

[snip] >The reason for my concern is that the simulator uses ROM, and I belive that ROM is only programmable in the factory, and that I need to use EEPROM.
>
>So this is why I was asking about Interrupts. The IRQ interrupt vector is located in $FFF2, so when you make the IRQ line low, the data contained in this address is inserted into the program counter and is used as the address for the next instruction. So if the data located at $FFF2 is in ROM, then how do you change it? I realized just now that there is another way to understand your question.
Are you trying to run out of the EEPROM on the MC68HC11, the 1/2K
located at $B600?

If so, then the answer is No, this will not work as you have written it.

There are several techniques for execting from the EEPROM on the
chip, if that is what you want to do. Two of them are simple, others
get more complicated.

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Jul 7, 2005, at 6:40 AM, nathan apps wrote:

> So this is why I was asking about Interrupts. The IRQ interrupt
> vector is located in $FFF2, so when you make the IRQ line low, the
> data contained in this address is inserted into the program counter
> and is used as the address for the next instruction. So if the data
> located at $FFF2 is in ROM, then how do you change it?

Summary of all the other replies:
- Either use a one-time-programable part and write the vector table
as part of your code.
- Or use a part configured for Expanded Mode and place your code
(including vector table) in an external EPROM.
- Or if using a part which has the Buffalo monitor ROM image you
would consult the Buffalo docs for setting IRQ vectors.

The 68HC11 is intended as a dedicated embedded MCU. Only a rare
exceptional application would have RAM in the vector table space. Its
a Catch-22 situation, if the vector table was in RAM then how would
the CPU know how to start running your code out of RESET?

If one absolutely must revector an IRQ during operation then point
that IRQ at a "jmp (ramlocation)" and put the variable address of
your IRQ service routine in ramlocation (believe this is how the
Buffalo monitor ROM does it). And make darn sure the vector is not
used until after you have ramlocation initialized to something sane.

--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi everyone

Ok, I think I understand my question now.

Here it is.

I have a program that works in ROM, I used the THRISM11 simulator to write and test this program. Now, I want to transfer the program I wrote on my simulator into a real 68hc11, should I:

A) Get someone????? to program the ROM of a 68hc11 with my program

or

B) Put it in the chip another way (such as EEPROM)

What way is the fatsest/easiest/cheapest and if it is to program the ROM who can do this in Australia?

Thanks very much for your help

Kind regards

Nathan

David Kelly <dkelly@dkel...> wrote:

On Jul 7, 2005, at 6:40 AM, nathan apps wrote:

> So this is why I was asking about Interrupts. The IRQ interrupt
> vector is located in $FFF2, so when you make the IRQ line low, the
> data contained in this address is inserted into the program counter
> and is used as the address for the next instruction. So if the data
> located at $FFF2 is in ROM, then how do you change it?

Summary of all the other replies:
- Either use a one-time-programable part and write the vector table
as part of your code.
- Or use a part configured for Expanded Mode and place your code
(including vector table) in an external EPROM.
- Or if using a part which has the Buffalo monitor ROM image you
would consult the Buffalo docs for setting IRQ vectors.

The 68HC11 is intended as a dedicated embedded MCU. Only a rare
exceptional application would have RAM in the vector table space. Its
a Catch-22 situation, if the vector table was in RAM then how would
the CPU know how to start running your code out of RESET?

If one absolutely must revector an IRQ during operation then point
that IRQ at a "jmp (ramlocation)" and put the variable address of
your IRQ service routine in ramlocation (believe this is how the
Buffalo monitor ROM does it). And make darn sure the vector is not
used until after you have ramlocation initialized to something sane.

--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.
---------------------------------
YAHOO! GROUPS LINKS ---------------------------------

---------------------------------
Sell on Yahoo! Auctions - No fees. Bid on great items.

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi Nathan,

Unless you have a good reason to use a HC11, I would look at
using a flash based micro. Some of these have very cheap ways
to program the device, using the serial port. They don't need
special programming voltages and have many other neat features.

Some more details about what your trying to do would help list
members help you choose a device. In most cases the flash
chips will be faster, use less power and cheaper too.

Were in Australia are you ?

Regards,
Darren Moore
> -----Original Message-----
> From: m68HC11@m68H...
> [mailto:m68HC11@m68H...] On Behalf Of nathan apps > Hi everyone
>
> Ok, I think I understand my question now.
>
> Here it is.
>
> I have a program that works in ROM, I used the THRISM11
> simulator to write and test this program. Now, I want to
> transfer the program I wrote on my simulator into a real
> 68hc11, should I:
>
> A) Get someone????? to program the ROM of a 68hc11 with my program
>
> or
>
> B) Put it in the chip another way (such as EEPROM)
>
> What way is the fatsest/easiest/cheapest and if it is to
> program the ROM who can do this in Australia?
>
> Thanks very much for your help
>
> Kind regards
>
> Nathan



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi Darren

The only reason I wanted to use the 68HC11 was because I just spent a semester at university learning about computer hardware. The first half of the semester was spent on plds, and then in the second half we touched on micro controllers, in particular the 68hc11.

A friend of mine wants me to design a micro controller for his clock tower. The mechanical clock in this tower has a micro switch in it that sends an electrical pulse once every hour. This signal is to be recorded by a micro controller, and then used to send a signal to a relay to dong the bell. The micro controller is responsible for keeping track of the time, and with the aid of input switches, determining when to send a signal to the relay.

So, because I am reasonable familiar with the 68HC11 and its assembly language, I thought I would use it.

I have already written and tested the code for the 68Hc11 in the free simulator that came with our textbook - THRISM11. But when it came to transferring this code to the microprocessor, things became difficult. Bah.

I live in Sydney Australia.

Kind regards

Nathan

Darren <djmoore@djmo...> wrote: Hi Nathan,

Unless you have a good reason to use a HC11, I would look at
using a flash based micro. Some of these have very cheap ways
to program the device, using the serial port. They don't need
special programming voltages and have many other neat features.

Some more details about what your trying to do would help list
members help you choose a device. In most cases the flash
chips will be faster, use less power and cheaper too.

Were in Australia are you ?

Regards,
Darren Moore
> -----Original Message-----
> From: m68HC11@m68H...
> [mailto:m68HC11@m68H...] On Behalf Of nathan apps > Hi everyone
>
> Ok, I think I understand my question now.
>
> Here it is.
>
> I have a program that works in ROM, I used the THRISM11
> simulator to write and test this program. Now, I want to
> transfer the program I wrote on my simulator into a real
> 68hc11, should I:
>
> A) Get someone????? to program the ROM of a 68hc11 with my program
>
> or
>
> B) Put it in the chip another way (such as EEPROM)
>
> What way is the fatsest/easiest/cheapest and if it is to
> program the ROM who can do this in Australia?
>
> Thanks very much for your help
>
> Kind regards
>
> Nathan
---------------------------------
YAHOO! GROUPS LINKS ---------------------------------

---------------------------------
Sell on Yahoo! Auctions - No fees. Bid on great items.

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi Nathan,

I understand your reasons to stick with the HC11, and you
are one of many that find it hard to make the jump.

BUT, other then some of your time, to move to say a HC08
device is very easy, and for the most part you can use the
HC11 code. The HC980GP32 is a very popular HC08, and should
be easy to get hold of. I would have a look at the data
online at Freescale, there is free software, assembler and
programmer available from P&E. You can build the small
amount of required programming circuit for it, or buy one.

This device can run from a 32.768khz crystal, so timing
seconds will be very easy, the PLL can boost that to
8Mhz. It has heaps of flash and RAM, you could also use
the free version of the Metrowerks software and program
in C if you like also.

Regards,
Darren Moore

PS I'm in Melbourne. > -----Original Message-----
> From: m68HC11@m68H...
> [mailto:m68HC11@m68H...] On Behalf Of nathan apps
>
> Hi Darren
>
> The only reason I wanted to use the 68HC11 was because I just
> spent a semester at university learning about computer
> hardware. The first half of the semester was spent on plds,
> and then in the second half we touched on micro controllers,
> in particular the 68hc11.
>
> A friend of mine wants me to design a micro controller for
> his clock tower. The mechanical clock in this tower has a
> micro switch in it that sends an electrical pulse once every
> hour. This signal is to be recorded by a micro controller,
> and then used to send a signal to a relay to dong the bell.
> The micro controller is responsible for keeping track of the
> time, and with the aid of input switches, determining when to
> send a signal to the relay.
>
> So, because I am reasonable familiar with the 68HC11 and its
> assembly language, I thought I would use it.
>
> I have already written and tested the code for the 68Hc11 in
> the free simulator that came with our textbook - THRISM11.
> But when it came to transferring this code to the
> microprocessor, things became difficult. Bah.
>
> I live in Sydney Australia.
>
> Kind regards
>
> Nathan



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Please use shorter lines. Please?

nathan apps wrote:

>Hi everyone
>
>Ok, I think I understand my question now.
>
>Here it is.
>
>I have a program that works in ROM, I used the THRISM11 simulator to write and test this program. Now, I want to transfer the program I wrote on my simulator into a real 68hc11, should I: Please explain what THRISM11 is. I'm not going to go researching
your tool like that. I'm expert at the 68hc11, not THRISM. >A) Get someone????? to program the ROM of a 68hc11 with my program
>
>or
>
>B) Put it in the chip another way (such as EEPROM)
>
>What way is the fatsest/easiest/cheapest and if it is to program the ROM who can do this in Australia? What mode are you intending to use? Special Boot, Special Test, Single Chip,
or Expanded Multiplex? We can't answer you question until you provide
that info.

Do you expect your program to change much in the near future? How large is
your program?

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

nathan apps wrote:

>Hi Darren
>
>The only reason I wanted to use the 68HC11 was because I just spent a semester at university learning about computer hardware. The first half of the semester was spent on plds, and then in the second half we touched on micro controllers, in particular the 68hc11. That's a reasonable answer. >A friend of mine wants me to design a micro controller for his clock tower. The mechanical clock in this tower has a micro switch in it that sends an electrical pulse once every hour. This signal is to be recorded by a micro controller, and then used to send a signal to a relay to dong the bell. The micro controller is responsible for keeping track of the time, and with the aid of input switches, determining when to send a signal to the relay.
>
>So, because I am reasonable familiar with the 68HC11 and its assembly language, I thought I would use it. This project doesn't even seem like it needs a uController, just a
counter and a decoder.

However, since you are familiar with the MC68HC11, I'd recommend doing this:

Run in BOOTSTRAP mode. Put your program into the on-chip 1/2K EEPROM.
You don't even need to use interrupts. Just poll. Since you have a
mechanical switch,
you'll either need extra hardware for debounce external to the
uController, or you'll
have to debounce in software. If you don't debounce the switch
externally, you can't
use an interrupt, anyway. So debounce in software (firmware, actually)
and poll
the switch.

If you insist on using interrupts, then I strongly recommend you to use
external
debouncing of the switch. Otherwise you will wind up with a project that has
bizarre behavior that you won't be able to explain, given your seemingly
limited
experience with switches.

I can help you with debounce either way. >I have already written and tested the code for the 68Hc11 in the free simulator that came with our textbook - THRISM11. But when it came to transferring this code to the microprocessor, things became difficult. Bah. Welcome to the real world. In theory, theory is the same as practice. In
practice, theory is never the same as practice.

[huge quote snipped]

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Nathan apps wrote:
> Hi Darren
>
> The only reason I wanted to use the 68HC11 was because I just
spent a semester at university learning about computer hardware.
The first half of the semester was spent on plds, and then in
the second half we touched on micro controllers, in particular
the 68hc11.
>
> A friend of mine wants me to design a micro controller for
his clock tower. The mechanical clock in this tower has a micro
switch in it that sends an electrical pulse once every hour.
This signal is to be recorded by a micro controller, and then
used to send a signal to a relay to dong the bell. The micro
controller is responsible for keeping track of the time, and
with the aid of input switches, determining when to send a
signal to the relay.
>
> So, because I am reasonable familiar with the 68HC11 and its
assembly language, I thought I would use it.
>
> I have already written and tested the code for the 68Hc11 in
the free simulator that came with our textbook - THRISM11. But
when it came to transferring this code to the microprocessor,
things became difficult. Bah.
>
> I live in Sydney Australia.
>
> Kind regards
>
> Nathan
>
Hi Nathan,

If you are very careful it could fit in the 512 bytes of EEPROM
of a 68HC11 written in C. But that takes some really tight
programing and probably modification of the compiler start up
code. It should not be hard to fit in with assembler. You modify
an address at the beginning of EEPORM to tell the CPU where the
program is. If you have a Buffalo monitor on the board you pull
pin e.0 high and it will jump the start of EEPROM on power up or
reset instead of E000.

For a one off buying a board from some one like New Micros
http://www.newmicros.com/ is by far the least expensive way to
go. I have extensively used their NMIS-0021 board that takes to
memory chips and put an EEPROM in one for the program. If you
don't have access to EEPROM blaster you can use two SRAM chips
and HCLOAD it is at http://www.microsyl.com/. The documentation
does not mention Windows XP but the HCLOAD ran on my XT box. It
will burn code to the on board 512 KB of EEPROM or the OTROM
chips. You can also put a SRAM chip in the place where you would
normally put and EEPROM and use HCLOAD to load the program the
remove the jumper from the write enable pin of the SRAM socket.
That is not as secure as EEPROM but it woks great for testing
and is not a lot of trouble in service if you opto isolate it
from the wires coming down from the clock and run it on
batteries so nothing wild gets on the board.

I have not use at 68HC08 but your code should be an easy port to
a 68HC12 I have their NMIB-0912 $149.00 and NMIN-0812
$79.95. The 812 has 1024 bytes of RAM and 4096 bytes of EEPROM
on board. The EEPROM live is sort and 100 or 200 cycles. If you
use this chip if you can modify the EEPROM write program to
erase and write as fast as it can so the bits are heated as
little as possible.

Another choice with the New Micros 68HC11 boards is to use the
on board FORTH that resides at E000 to FFFF. They have examples
to do most of what you want and again if your fugal with your
code it should fit in the 512 EEPROM

I have been using the New Micros 68HC11 boards for about 15
years. These were the tools I used when I was working with it.
The editor is out of date and is a bit flaky on newer windows
systems. I have just revived that set up for a light meter and
it still works just fine.

If you are seriously thinking about going forward with embedded
systems I would consider a modern processor. I just bought New
Micros Tiny Arm Tini2106 and Plug an Arm D_kit and couple of
sockets for the Tiny Arm. A $30 60 MHz 128KByte Program Flash
and 64KByte SRAM with a rich feature set looks like a good move.
Of course I can use their on board FORTH and that's not an easy
language to get to the point you can use it well but it does
make an excellent testing and debugging toll for hardware. It
has almost all the words you need to test most things you put on
a broad fairly easy.

It also uses the open source GNU C++ and development system
Eclipse http://eclipse.org/ The make files and complexity of GNU
C++ are substantial. How ever the wide spread use of GNU C++
makes it wroth the trouble to learn if you going to work on
multiple platforms. I haven't used Eclipse but they talk a good
story. It is written in Java that seem to the trend in tools so
they can be platform independent. The support at New micros is
pretty good it is managed by email or through a form.

But ARM may not have the life of the 68HCll. While its and old
processor there is no sign of it going away. There are lot of
products that use it that have no reason to change. Good luck
Gordon

Gordon Couger
Stillwater, OK
www.couger.com/gcouger



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Gordon Couger wrote:

>Nathan apps wrote: that he already has an assembly language program working with a simulator.

>If you are very careful it could fit in the 512 bytes of EEPROM
>of a 68HC11 written in C. But that takes some really tight
>programing and probably modification of the compiler start up
>code. It should not be hard to fit in with assembler. You modify
>an address at the beginning of EEPORM to tell the CPU where the
>program is. If you have a Buffalo monitor on the board you pull
>pin e.0 high and it will jump the start of EEPROM on power up or
>reset instead of E000. He's already stated that he is working in assy.

>For a one off buying a board from some one like New Micros
>http://www.newmicros.com/ is by far the least expensive way to
>go. I have extensively used their NMIS-0021 board that takes to [snip long discussion of New Micros stuff]

I also use New Micros, and think they are wonderful. They also live
about 20 mi from me, so it's an easy trip by car to pick one up, which
they will do.

However, this guy lives in AUSTRALIA. New Micros in Dallas, Texas,
USA is not very convenient for him.

>If you are seriously thinking about going forward with embedded
>systems I would consider a modern processor.
>
He wants to do a favor for a friend. Not become a major developer
of MC68HC11 products.

[snip more New Micros stuff]

>Good luck
>Gordon I suggest that, next time, you read a little of the context before
posting mail.

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Mike,

I gave him all the options I could think of including loading the the
assembly code in the 512 bytes of EEPROM on the chip with HCLOAD. Which
is more than anyone else I have seen thought of.

New Micros has shipped boards all over the world for me. The cost of
shipping to OZ is not that much.

Gordon

Mike McCarty wrote:

>Gordon Couger wrote: >
>>Nathan apps wrote:
>>
>>
>>
>>
>that he already has an assembly language program working with a simulator. >
>>If you are very careful it could fit in the 512 bytes of EEPROM
>>of a 68HC11 written in C. But that takes some really tight
>>programing and probably modification of the compiler start up
>>code. It should not be hard to fit in with assembler. You modify
>>an address at the beginning of EEPORM to tell the CPU where the
>>program is. If you have a Buffalo monitor on the board you pull
>>pin e.0 high and it will jump the start of EEPROM on power up or
>>reset instead of E000.
>>
>>
>>
>>
>He's already stated that he is working in assy. >
>>For a one off buying a board from some one like New Micros
>>http://www.newmicros.com/ is by far the least expensive way to
>>go. I have extensively used their NMIS-0021 board that takes to
>>
>>
>>
>>
>[snip long discussion of New Micros stuff]
>
>I also use New Micros, and think they are wonderful. They also live
>about 20 mi from me, so it's an easy trip by car to pick one up, which
>they will do.
>
>However, this guy lives in AUSTRALIA. New Micros in Dallas, Texas,
>USA is not very convenient for him. >
>>If you are seriously thinking about going forward with embedded
>>systems I would consider a modern processor.
>>
>>
>>
>He wants to do a favor for a friend. Not become a major developer
>of MC68HC11 products.
>
>[snip more New Micros stuff] >
>>Good luck
>>Gordon
>>
>>
>>
>>
>I suggest that, next time, you read a little of the context before
>posting mail.
>
>Mike
[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Gordon Couger wrote:

>Mike,
>
>I gave him all the options I could think of including loading the the
>assembly code in the 512 bytes of EEPROM on the chip with HCLOAD. Which
>is more than anyone else I have seen thought of. >
I don't want to get into a flame war, but my point is that you *haven't*
seen very
much. I'm not trying to sound like anyone is ungrateful for your attempt
to help.
I am suggesting that you try to get more context next time.

I pointed out to him that he could put his program into the on-board
EEPROM at $B600, myself.

>New Micros has shipped boards all over the world for me. The cost of
>shipping to OZ is not that much. I think that his project is already over-designed. All he really needs is a
debounce circuit, a counter, a decoder, and some transistors to drive
the relays. An $80 USD (what I paid for my New Micros NMIY020)
uController board is, IMO, way over the top. I'm sure there are firms
in Australia which supply small '11 boards.

In any case, I think his project has some problems. He wants to connect
a microswitch to an interrupt. A dry contact to an interrupt. How well
do you think this will work?

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Jul 8, 2005, at 1:36 PM, Mike McCarty wrote:

> In any case, I think his project has some problems. He wants to
> connect
> a microswitch to an interrupt. A dry contact to an interrupt. How well
> do you think this will work?

The first closure and a couple of bounces will work great! He only
has to be aware of the prospect of bounces and handle them
appropriately.

An hourly interrupt on a CPU which doesn't have anything else to do
isn't quite standard practice. But if the CPU powers itself down
between inputs then the input needs to be on an IRQ to wake the
sleepy head.

--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Jul 8, 2005, at 8:33 AM, Mike McCarty wrote:

>> So, because I am reasonable familiar with the 68HC11 and its
>> assembly language, I thought I would use it.
>
> This project doesn't even seem like it needs a uController, just a
> counter and a decoder.

Sounds a lot to me as if Nathan doesn't have any hardware at all
yet. Based on his brief description of the task I suspect acquiring
hardware will be by far the hardest task he is facing.

I second others' suggestion that you rethink your CPU selection.
Rather than use one you are briefly familiar with you could learn
enough to use something different with less effort than you can
acquire an HC11 and load your code into it.

Contact your nearest Freescale distributor. Tell them you are a
student and this is a non-class project that you are motivated to
undertake. As if they have anything cheap and/or free that you
could use. I'm guessing one of the $50 to $100 HC08 demo boards is
laying around slightly used that you could have for the asking.
Most of these only require an RS-232 serial cable to upload your
code, run, and debug on real hardware. Assembly is very similar to
the HC11. The free Metrowerks C compiler is more than enough for
your project. Would need Metrowerks even for assembly. Load your
code and test, pull the cable and you have real running hardware.

Microchip has similar offerings. Assembly on the PIC is unlike
anything you've seen before.

Atmel has a "Butterfly" board which is $19.95 from Digikey. Has an
LCD display and interesting assortment of prewired I/O.

It needs an external JTAG ICE (or ISP) to load/debug code. $40 for
"ICE-cube" from http://ecrostech.com/ . The $3 "10-way Ribbon
Cable, 12 in." really helps connect the ICE-Cube in tight places.

Also because the Butterfly is quite minimal you need something to
hold it to make connections:
http://ecrostech.com/Products/Butterfly/Intro.htm, $9 for bare PCB
or $19 for complete parts kit.

WinAVR is a packaged bundle of GNU tools for the AVR on Windows.
Highly recommended for the AVR if you are running Windows.

--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

David Kelly wrote:

>On Jul 8, 2005, at 1:36 PM, Mike McCarty wrote: >
>>In any case, I think his project has some problems. He wants to
>>connect
>>a microswitch to an interrupt. A dry contact to an interrupt. How well
>>do you think this will work?
>>
>>
>
>The first closure and a couple of bounces will work great! He only
>has to be aware of the prospect of bounces and handle them
>appropriately. I think this guy is pretty naive, actually. I made some remarks about
needing
debounce either in hardware or software, and he hasn't responded.

>An hourly interrupt on a CPU which doesn't have anything else to do
>isn't quite standard practice. But if the CPU powers itself down
>between inputs then the input needs to be on an IRQ to wake the
>sleepy head. Yes, he could use WAI. Of course, some mask sets have prolems with
that instruction. Or even STOP, which is lower power.

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Fri, 2005-07-08 at 13:36 -0500, Mike McCarty wrote:
> I think that his project is already over-designed. All he really needs is a
> debounce circuit, a counter, a decoder, and some transistors to drive
> the relays. An $80 USD (what I paid for my New Micros NMIY020)
> uController board is, IMO, way over the top. I'm sure there are firms
> in Australia which supply small '11 boards.

I tend to agree. Unless he wishes to actually keep time with the
board, for which he basically needs a RTC chip and 32,768 crystal (and -
even if he does), I would suggest a (fairly) local phone call to
Microzed about a PICAXE dev board (i.e., totally unrelated to 68HC11),
and either a little drive up to the Entrance (Wyong), or a mail order,
and easy-to-use hardware with no shortage of support will be on hand
pretty cheap!

http://www.microzed.com.au/MICROZED/ORDERING.htm --
Cheers,
Paul B.



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Fri, 2005-07-08 at 02:00 -0700, nathan apps wrote:

> The only reason I wanted to use the 68HC11 was because I just spent a semester
> at university learning about computer hardware.

Uni? HC11? Not perchance NSW, or UTS?

--
Cheers,
Paul B.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi Paul

I just had a look at the PICAXE site, I think this would be perfect. Have any of the other members used the PICAXE microcontrollers?

Macquarie University

Nathan

"Paul B. Webster VK2BZC" <paulb@paul...> wrote:
On Fri, 2005-07-08 at 13:36 -0500, Mike McCarty wrote:
> I think that his project is already over-designed. All he really needs is a
> debounce circuit, a counter, a decoder, and some transistors to drive
> the relays. An $80 USD (what I paid for my New Micros NMIY020)
> uController board is, IMO, way over the top. I'm sure there are firms
> in Australia which supply small '11 boards.

I tend to agree. Unless he wishes to actually keep time with the
board, for which he basically needs a RTC chip and 32,768 crystal (and -
even if he does), I would suggest a (fairly) local phone call to
Microzed about a PICAXE dev board (i.e., totally unrelated to 68HC11),
and either a little drive up to the Entrance (Wyong), or a mail order,
and easy-to-use hardware with no shortage of support will be on hand
pretty cheap!

http://www.microzed.com.au/MICROZED/ORDERING.htm --
Cheers,
Paul B.
---------------------------------
YAHOO! GROUPS LINKS ---------------------------------

---------------------------------
Sell on Yahoo! Auctions - No fees. Bid on great items.

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Mike,

I was a bit short and I am sorry for that. I went to a lot of
trouble to track down the sources for HCLOAD and the various
board and resources. I didn't see your mention of using the
EEPROM at B600 and my mention of it wasn't very clear in the
first post. I went to the trouble to down load HCLOAD to see if
ran on Windows XT it does but that's no warentee it will
function with a 68HC11.

I use New Micros as an example because they have been around for
ever and I expect they will be there in the future. They still
make boards with a socket for the port replacement unit though
they can't get them because they will emulate about any 68HC11
left on the market if you can find a PPU chip from them. They
don't obsolete boards very often and they will work with you on
custom designs, prototypes and manufacturing or provide you art
to do it some where else. I had them do it once and I thought
the price was quite reasonable including the rework that was my
mistake. Building a board for a one off is senseless unless one
need the experience or a 8 pin PIC or other simple board.

I am sure there are other broad makers out there with equally
good boards and track records. I just haven't used them.

If I were starting today I would get something like the ARM that
had good tools available free and didn't require a ROM emulator
and EPROM burner. In a sense I am starting over and thats why I
mentioned the ARM. I don't know if the fellow only want to do
one project in his life or if he serious about embedded programming.

If he wants to go in it seriously I don't think the 68CH11 is
the palace to start. It is used a lot in teaching because they
have them, it is a nice clean CPU with a rich set of features
and it serves the use of teaching very well.

But the quick way is to HCLOD to write the assembly he already
has on a single chip board such as
http://www.newmicros.com/cgi-bin/store/order.cgi?form=prod_detail&part=NMIN-0021A-
if he is failure with the Buffalo monitor as there is a lot
documentation on how to do it.

Best Regards
Gordon

Mike McCarty wrote:
> Gordon Couger wrote: >>Mike,
>>
>>I gave him all the options I could think of including loading the the
>>assembly code in the 512 bytes of EEPROM on the chip with HCLOAD. Which
>>is more than anyone else I have seen thought of.
>>
>>
>>
>
> I don't want to get into a flame war, but my point is that you *haven't*
> seen very
> much. I'm not trying to sound like anyone is ungrateful for your attempt
> to help.
> I am suggesting that you try to get more context next time.
>
> I pointed out to him that he could put his program into the on-board
> EEPROM at $B600, myself. >>New Micros has shipped boards all over the world for me. The cost of
>>shipping to OZ is not that much.
>>
>>
>
> I think that his project is already over-designed. All he really needs is a
> debounce circuit, a counter, a decoder, and some transistors to drive
> the relays. An $80 USD (what I paid for my New Micros NMIY020)
> uController board is, IMO, way over the top. I'm sure there are firms
> in Australia which supply small '11 boards.
>
> In any case, I think his project has some problems. He wants to connect
> a microswitch to an interrupt. A dry contact to an interrupt. How well
> do you think this will work?
>
> Mike




(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Gordon Couger wrote:

>Mike,
>
>I was a bit short and I am sorry for that. I went to a lot of
>trouble to track down the sources for HCLOAD and the various
>board and resources. I didn't see your mention of using the No problem. I'm sure you went to a lot of work.

[snip]

>I use New Micros as an example because they have been around for
>ever and I expect they will be there in the future. They still
>make boards with a socket for the port replacement unit though I agree New Micros is great.

[snip]

>But the quick way is to HCLOD to write the assembly he already
>has on a single chip board such as
>http://www.newmicros.com/cgi-bin/store/order.cgi?form=prod_detail&part=NMIN-0021A-
>if he is failure with the Buffalo monitor as there is a lot
>documentation on how to do it. >
Certainly an SBC would do the job.

I wonder where the original poster went in all the dust?

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Jul 8, 2005, at 6:36 PM, Gordon Couger wrote:

> If he wants to go in it seriously I don't think the 68CH11 is
> the palace to start. It is used a lot in teaching because they
> have them, it is a nice clean CPU with a rich set of features
> and it serves the use of teaching very well.

Its so refreshing to see others share the same opinion as myself,
"... it serves the use of teaching..." That the purpose of education
is not to drill repetitive skills but to teach one how to solve
problems and learn to self-teach. That too many schools "teach"
Microsoft Word version 3.14159 and graduates think they have "learned
computers" when they haven't learned anything but rote drill using a
specific application.

About 8 years ago I got placed on the interview list to grill
potential new hires. Was shocked to find so-called CS graduates had
not operated a raw C compiler or written a Makefile. Graduated with a
B.C.S. and never ventured outside of Microsoft Visual Suite. All got
solid F's on my report. The opening was for a Unix System
Administrator. I had to try to explain some facts of life to
Personnel that those candidates should not have received invitations.

Had any candidate indicated they understood the whole world was not
Microsoft Visual Suite, then they could have earned a "C" on their
interview from me.

Agree the HC11 is a good platform to introduce students to
microcontrollers. Its not so good for ease of using the hardware. The
famous Pink book is an exceptionally excellent reference.

Have been using Atmel Atmega64 lately. Its features make the hardware
much easier to construct and cheaper than the HC11. Its documentation
lacks the clarity and organization found in the Pink book.

--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Fri, 2005-07-08 at 20:05 -0500, Mike McCarty wrote:

> I wonder where the original poster went in all the dust?

It appears (he's told me,) he's been intensively researching the
PICAXE.

Over here, it's far easier to pick up than anything HC11, HC12 or such
- it's the current darling of the local electronics magazine (I would
say "magazines", but they all basically coalesced into one), and kits
are available from the local "hobby" retailers.

> I agree New Micros is great.

Mind you, I too still have an NMI system of great antiquity, unused
after 10 years or so. I'm about to locate it soon - major house
upheaval. Its main lack for my purpose (house controller) is of all
things - a RTC.

The PICAXE is within its limits, a dev system on a chip - like a
Rabbit but less sophisticated (and much, much cheaper). It has an
interpreter (token code), doesn't run particularly fast, but contains
all the primitives for debounce, PWM, analog estimation, timing, LCD,
I²C & DOW (I think), so for simple logic replacement and rapid one-off
development, it is very effective. The version likely useful in this
case is an 8-pin chip - that is, 5 or 6 I/O, retailing about A$4. Since
the concept is to use virtually *no* "glue" logic, it works quite well
on Vero or a "breadboard" PCB which simply expands DIL to pads.

Low-end chips can self-clock with modest stability, larger ones can or
must use one or two crystals. They are in fact simply F-series PICs
programmed with the interpreter, interpreting token code from EEPROM
which can alternatively store data. One is warned not to put them in a
"real" PIC programmer and erase them because you lose the interpreter
(irretrievable because it is proprietary)!

Not quite the same as running FORTH, to which you can talk with a
terminal emulator (or straight terminal).

Speaking of interrupts, and echoing all previously written, it might
seem that instructors fail to make it clear that interrupts are actually
for interfacing *not* to the "real world" at all, but to logic chips
(generally: peripherals, and *only* through these to the "real world").
Obviously, this needs to be stressed. Very few "real world" devices
indeed have the (time) resolution to deserve service at interrupt level.

Students, having been taught that interrupts provide "fast" service,
are obviously not in a mindset to conceptualise that "fast" to the
microprocessor, is nearly a million times what it means in human terms -
because that is how fast the MCU cycles.

--
Cheers,
Paul B.



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi Paul,

In the prototype of www.greenseeker.com interutpts detected
ground seed by using the pulse accumlator on 68HC11 to count the
pulses off a shaft encoder tied to a wheel with a timeing belt.

I built an 10 x 32 foot X, Y, Z scanner used a line of laser
light at 45 degrees to the camera axis to scan a soil table with
an arifical rain maker in New Micros FORTH. It used 3 input
caputure interupts to cange one of 3 differnt stacks to keep
track of the position in space. The fellow before me wrongly
assumed that he had bigenough stepper motors to move the
reliably where he told it to go. He installed a stepper dirver
card in a PC to a power supply with 40 foot of 14 guage wire to
the stepper motors,

I moved the power supply to the carrage with in 7 foot of the
stepper moters and used 10 gauge Leitz wire for added flexibity.
I put an opto isolated 68HC11 bord on the power supply and
commuicated with it via the RS232. Insted of telling it how many
steps to take I told it the postiion to go to. The boar set a
goal for the new postion from its present postion and ramped up,
down, and if it was off jogged into positon.

It worked well when we used the standard scan of 1 cm accross
the plot and 20 cm down slope that had been carried over from
the days it was done by hand. Tough the accross slope resouliion
was a great deal higher. When the project got a new PI that
didn't understand that laws of physics applied to him he decided
he wanted it on a 1 cm x 1 cm basis. A device that was made
for attended operaton suddenly needed to run 20 times longer. It
took 7 seconds for the camera to stop shaking no matter what we
did.Hi Paul,

In the prototype of www.greenseeker.com interutpts detected
ground seed by using the pulse accumlator on 68HC11 to count the
pulses off a shaft encoder tied to a wheel with a timeing belt.
It also can get its timing intrerupt for heart beat from the CPU
or GPS.

I built an 10 x 32 foot X, Y, Z scanner used a line of laser
light at 45 degrees to the camera axis to scan a soil table with
an artificial rain maker in New Micros FORTH. It used 3 input
capture interrupts to change one of 3 different stacks to keep
track of the position in space. When and interrupt occurred the
interrupt routine blocked interprets changed the stack pointer,
saved the resisters and start adding or subtracting counts from
it and restored things on the way out. I don't remember how
many machine cycles it saved but it was enough to make it worth
while so I didn't get two interrupts from the other shaft
encoders and loose one. All that was left on the stack was the
absolute count from the shaft encoder from 0,0,0. The camera arm
had a stop on the lower end so it could be raised at any time
and the position recovered because it fell to the ground if the
power failed and that was 2 or 3 times a week in the spring.

The fellow before me wrongly assumed that he had big enough
stepper motors to move the reliably where he told it to go. They
were almost big enough when it was new if he had not installed a
stepper diver card in a PC to a power supply with 40 foot of 14
gauge wire to the stepper motors,

I moved the power supply to the carriage with in 7 foot of the
stepper motors and used 10 gauge Leitz wire for added flexibly.
If the wire was any thicker the mother would not move smoothly.
I put an opto isolated 68HC11 board on the power supply not as
close to the stepper motor as they could be and communicated
with it via the RS232. Instead of telling it how many steps to
take I told it the position to go to. The board set a goal for
the new position from its present positron and ramped up, down,
and stomped. If it was off jogged into positron.

It worked well when we used the standard scan of 1 cm across the
plot and 20 cm down slope that had been carried over from the
days it was done by hand. Tough the across slope resolution was
a great deal higher than when done by hand. When the project got
a new PI that didn't understand that laws of physics applied to
him he decided he wanted it on a 1 cm x 1 cm basis. A device
that was made for attended operation suddenly needed to run 20
times longer. It took 7 seconds for the camera to stop shaking
no matter what we did.

It went a lot slower than planed because it required an method
of using a computer to find the path water flowed over land and
no one had done that before. I finally got a hint in
Mathematical Recitations in Scientific American that mazes could
be solved by starting at an opening every opening on the edge
and working the way to each and ever blind end of the maze or
out of it. So I tuned the data into a maze by sorting it for
elevation and starting with the highest point and when I hit a
dead end mark the path back until came to anther path or ran off
the plot. Then I started at each and every point around the edge
and recursively climbing to the to each and every dead end.
When the algorithm failed I started collecting and writing data.

The project had set idle for over a year and it was made of wood
and not concrete so it moved as time went on. After a rain fall
event it took two months to dry out and all the water had to
evaporate out the top of the soil. That concentrates the salts
in surface and after 3 runs the soil resembles concrete more
than soil. When we rebuilt it for the new PI we put in Roots
blower or super charger and could dry it out in a week.

But by thin it was failing faster than we could fix and new PI
had spent all the money on computers for his lab and office.

The one thing we did find out for sure is if the water pools for
any reason the stream will be drawn though the depression. There
were 5 drips that they never stopped and the streams developed
with in 20 cm of the same palace on 12 runs with 3 soil changes
on the lower half of the table.

The moral of this tail is to get a firm commitment for the
resources needed to complete the project when a new guy comes in
you don't. I still like the guy real well but I should have quit
the project as soon as was sure it would fail and not have tried
to make it work once I was sure I couldn't do it. In spite of
the fellow that was running the project, my boss and the
department head. At the time I could have got a job several
places on campus or gone to much better paying job but I am very
sure now and I was pretty sure then that ever one but the PI on
the project would have respected my choice. Instead I waste a
year. Don't work on project that won't work.

Your right about interfacing with the outside world. almost
everything needs something between it and the CPU if for nothing
else but act as fuse when transient get on the line. Long runs
of wire are also known as antennas and pick up a lot of energy
if lightning shrikes near by or some one keys up an 100 watt
radio near by. They have that petty well under control But there
was Porsche that you could kill the engine with a 100 watt ham
radio sitting at the stop light beside it.

If you have problems with electrical noise on long runs of wire
for data consider using voltage to frequency chips and opto
isolators. If its really bad fiber optic cable always works.
Then run the computer on batteries and it really hard for any
outside source to damage it. But you can easily double the cost
of the system and greatly increase the maintenance cost.

Gordon
Gordon Couger
Stillwater, OK
www.couger.com/gcouger

Paul B. Webster VK2BZC wrote:
> On Fri, 2005-07-08 at 20:05 -0500, Mike McCarty wrote: >>I wonder where the original poster went in all the dust? > It appears (he's told me,) he's been intensively
researching the
> PICAXE.
>
> Over here, it's far easier to pick up than anything HC11,
HC12 or such
> - it's the current darling of the local electronics magazine
(I would
> say "magazines", but they all basically coalesced into one),
and kits
> are available from the local "hobby" retailers. >>I agree New Micros is great. > Mind you, I too still have an NMI system of great
antiquity, unused
> after 10 years or so. I'm about to locate it soon - major house
> upheaval. Its main lack for my purpose (house controller) is
of all
> things - a RTC.
>
> The PICAXE is within its limits, a dev system on a chip -
like a
> Rabbit but less sophisticated (and much, much cheaper). It
has an
> interpreter (token code), doesn't run particularly fast, but
contains
> all the primitives for debounce, PWM, analog estimation,
timing, LCD,
> I²C & DOW (I think), so for simple logic replacement and
rapid one-off
> development, it is very effective. The version likely useful
in this
> case is an 8-pin chip - that is, 5 or 6 I/O, retailing about
A$4. Since
> the concept is to use virtually *no* "glue" logic, it works
quite well
> on Vero or a "breadboard" PCB which simply expands DIL to pads.
>
> Low-end chips can self-clock with modest stability, larger
ones can or
> must use one or two crystals. They are in fact simply
F-series PICs
> programmed with the interpreter, interpreting token code from
EEPROM
> which can alternatively store data. One is warned not to put
them in a
> "real" PIC programmer and erase them because you lose the
interpreter
> (irretrievable because it is proprietary)!
>
> Not quite the same as running FORTH, to which you can talk
with a
> terminal emulator (or straight terminal).
>
> Speaking of interrupts, and echoing all previously written,
it might
> seem that instructors fail to make it clear that interrupts
are actually
> for interfacing *not* to the "real world" at all, but to
logic chips
> (generally: peripherals, and *only* through these to the
"real world").
> Obviously, this needs to be stressed. Very few "real world"
devices
> indeed have the (time) resolution to deserve service at
interrupt level.
>
> Students, having been taught that interrupts provide "fast"
service,
> are obviously not in a mindset to conceptualise that "fast"
to the
> microprocessor, is nearly a million times what it means in
human terms -
> because that is how fast the MCU cycles.
It went a lot slower than pland becuse it required an method of
using a computer to find the path water flowed over land and no
one had done that before. I finaly got a hint in Mathamtical
Rectations in Scintific American that mazes could be solved by
srarting at an opening a the edge and working down hill to the
lowest the way to each and ever blind end of the maze or out of.
So I tuned the data into a maze by sroting it for elevaton and
startng with the highest point and when I hit a dead end mark
the path back until came to anthoer path or ran off the plot.
Then I started at each and every point around the edge and
recuively climbing to the to

Paul B. Webster VK2BZC wrote:
> On Fri, 2005-07-08 at 20:05 -0500, Mike McCarty wrote: >>I wonder where the original poster went in all the dust? > It appears (he's told me,) he's been intensively researching the
> PICAXE.
>
> Over here, it's far easier to pick up than anything HC11, HC12 or such
> - it's the current darling of the local electronics magazine (I would
> say "magazines", but they all basically coalesced into one), and kits
> are available from the local "hobby" retailers. >>I agree New Micros is great. > Mind you, I too still have an NMI system of great antiquity, unused
> after 10 years or so. I'm about to locate it soon - major house
> upheaval. Its main lack for my purpose (house controller) is of all
> things - a RTC.
>
> The PICAXE is within its limits, a dev system on a chip - like a
> Rabbit but less sophisticated (and much, much cheaper). It has an
> interpreter (token code), doesn't run particularly fast, but contains
> all the primitives for debounce, PWM, analog estimation, timing, LCD,
> I²C & DOW (I think), so for simple logic replacement and rapid one-off
> development, it is very effective. The version likely useful in this
> case is an 8-pin chip - that is, 5 or 6 I/O, retailing about A$4. Since
> the concept is to use virtually *no* "glue" logic, it works quite well
> on Vero or a "breadboard" PCB which simply expands DIL to pads.
>
> Low-end chips can self-clock with modest stability, larger ones can or
> must use one or two crystals. They are in fact simply F-series PICs
> programmed with the interpreter, interpreting token code from EEPROM
> which can alternatively store data. One is warned not to put them in a
> "real" PIC programmer and erase them because you lose the interpreter
> (irretrievable because it is proprietary)!
>
> Not quite the same as running FORTH, to which you can talk with a
> terminal emulator (or straight terminal).
>
> Speaking of interrupts, and echoing all previously written, it might
> seem that instructors fail to make it clear that interrupts are actually
> for interfacing *not* to the "real world" at all, but to logic chips
> (generally: peripherals, and *only* through these to the "real world").
> Obviously, this needs to be stressed. Very few "real world" devices
> indeed have the (time) resolution to deserve service at interrupt level.
>
> Students, having been taught that interrupts provide "fast" service,
> are obviously not in a mindset to conceptualise that "fast" to the
> microprocessor, is nearly a million times what it means in human terms -
> because that is how fast the MCU cycles.




(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Paul B. Webster VK2BZC wrote:

>On Fri, 2005-07-08 at 20:05 -0500, Mike McCarty wrote: [snip]

>>I agree New Micros is great.
>>
>>
>
> Mind you, I too still have an NMI system of great antiquity, unused
>after 10 years or so. I'm about to locate it soon - major house
>upheaval. Its main lack for my purpose (house controller) is of all
>things - a RTC. They make several with a RTC. My NMIY-020 has one on it. In any case,
single-chip '11 designs can be *really* easy. I did an expanded mode
in an afternoon with 32K RAM, 32K EEPROM (with 8K blocks
disableable) and RS-232 I/F on board. So the '11 isn't particularly
difficult to design and build with. I just used point-to-point on a
vectorboard.

> The PICAXE is within its limits, a dev system on a chip - like a
>Rabbit but less sophisticated (and much, much cheaper). It has an
>interpreter (token code), doesn't run particularly fast, but contains
>all the primitives for debounce, PWM, analog estimation, timing, LCD,
>I²C & DOW (I think), so for simple logic replacement and rapid one-off
>development, it is very effective. The version likely useful in this
>case is an 8-pin chip - that is, 5 or 6 I/O, retailing about A$4. Since
>the concept is to use virtually *no* "glue" logic, it works quite well
>on Vero or a "breadboard" PCB which simply expands DIL to pads. Sounds like a good deal. Something like the Stamp. It's hard to beat the A$4
(that would be about $2 USD, IIRC) price. Especially for newbies, having
debounce already done lets one get on with designing the "guts" of the
project.

I like the '11 partly because I have about 100 of them lying around, many
with BUFFALO in them.

> Low-end chips can self-clock with modest stability, larger ones can or
>must use one or two crystals. They are in fact simply F-series PICs
>programmed with the interpreter, interpreting token code from EEPROM
>which can alternatively store data. One is warned not to put them in a
>"real" PIC programmer and erase them because you lose the interpreter
>(irretrievable because it is proprietary)! Oh, so it *is* a Stamp, more or less.

> Not quite the same as running FORTH, to which you can talk with a
>terminal emulator (or straight terminal). <shudder> Forth, yes, Forth, I recall that language....

> Speaking of interrupts, and echoing all previously written, it might
>seem that instructors fail to make it clear that interrupts are actually
>for interfacing *not* to the "real world" at all, but to logic chips
>(generally: peripherals, and *only* through these to the "real world").
>Obviously, this needs to be stressed. Very few "real world" devices
>indeed have the (time) resolution to deserve service at interrupt level. Most never discuss real time at all. I'm pretty disgusted by the recent
crops
coming from, yes even Grad School. Can you believe it? A job applicant
with a Masters of Science degree who doesn't know what "debounce" means.

I've had discussions on a couple of newsfeeds where people don't even
understand why an interrupt is undesirable on real time systems. Polling
is always the way to go if you can do it. An interrupt is sometimes just the
right thing. But it should do as little as possible, and then schedule a
task
to handle the rest. Otherwise, the scheduler is not in control of the CPU
enough of the time to make sure deadlines get met.

> Students, having been taught that interrupts provide "fast" service,
>are obviously not in a mindset to conceptualise that "fast" to the
>microprocessor, is nearly a million times what it means in human terms -
>because that is how fast the MCU cycles. >
Yes, even a very slow processor is very fast by human standards. Like
my '11 projects. I have a 2MHz processor (8MHz clock). Most instructions
take 2 - 5 cycles. S-L-O-W by today's standards. But think in human terms,
most instructions take 1 - 2.5 MICROseconds.

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Jul 9, 2005, at 9:39 AM, Mike McCarty wrote:

> <shudder> Forth, yes, Forth, I recall that language....

Forth is absolutely brilliant. With very little assembly one can
create a Forth system on-chip to develop code self-hosted on the target.

I wouldn't recommend building new using Forth, but it is one of those
fields of study any well-rounded engineer working in the embedded
market should spend 3 months to understand inside and out.

One of the biggest problems with Forth is that its a "write only"
language. Its very hard to write Forth that one can read and
understand a month or year later.

About 10 years ago I had several NMI HC11 Forth boards to use for
prototyping. Was planning on using a Benchmarq RTC module but the
data sheet left some timing questions unanswered and the phone tech
support repeatedly insisted his answer was correct, but it was stated
in such a way it was clear he didn't understand the question. So in
less time than I spent on the phone I wired one up several different
ways on the proto space on an NMI board. Then in exercised the module
in Forth and got my answers.

Sure enough, the order of certain signals didn't matter so long as
enough time lapsed from the last before expecting data valid. Product
has been in production for over 10 years now without an issue.

--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Sat, 2005-07-09 at 11:38 -0500, David Kelly wrote:
> Forth is absolutely brilliant. With very little assembly one can
> create a Forth system on-chip to develop code self-hosted on the target.

It is as well to remember for what FORTH was "invented". It was for
real-time control of (electro-)mechanical systems. For that function,
it remains superb, though on a fully-fledged PC-based system, you would
no doubt use Python.

FORTH - on a microcontroller - requires certain primitives to run
efficiently (yes, I know people have fudged it on a PIC, and it worked
OK on a 6502!). It happens that those primitives are present on the
6809/ 68HC11, so those processors are perfect for implementing it (as is
the 80x86). Ergo, New Micros.

> I wouldn't recommend building new using Forth, but it is one of those
> fields of study any well-rounded engineer working in the embedded
> market should spend 3 months to understand inside and out.

OK, so you have all your hardware correctly(?) interfaced to your PC
or microcontroller, you run the smoke test, now, what other language
facilitates incremental testing of one part after another, thence
setting up of control subsystems and construction of a complete
application? There is virtually no compile cycle involved - it compiles
incrementally as you write and test the code.

> One of the biggest problems with Forth is that its a "write only"
> language. Its very hard to write Forth that one can read and
> understand a month or year later.

Actually, it's more *self*-documenting than many languages, and has
perfectly adequate provisions for commenting.

> About 10 years ago I had several NMI HC11 Forth boards to use for
> prototyping. ... Then in exercised the module in Forth and got my
> answers.

Exactly - that's how it works.

I probably *could* use something else (with difficulty), but still use
F-PC on a machine with a parallel port card (replaceable) to rig
experiments/ testing for various devices or assemblies - such as
displays, encoders, interface cards, keyboards ...
--
Cheers,
Paul B.



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Sat, 2005-07-09 at 09:39 -0500, Mike McCarty wrote:
> They make several with a RTC.

I'm sure they do - now, but it means I have to go and buy another.
That's the trick!

> Sounds like a good deal. Something like the Stamp.

It is, and it isn't a Stamp. It utilises the fact that the later PICs
have all the resources on-board, and far more resources than the old
Stamp. And since the Stamp code was proprietary, it's a(nother
proprietary) re-write of both the interpreter firmware, and the
development system. It certainly *works* like a Stamp.

> It's hard to beat the A$4 (that would be about $2 USD, IIRC) price.

As it currently goes, A$4 is almost exactly US$3, except for the
exchange and shipping costs, of course.

> Especially for newbies, having debounce already done lets one get on
> with designing the "guts" of the project.

Perhaps it's even more important that it is actually *documented* as
an essential consideration.

> An interrupt is sometimes just the right thing. But it should do as
> little as possible, and then schedule a task to handle the rest.
> Otherwise, the scheduler is not in control of the CPU enough of the
> time to make sure deadlines get met.

Alternately expressed, there is almost always something *else* that
was happening, that really needs to be finished before dealing with
"user" input, or a (slow) mechanical device.

--
Cheers,
Paul B.



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Paul B. Webster VK2BZC wrote:

>On Sat, 2005-07-09 at 09:39 -0500, Mike McCarty wrote: >>They make several with a RTC.
>>
>>
>
> I'm sure they do - now, but it means I have to go and buy another.
>That's the trick! I knew that, just letting the rest of the world know, as well. The NMIY-020
also has a fully debounced matrix keyboard interface for, IIRC, 16 buttons.

[snip]

[cocerning PICAXE]

>> Especially for newbies, having debounce already done lets one get on
>>with designing the "guts" of the project.
>>
>>
>
> Perhaps it's even more important that it is actually *documented* as
>an essential consideration. Yes. I find that it is invariably the case that newbies connect a dry
contact
to an interrupt, press a button, and then wonder why they got a stack
overflow
or something wierd. I had a guy whose job it was to insert faults in a
memory
board tell me my driver didn't work for fault isolation/recovery when he
inserted a fault into the memory board. He put a dry contact across one of
the driver chips and pressed the button. My software declared that the
board had a completely unrecoverable error, and removed it from service,
switching to running simplex with its mate only, then began diags, and
then restored it to service after refilling content. His complaint was that
it should not have removed the board from service when he inserted
"only" one error. My driver counted more than 48 consecutive errors
on that board. >
>>An interrupt is sometimes just the right thing. But it should do as
>>little as possible, and then schedule a task to handle the rest.
>>Otherwise, the scheduler is not in control of the CPU enough of the
>>time to make sure deadlines get met.
>>
>>
>
> Alternately expressed, there is almost always something *else* that
>was happening, that really needs to be finished before dealing with
>"user" input, or a (slow) mechanical device. Yes. Or even a fast device. My point is that having execution contexts out
of control of the scheduler makes hitting deadlines difficult. This can be
due to any number of reasons. Your statement is nicely put, though. I like
it.

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
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!



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Paul B. Webster VK2BZC wrote:
> On Sat, 2005-07-09 at 11:38 -0500, David Kelly wrote:
>
>>Forth is absolutely brilliant. With very little assembly one can
>>create a Forth system on-chip to develop code self-hosted on the target. > It is as well to remember for what FORTH was "invented". It was for
> real-time control of (electro-)mechanical systems. For that function,
> it remains superb, though on a fully-fledged PC-based system, you would
> no doubt use Python.
>
> FORTH - on a microcontroller - requires certain primitives to run
> efficiently (yes, I know people have fudged it on a PIC, and it worked
> OK on a 6502!). It happens that those primitives are present on the
> 6809/ 68HC11, so those processors are perfect for implementing it (as is
> the 80x86). Ergo, New Micros. >>I wouldn't recommend building new using Forth, but it is one of those
>>fields of study any well-rounded engineer working in the embedded
>>market should spend 3 months to understand inside and out. > OK, so you have all your hardware correctly(?) interfaced to your PC
> or microcontroller, you run the smoke test, now, what other language
> facilitates incremental testing of one part after another, thence
> setting up of control subsystems and construction of a complete
> application? There is virtually no compile cycle involved - it compiles
> incrementally as you write and test the code. >>One of the biggest problems with Forth is that its a "write only"
>>language. Its very hard to write Forth that one can read and
>>understand a month or year later. > Actually, it's more *self*-documenting than many languages, and has
> perfectly adequate provisions for commenting. >>About 10 years ago I had several NMI HC11 Forth boards to use for
>>prototyping. ... Then in exercised the module in Forth and got my
>>answers. > Exactly - that's how it works.
>
> I probably *could* use something else (with difficulty), but still use
> F-PC on a machine with a parallel port card (replaceable) to rig
> experiments/ testing for various devices or assemblies - such as
> displays, encoders, interface cards, keyboards ...

Having FORTH burned in ROM on a 68HC11 boar and the hardware
test programs in FORTH let find out if the problem is hardware
or software very quickly.

I have use FORTH to interface the first Intel CAN chip to a
Motorola bus, develop vehicle tracking software for a fellow
that knew noting about computer programming in Vancouver BC from
Oklahoma but we cloud use FORTH to debug problems and develop
feature on the pone. I did a similar project with a Chinese
programmer that barely spoke English and I speak no Chinese at all.

I don't think any of these projects would have been possible
with a compiled language with tools I had at the time.

I plan on using it a again to develop sepctophotmeter on New
micros Tiny Arm. I could do it in C but I have used GCC a lot
and once I have the interrupts worked out and and the timing and
other problems solve I will convert it to C and not spend all
the time in edit, save, compile, link, load, run crash cycle
that C takes. When I can edit one value and copy and paste a
few lines to the terminal program.

I have never looked at FORTH as a final product and I probably
should. But there is lot pressure for management against it
because there are so few of us that work with it. Since I wear
two hats I usually rewrite the program in C. As the baker told
me when I was trying to sell Radio Shack computers nobody got
fired for buying IBM and I don't have to defend my choice of
using C. But when start from scratch with a new CPU and new hard
were FORTH is a lot more productive than anything else.

Gordon

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )