Seen this chip listed as a “drop in” replacement for the 644p, but with more RAM available.
Could this be used for a Shruthi-1, but have some extra RAM for more user waves/wavetables or is the limitation more about CPU cycles?
I realise that adding more to the Shruth-1 with its limited interface adds all sorts of usability problems 
I have tried that in the past of course. The DIP 1284P suffers from a hardware bug when running at 20 MHz and when the UART0 is used, causing random memory corruption. It’s documented in a few places and regularly pops up on AVR freaks. Some tricks have been suggested (low-pass filtering the signal getting into the UART) but the problem does not entirely disappear - crashes every 20 or 30 hours of use - and of course it’s no longer a “drop in” replacement since it requires a modification of the digital control board. No go for me.
Bit of a major flaw for such a chip then. I’m sure I read about your experiments with higher spec chips on the blog before now.
In fact, I was just reading this thread and saw a rather familiar product description appear
That’s a real shame-wondered why it was so cheap on Mouser (the same price as the 644PA) and now I know 
Well the forum post above says you can “fix” it with some additional components. But such fixes may or may not work depending how you are using the chip.
The last thing you want on a kit is to have to instruct people to solder components on the surface of the board across tracks.
If I’m bored enough some day I may give it a go and see if it works.
Thanks for the information.
I used too the 1284P and his 2 UART for a simple midi merger, and I observed bored and curious crashes.
( picture of the project: http://www.flickr.com/photos/nicoo_diy/6869065600/in/set-72157629666800221 )
Now I will try will a 644P
You could try the fix, it’s only a capacitor and resistor. You could then tell us if it resolves the problem
"Issue: Atmega1284p uasrt receiver (RX0) causes unpredictable crashes / reboots.
Package in question is 40-PDIP.
Resolution: 10k series resistor in line and 100pf cap to ground. "
Actually, it seems that some 644s also has this issue but to a much lesser extent. I have a contraption on a breadboard that consistently crashed when receiving MIDI input until I put a lowpass filter on it… (same circuit worked perfectly with a 328 MCU).
Well things behave differently on a breadboard as there is unwanted capacitance between the rows.
Yes, the ATMega644p is prone to the same problem to a much, much, much lesser extent. It appears once in a while (due to tolerance excursions in chips and PCB resistance / capacitance) - in this case I suggest replacing the optocoupler by a slower one which produces soft edges (6N138).
The filter did not entirely get rid of the problem for me. I got a MIDI monitor tool running for a whole day before it crashed [vs a few minutes without the fix].
Is it the DIP version that is more prone to this or is the SMT version just as bad?
Apparently it’s the DIP version only.
Wouldn’t another option for nicoo be to clock it at 16Mhz?
If it’s for midi operation, I don’t think it’s much of a trouble. I remember reading pichenettes say that the 16 Mhz thing solved the issue.
Yeah, 16Mhz would probably work. I guess this is the curse of Arduino as they don’t run at 20Mhz (largely as the code assumes 16Mhz I think).
For moment no time for testing with an other quartz, but in some week I will try for sure…
16 MHz was chosen for the Arduino project because some of the larger ATMega (ATMega2560) don’t go up to 20 MHz.
Originally yes, but they could shift to 20Mhz but there’s code that would need changing so it seems:
@6581punk : I have made some tests last night with using a 15MHz (no 16Mhz crystal in spare at home) instead of the 20Mhz crystal.
And, hapiness! with a flood of Midi message and clock event thru the 2 UART, no crash
So thank you again for the information, during some week I thought the problem came from my firmware,
now I ready to jam with my midi box…
that’s a neat thing you built!
