PIC16F54A

[GatorGuy]

I am looking to build this circuit http://www.rentron.com/PIC16F84.htm and would like to use the PIC16F54A instead of the 16F84. It seems that the pins are the same but the 16F54 has less memory. Does anyone else see anything different that I should consider? Or would it even work with the same schematic?

 

[motion]

You must have really compelling reasons for replacing the PIC16F84A with a PIC16F54. There are better substitutes like the PIC16F627.

The only reason I see is the price. Microchip prices for 100+ qty.:

PIC16F54 - $1.38
PIC16F627 - $1.95
PIC16F84A - $3.78

However, there are also technical problems to surmount to use the PIC16F54. Besides the smaller program space of 512 instruction words, the ff. are some more differences.

1. The PIC16F54 is not object code compatible with the PIC16F84. The '54 has a 12-bit instruction width while the '84 is 14-bits wide.

2. There is no RA4 on the 16F54. Getting the bit state of the serial data is tricky at best.

3. There are no interrupts on the 16F54. You might have to poll the port at high scan rate to accurately detect leading edge of the start bit. This could limit the highest baud rate you can receive data.

4. The call stack is only two levels deep.

 

[Nigel Goodwin]

However, there are also technical problems to surmount to use the PIC16F54. Besides the smaller program space of 512 instruction words, the ff. are some more differences.

1. The PIC16F54 is not object code compatible with the PIC16F84. The '54 has a 12-bit instruction width while the '84 is 14-bits wide.

I've not checked, but presumably the F54 is a FLASH replacement for the OTP 16C54, which is an old 12 bit PIC?.

2. There is no RA4 on the 16F54. Getting the bit state of the serial data is tricky at best.

I don't see any relevence to RA4?, RA4 is simply an open-collector output, if you don't require that (and not much does), it won't cause any problems.

3. There are no interrupts on the 16F54. You might have to poll the port at high scan rate to accurately detect leading edge of the start bit. This could limit the highest baud rate you can receive data.

Not a problem either, you're unlikely to be wanting to do excessively high serial speeds - not much point with a PIC, you've got no where to store large quantities of data (and 115kbps can be done in software without interrupts!). However, having no interrupts could well cause you other problems if trying to convert 14 bit code to 12 bit.

4. The call stack is only two levels deep.

That's likely to be one of the biggest problems, requiring substantial rewriting!.

However, as I see it, the biggest problem is the website he quoted!, it's all in BASIC, does he have a BASIC compiler that targets the 16F54? - it seems pretty unlikely?.

My advise is to go for the 16F627/8 which is the replacement for the F84.

 

[motion]

I don't see any relevence to RA4?, RA4 is simply an open-collector output, if you don't require that (and not much does), it won't cause any problems.

Oh yeah? The serial data line is connected to pin3 of the chip. It is supposed to be connected to bit4. On the '84 in the i/o expander, it is configured as input not output. Bit4 of portA in the 16F54 will always read as '0'.

 

[Jay.slovak]

Why don't you use 16F627 and drop that 16F54 or 84. simple deal. Is there a special need for 54 ?

 

[Nigel Goodwin]

I don't see any relevence to RA4?, RA4 is simply an open-collector output, if you don't require that (and not much does), it won't cause any problems.

Oh yeah? The serial data line is connected to pin3 of the chip. It is supposed to be connected to bit4. On the '84 in the i/o expander, it is configured as input not output. Bit4 of portA in the 16F54 will always read as '0'.

Big deal! - stick it on a different pin! - that's the least of the problems!.

 

[motion]

Big deal! - stick it on a different pin! - that's the least of the problems!.

Yeah that answer would be outside the scope of the threadstarter's question: "would it even work with the same schematic?". Let's limit the discussion to this or else this will get out of hand.

 

[GatorGuy]

For the most part the only reason for the swap is price. I will stay away from the 16F54 if there is that much of a difference. The $2 or so won’t break the bank. Thank you for all of the input. As far as the programming language I am going to be using VB6 using MSCOM. As far as this schematic I only have one use for this circuit. I only need to be able to send commands to it turning relays on and off. I wont have any need to store any programs on the chip.

 

[upand_at_them]

If you don't mind the difference in price then get a 16F628A. It's much better and cheaper than the 16F84A.

Microchip s budgetary price:
16F54 $1.25
16F84 $4.39
16F84A $3.42
16F627 $1.42
16F628 $2.12
16F628A $1.61 (best chip of this lot)

Mike

 

[Nigel Goodwin]

For the most part the only reason for the swap is price. I will stay away from the 16F54 if there is that much of a difference. The $2 or so won’t break the bank. Thank you for all of the input. As far as the programming language I am going to be using VB6 using MSCOM. As far as this schematic I only have one use for this circuit. I only need to be able to send commands to it turning relays on and off. I wont have any need to store any programs on the chip.

