Anyone know if using a 18F4520 works instead of the 18F452? The 452 is obsolete now according to Microchip.com and the 4520 has replaced it and is feature compatible (plus my programmer - pickkit2 - only likes the 4520).
I’ve ordered 3x 18F4520 anyway as they’re free from samples.microchip.com 
The 452 is obsolete now according to Microchip.com
Are you sure it#s really obsolete respectively on Last Time Buy? I just double checked the Microchip web site, and it just says <<not recommended for new designs>> – which is different to a Last Time Buy since the 452 is still available. Can you refer to the Microchip statement that you mentioned? LTB page or something similar?
Cheers,
Andreas
Hi,
The 18F4520 uses the Microchip EUSART rather than the standard USART found in the 18F452. All 18F family chips that use the EUSART have a silicon bug that prevents back-to-back interrupt driven transfers on the serial port. This makes them unusable for MIDI applications such as MIOS. I have not tested the 18F4520 but have no reason to believe that Microchip has resolved this problem since they have not published anything to the contrary. So, I say stay away from the 18F4520 and stick to the 18F452 which I am sure will be available for many years to come.
Regards,
Synapsys
The PIC18F4520 won’t work, I’ve already tested it: it has the same EUSART bug.
Btw.: three weeks ago I felt so bored, that I contacted the microchip support again in order to inform them, that the PIC18F4620 as well as the PIC18F4520 has the same bug. As expected they were not informed about this issue. Two days later they updated the 18F4520 errata sheet and asked me if the bug is in the sheet now (seems to be a more comfortable way than reading my previous messages) — it wasn’t
This discussion is still continuing, in the meantime I sent them two programs which allow to reproduce the bug within one second…
Best Regards, Thorsten.
Joy - I’m beginning to hate PICs after all the trouble I’ve seen with recent ones. I wish I’d stuck with big old Z80s and EPROMs/SRAM/discrete on large chunks of stripboard eating tons of juice.
Can’t use a 452 as my programmer doesn’t support it (thank you Microchip!).
My current problem is getting the oscillators to stay stable on my dev board. I’ve tried just about every cap value between 2.2pF and 100pF and the oscs die randomly. The XTAL is a known good one (10MHz). The damn thing just dies after about a minute - it’s not the WDT which is disabled and the IRQ routine just does an RETFIE straight away. It’s got to be stray capacitance as if i stick my scope (philips pm3217) near it or my finger it dies too (meaning i can’t even check the osc drive waveform to make sure it’s stable). I’m a VLSI guy by trade - stray capacitance is my middle name - so this should not be a problem!!
Awful pieces of crap!
Hello TK!
Have you tested the workaround from Microchip?
The Forum message from microchip, seems to be deleted!
Jack
There is no workaround…
The forum message still exists, just the URL has been changed (fixed)
Two days ago Microchip closed my case with following message (one of my initial questions was, what will happen with the PIC18F452)
A collegue has seen this effect also with a few other customers and reported it to the factory.
It could be verified there as well and a thorough investigation is in progress to understand the issue.
So far a solution and implementation in new Silicon is not in sight yet.
If this EUSART on PIC18F4520 is not usable in your application, continue with the PIC18F452 which is available RoHS conform as well.
Even if it is not recommended for new designs, this device can still be found in the latest price list.
Please contact your local distributor to see if they can ship or order your required quantities.
Thanks for your detailed tests.
regards
Best Regards, Thorsten.
I mean this one from Errata Sheet from PIC18F2455/2550/4455/4550.
1. Module: EUSART
When performing back-to-back transmission in
9-bit mode (TX9D bit in the TXSTA register is
set), an ongoing transmission’s timing can be
corrupted if the TX9D bit (for the next transmission)
is not written immediately following the
setting of TXIF. This is because any write to the
TXSTA register results in a reset of the Baud
Rate Generator which will effect any ongoing
transmission.
Work around
Load TX9D just after TXIF is set, either by polling
TXIF or by writing TX9D at the beginning of the
Interrupt Service Routine, or only write to TX9D
when a transmission is not in progress
(TRMT = 1).
PS: Microchip is not planing to solve this problem!
The Hardwerker from Siemens told me.
Jack
This is an older erratum which only mentions the 9bit mode…
Note that the workaround suggested there is not sufficient for continuous (back-to-back) transmissions over the MIDI interface. E.g., if a SysEx string should be forwarded which is longer than the transmit buffer, a buffer overrun will occur.
Best Regards, Thorsten.
I have a other question???
Is it possible to use this bugged chips (4550) as companion LCDs. I made a Coreboard that fits behind the S65 Display (at the moment not fully assembled).
http://www.midibox.org/forum/index.php?topic=5603.msg35504#msg35504
Jack
yes (but note that nobody has written a companion firmware yet…)
In theory it should also be possible to get the MIDI interface properly running, when an external serial transmitter is used - e.g. via the IIC interface. If Microchip is not able to fix the problem until this summer, this is propably the way I will go (even it will cost me a lot of documentation and support effort…)
Best Regards, Thorsten.
I think I have then a little problem!
IIC and hardware SPI doesn’t work at the same time, I think?
And I don’t know If Soft SPI is fast enough (I never programmed a soft SPI).
One Display needs 8 MHz.
PS: For those who wants to try:
There is a Software for PIC16LF876 for the LS020 Display from Mario.
Here is the Link:
http://www.mikrocontroller.net/forum/read-4-243641.html#286520
Jack
No, you don’t have a problem, since you don’t need a MIDI Out, and since I would prefer to use the same pins like for the BankStick for the Tx pin replacement (Soft-IIC, transfer maybe to second PIC with reliable USART, speed is fast enough, second MIDI In would also be possible).
You see: such questions will raise the need for additional documentation and support… :-/
Best Regards, Thorsten.
Thanks TK!
Now, I can work on my Companion Core Board.
Jack