16F877A or a pic mcu from new series(pin compatible) for simple medical device??

[okmn]

a medical device that will be used in beauty salons and hospitals(not a complex device that can have fatal consequences in the event of a fault or malfunction) , would you use the pic16f877A, or would you use another model of the new series "pic mcu" compatible with its pins?
(I am more dominant in PIC16f877A).
if you recommend a pic mcu from the new series, which new type of PIC mcu will be pin compatible?

[top204]

A tricky question!

If the application works well on a PIC18F877A device, without having to perform tweaks to make it work well, it could be stated that "The device is mature and does not have any silicon issues"

However, if you have to tweak the code to workaround some of the issues with the older devices, then move to an older 18F device that will work "out of the box". :-) Still a mature and stable device, but has the extra features required.

[okmn]

thanks top204,

I asked this question because 877a is an easily available product in the markets here, but the price is getting expensive now !!

I've never worked with the pic18 series before (but I know I need to switch to it)
But should I switch from the new pic16f1 to a model? (because their prices are even cheaper and there are many new features.
such as ZCD.
In my current project, I did it with the ZCD op-amp that I used in the "trigger by phase angle" process.

[top204]

My advice for a product that has medical uses is to use a more mature device, but not a device that is now, very much, out of date. The original 16F, standard 14-bit core, devices are also quite expensive because they are now legacy devices and Microchip will not be making them on-mass

Microchip seem to bring new devices out without full testing. The amount of errata documents for every new device tells that story. I've also found some very big anomalies in new devices when I have been writing code generation for them in the compilers. That's when I put them on hold and do not add them to the compilers until the device is stable, otherwise, the compilers get the blame for them not working correctly. :-)

A device that has been available for a few years will have had most of its silicon issues corrected, but not all of them, so choose a device that has been available for approx 2 to 8 years.

[okmn]

dear top204,

may i ask it from you direkt model number (i know this will run into laziness a bit !!!)
however No one around me knows the pic better than you.
can you give a pic model name which is exactly 16F877A pin compatible and proven, from the new series ... please!!

actually I want to start learning the pic18q series but "I'm really waiting for your newly updated positron with its pdf manual"

[John Drew]

I've used the 18f4620, 18f4680 and 18f4685 as my original 16f877 project grew. Pin outs are the same and enabled me to make the project more capable as I needed more memory. They are relatively old chips but are stable and reliable.
John

[See_Mos]

My upgrade path was 16F877 to 18F452 then 18F4520 but the 452 is now about 20 years old and the 4520 about 13 years old.

[Maxi]

16F877A-->18F44K22

https://www.microchip.com/wwwproducts/en/PIC18F44K22

[Amod]

Iam using 16f886 and 16f877A for my projects. How old are they?

[RGV250]

Noah used them on his ark

Bob

[okmn]

16F877A-->18F44K22

https://www.microchip.com/wwwproducts/en/PIC18F44K22

thanks.

18F44K22 ,when it happend old !
it says Newer Device Available PIC18F45Q10..... ...This product is recommended for safety critical applications targeting both industrial and automotive products (IEC 61508 and ISO 26262)
Will these latest new pics be stable as les said?

[top204]

Forget what Microchip write about their own devices! Remember, they are sales people so they will exaggerate all they can, without it being legally classed as lies. :-) Just as all advertising does.

Instead, listen to what "actual" people who have used the devices for years have to say. All devices come under some spec or other, but what are they like out in the real world and not in some laboratory having artificial aging processes done to them?

The older devices are rather expensive, and the newer devices are the least expensive because Microchip want them to sell, but...... they are new so they may have issues. Go with a mature 18F device that others have used out in the field succesfully. A nice device that has been around for a few years and is inexpensive and has good RAM, Flash and peripherals is the PIC18F27K42, or PIC18F47K42 for a 40-pin device. But that is just my opinion, and is why I chose the PIC18F27K42 device for the Positron board. 64MHz operation, 8K RAM, 128K flash, 1K EEPROM, all sorts of peripherals, and an operating voltage from 2.3V to 5.5V.

[okmn]

After your nice happy news, no more words for me ... thank you dear Les...PIC18F27K42,and PIC18F47K42

If you did not have this note, I would choose something from the 18fq series (to start learning) and I was actually waiting for the positron ..

but I still need another PIC, which I can get 5 pwm outputs hardware at the same time(5 frequencies and duty-cycle values will be adjusted separately AND MİN. 2 UART);
and for this, there is still only one pic(I was waiting for something to come out of the new series BY Microchip), and it is PIC16f1527,
in fact , I OPENED A TOPIC FOR A FEW simple SAMPLE CODE IN THIS NEW FORUM FOR PIC16F1527, BUT THERE IS NO SUPPORT YET...