VB6 is only for programming the PC, how are you going to program the PIC!. The webpage you showed was using PICBASIC, which you would need to buy in order to program the PIC.

So although I wouldn't normally advise buying the obselete F84 (because there's no advantage to doing so), in this case by doing that you could use the precompiled HEX file available on that webpage.

However, the program is only trivial, and would be easy to write in assembler, which is free!.

I presume you have a PIC programmer, in order to program the PIC?.

 

[GatorGuy]

I am still researching using the MSCOMM function but I believe you can send the pin number and pin state to change the pin from high to low or low to high. Correct me if I am wrong. I am pretty new with the PIC's as you can tell. Again thank you for all of the help. And no I do not have a programmer as of yet but that will before building it. I also have examples of the BASIC code to program the PIC.


MSComm1.Output = Chr$(255) & Chr$(PinNumber) & Chr$(PinState)

 

[Nigel Goodwin]

I am still researching using the MSCOMM function but I believe you can send the pin number and pin state to change the pin from high to low or low to high. Correct me if I am wrong. I am pretty new with the PIC's as you can tell. Again thank you for all of the help. And no I do not have a programmer as of yet but that will before building it. I also have examples of the BASIC code to program the PIC.


MSComm1.Output = Chr$(255) & Chr$(PinNumber) & Chr$(PinState)

That doesn't look right?, I'm presuming '&' is a logical AND?, you need '+' to send the three bytes of data. I can't comment on the use of MSCOMM itself as I've never used it (nor VB).

Examples of the BASIC code for the PIC won't help unless you have a copy of PIC BASIC - which is a (fairly expensive) commercial program.

 

[upand_at_them]

I am still researching using the MSCOMM function but I believe you can send the pin number and pin state to change the pin from high to low or low to high. Correct me if I am wrong.

You're wrong.

You can't change the state of any pin of the serial port. On a parallel port you can, but not a serial port. I've written several VB apps that use the serial port via the MSCOMM control. All you do is put data into the buffer and the UART sends it. You can turn on/off the handshake lines, but I don't think that's what you want to do.

Also, keep in mind that the serial port of a PC is not at logic levels. You can destroy a PIC by assuming so.

Mike

 

[GatorGuy]

I am still researching using the MSCOMM function but I believe you can send the pin number and pin state to change the pin from high to low or low to high. Correct me if I am wrong. I am pretty new with the PIC's as you can tell. Again thank you for all of the help. And no I do not have a programmer as of yet but that will before building it. I also have examples of the BASIC code to program the PIC.


MSComm1.Output = Chr$(255) & Chr$(PinNumber) & Chr$(PinState)

That doesn't look right?, I'm presuming '&' is a logical AND?, you need '+' to send the three bytes of data. I can't comment on the use of MSCOMM itself as I've never used it (nor VB).

Examples of the BASIC code for the PIC won't help unless you have a copy of PIC BASIC - which is a (fairly expensive) commercial program.

I was just using that VB code for an example. I have some others that are alot better. What I gave was only part of a program I found.

Something like MSComm.output = "QUALIFIER,PINNUMBER,PINSTATE".
Again this is just an example. From the information I found I can send the qualifier number with the pin number address and pin state to the PIC to turn the PICs pins high or low. I will see if I can find more information and post it.

 

[upand_at_them]

This might be the protocol of the device you're building, but it's certainly not a feature of VB, the serial port, or your computer. That I/O expander you're building might expect that data that way, in which case your VB code might be:

Dim qualifier as variant
Dim pinnumber as variant
Dim pinstate as variant
' change the datatypes as necessary
' and convert to ASCII if needed

MSComm.Output = chr$(qualifier)
MSComm.Output = chr$(pinnumber)
MSComm.Output = chr$(pinstate)

Concatenating the chars would also work:

MSComm.Output = chr$(qualifier) & chr$(pinnumber) & chr$(pinstate)

In VB the ampersand serves to concatenate strings.

It should be pointed out that there is no difference between the above two sections of code. The first one is preferred, as it more clearly shows what is going on.

Mike

 

[Nigel Goodwin]

In VB the ampersand serves to concatenate strings.

I said I didn't use VB 8)

 

[upand_at_them]

In VB the ampersand serves to concatenate strings.

I said I didn't use VB 8)

Nigel, I wasn't picking on you. I was just stating it so people could understand the code he posted.

Mike

 

[Nigel Goodwin]

Nigel, I wasn't picking on you. I was just stating it so people could understand the code he posted.

Hi Mike,

It's OK, I didn't think you were 8)