and wurth used this pic in his product, which is seen at this address..this means that it is a stable PIC (I think it is a product that can get your approval)how about?
https://www.we-online.com/catalog/en/VDRM_MULTICOLORLEDDRIVER
Reference Design MagI³C Multi Color LED Driver

[tumbleweed]

PIC18F27K42,and PIC18F47K42

Personally I'm not very fond of the K42 family. That was one of the first with the MOVFFL instruction.

They located all of the SFR registers into memory that can't be accessed with MOVFF,
and require the use of the  3-word MOVFFL instruction which makes the code larger and slower.

Plus, they changed many of the hardware peripherals, so I2C and SPI function very different from the old devices and aren't code compatible.

[top204]

I used to think that of the PIC18FXXK42 devices as well, until I started writing code for them.

The Movffl mnemonic is required for all RAM above address 4096, so "all" the new devices with extra RAM need it, but just as with all other 18F devices, the Movlb mnemonic is still required to set the RAM bank for other mnemonics for variables not in user or SFR (Special Function Registers) access RAM, and indirect RAM is still linear and requires no RAM bank switching. The SFRs still have a section that are in Access RAM, just like all other 18F devices, and all the other, newer, 18F devices have SFRs not in access RAM, so they still need the RAM bank set, or the Movff mnemonic used.

I have optimised the compiler even further for these devices, so the Movffl mnemonic is not the first choice, as other compilers do not do, and they use the Movffl mnemonic as standard. If possible, the Movff mnemonic is used, or the Movf Var,w/Movwf Var mnemonics are used if both source and destination are in User and SFR Access RAM, and if one is in Access RAM and the other is in normal RAM, and below the address 4096, the standard  Movff mnemonic is used etc.... In "real life" and because of the compiler's optimisations, the code size differences are not that noticable, but the extra features the device gives and the extra RAM are worth the slight differences, and this will be the same for "all" new 18F devices with extra RAM above address 4096. Also, the "lead" time for the new, larger RAM size, PIC18FxxQxx devices is about a half to three quarters of a year now!

In a standard program, approx 99% of the code is for standard variables in standard RAM, and only a very small part of it is using peripheral SFRs that are loaded and read "directly" (using the Movff mnemonic), so the code differences on the vast majority of programs will not actually be noticable. Heck..... Some compilers do not even bother with the Movff mnemonc and instead use the Movf/Movwf mnemonics all the time, with RAM bank switching around them that wastes time and code space, because they use the same code generator for all devices, instead of specialising to a particular devices family, because that takes more research and work doing to the code generator.

Also, if you use arrays and Strings on an 18F device or enhanced 14-bit core device, make them Heap types and they will reside in higher RAM above the standard variables, and because they mostly operate indirectly, no RAM bank switching is required for them so it doesn't matter what address they reside in, above or below address 4096. Or use "Declare Auto_Heap_Arrays = On or Off" and/or "Declare Auto_Heap_Strings = On or Off" and the compiler will do that for you automatically. More good, new, additions to the compiler. :-) I made the new operation of Arrays and Strings as declares to keep backward compatability, so they default to the way things used to be. That sounds like a song title. LOL

The SPI peripheral is actually quite good on the K42 devices, and follows the same strategy as all the newer 18F devices, and offers faster, and more flexible, SPI than the older generation of devices. I have created a library for it for the Positron board. For example, a procedure from the Positron SPI library is:

Code Select Expand

'--------------------------------------------------------------------------------
' Initialise the SPI1 peripheral
' Input     : pMode holds the mode of the SPI interface (0 to 3)
'           : pSpeed holds the speed of the SPI (in KHz)(With the calculation, the maximum frequency with a 64MHz device is 32000 KHz)
' Output    : None
' Notes     : The sampling is set to middle, and the 8-bits are set to be sent MSB first
'
Proc HSPI1_Init(pMode As Byte, pSpeed As HSPIx_wSpeed)
    HSPI_CalcSSPxBAUD(HSPIx_wSpeed)     ' Calculate the value to place into SSP1BAUD for the frequency required for the SPI1 peripheral
    SPI1CON0 = %10000010           
    If pMode = 1 Then                   ' Is SPI Mode 1 required?
        SPI1CON1 = %00000000            ' Yes. So SMP Middle, CKE Idle to active, CKP Idle Low, Active High

    ElseIf pMode = 2 Then               ' Is SPI Mode 2 required?
        SPI1CON1 = %00111100            ' Yes. So SMP Middle, CKE Active to idle, CKP Idle High, Active Low

    ElseIf pMode = 3 Then               ' Is SPI Mode 3 required?
        SPI1CON1 = %00100000            ' Yes. So SMP Middle, CKE Idle to active, CKP Idle High, Active Low

    Else                                ' Otherwise it is SPI Mode 0. So...
        SPI1CON1 = %01000000            ' SMP Middle, CKE Active to idle, CKP Idle Low, Active High

    EndIf
    SPI1CON2 = %00000000
    SPI1CLK =  %00000000                ' CLKSEL FOSC
    SPI1BAUD = pSpeed                   ' Place the value for the speed into SFR SPI1BAUD
EndProc

Which will setup the SPI peripheral for each SPI mode, and the SPI speed required. Then once the SPI interface is chosen, the pins can be chosen for the SPI by using the PPS peripheral in the main program's Setup procedure, and I have also made SPI PPS manipulation a lot simpler with some preprocessor meta-macros in the SPI library for each pin and PPS SFR.

Then to write or read from the SPI interface:

Code Select Expand

'--------------------------------------------------------------------------------
' Write 8-bits to the SPI1 interface
' Input     : pData holds the byte to write to the SPI1 interface
' Output    : None
' Notes     : None
'
Proc HSPI1_Write8(pData As HSPIx_bData)
    SPI1TCNTL = 1
    SPI1TXB = pData
    While PIR2bits_SPI1RXIF = 0: Wend
EndProc

'--------------------------------------------------------------------------------
' Read 8-bits from the SPI1 interface
' Input     : None
' Output    : Returns the byte read from the SPI1 interface
' Notes     : None
'
Proc HSPI1_Read8(), HSPIx_bData
    SPI1TCNTL = 1
    SPI1TXB = 0
    While PIR2bits_SPI1RXIF = 0: Wend
    Result = SPI1RXB
EndProc

The I²C peripheral is the same as on all newer devices, in that they have removed the MSSP peripheral and now have a dedicated I²C peripheral.  I am creating a Positron library for the I²C peripheral, but it does have a bit of a steep (ish) learning curve because they have gone over-board with what it can do, just as they have done with the ADC peripheral on new devices.

It's just a shame it only has a 5-bit DAC, and not a 12-bit or 16-bit DAC, but these are on PIC24 and dsPIC33 devices, for now.

For an eBook I am creating, I have written a few libraries for different colour OLED and TFT displays using the SPI library on a Positron board, and the displays are blisteringly fast, even with SPI. I also created a procedure, which I am rather proud of, within the OLED libraries, that prints any text sent to it in the centre of the display, regardless of the font size or type used or fixed or proportional. :-) It makes code creation so much faster because without it, I had to run many tests and move the X position of the text accordingly to get it centred on the LCD, then when the font was changed or the text was changed, do it again and again and again. LOL But not anymore! A single call to PrintAtCentre(Ypos, "Hello World") or PrintAtCentre(Ypos, "MyVar = " + Str$(Dec, MyVar)) does all the work required by counting the pixels used in each font character and the whole string being sent, then calculating the offset, all in a single procedure that operates blisteringly fast because of the compiler. :-)

[tumbleweed]

Thanks for the tips.

One thing they did fix in devices released after the K42 was to move the SFRs down to the beginning of memory so you no longer need the MOVFFL instruction to get at them.

And, some even added legacy control of the I2C peripheral back in.
 

[top204]

The movement of the SFRs to the lower RAM banks is a good improvement, but still only some of them are in Access RAM, so bank switching is still required, and with the optimisations I had done with the compiler they do not make that much difference.

And, some even added legacy control of the I2C peripheral back in.

Unfortunately, that isn't quite correct George. The very first 18FxxQ10 devices were based, loosely, upon the earlier 18FxxK types, but the newer Q microcontrollers all have a seperate I²C and SPI peripheral and have the capability of more RAM.

The ultra new PIC18F06Q41 and PIC18F16Q41 devices are really quite nice and have packages as small as 14-pins, yet still enough RAM and flash and peripherals to make them useful. I'm busy re-writing the compiler's assembly for these devices because they use a different assembler program and the directives are very different, and it has to use the linker as well. Something similar to what I had to do for Proton24, and it has to be invisible to the user. So if an ultra new device is chosen, the compiler uses the new assembler code and program, but if a current device is chosen, it has to use the standard assembler code and program. Phew!

[Tenaja]

I started with the 16f877, too. I've used the newer 16f18xx devices in a few medical devices, with proton, and can easily recommend them. They are a lot cheaper, and have 49 instructions... Iirc, the '877 is 35ish, so it takes more code.

While microchip is good at keeping a chip in production, those as old as the 877 (I think over 20 years, and not recommended for new designs) might start to get hard to find.

I haven't seen many benefits of the 18f's, unless the newer 16f's don't have enough memory or speed for you.

The reality is, if you are good enough at debugging to find errata, any pic will do... But I agree that 2 years old would likely be my minimum, too.