SMD ATMEGA1284P adapter boards available for work on Shruthi/Ambika

Greetings!

TL, dr; I had a batch of adapter boards for the ATmega1284P (a pin-compatible upgrade to the ATmega644 used in the Shruthi and Ambika) built which enable an SMD version of the chip to be inserted into the DIP socket on the MI boards. I now have loads of them and am giving these boards away for free to people who want to work on open source Shruthi/Ambika firmware! I’m also happy to assemble them for a few euros.

For context:
Why the ATmega1284P?
This chip is a drop-in, pin-compatible upgrade to the ATmega644 used in the original Ambika and Shruthi designs, which provides twice the flash available in the 644p. This is particularly important for Ambika firmware development because the stock firmware, and YAM, uses up almost all the space.

Why not just use a DIP ATmega1284p, if they’re pin-compatible?
As previously discussed on the forums, the DIP ATmega1284p chips have a hardware fault related to the UART used for MIDI functionality which can cause the chip to crash. The SMD version of the chip apparently doesn’t have this fault, and therefore using the SMD chip via an adapter board should fix the problem and act as a drop-in replacement without having to totally redesign the synth.

I designed this board last month and now have 44 of them. I’m sending some to @Bjarne (YAM developer) and will experiment with a few myself, but I have no need for so many. So, if anyone’s interested in doing firmware development work on Ambika or Shruthi, or using these for any other open-source purposes: message or email me (barnaby@waterpigs.co.uk) your address, paypal me the shipping costs if it’s going to be more than a couple of euros, and I’ll send you some boards!

I’m also happy to assemble the boards with headers and ATmega chip for €8 + P&P per board, if anyone wants.

Disclaimer: the boards are untested, and I personally have not tested them with the shruthi hardware or firmware! I may not have time to do so but will post my experiences here when I get round to it. Point is, these boards are strictly experimental with no guarantee they actually work!

Boards in stock as of 2017-11-18: 32

2 Likes

Beware! The Shruthi firmware might need a few modifications to run on the 1284p (iirc, some bank-switching stuff in the assembly code reading data from flash memory).

1 Like

Thanks for the official warning Olivier.
I hope its clear to everyone that these are intended for DIY developments, and not simply a “no fuzz” upgrade of a Shruthi or Ambika (or even Anushri!).
Personally, I’m thrilled and thankful about this DIY possibility.

Cheers

1 Like

Thanks for the warning Olivier! I’m trying to make sure everyone who gets one of these knows that it’s untested, undocumented, unofficial and suitable only for experimenting at the moment.

Interesting about the bank switching stuff, I’ve not delved deep enough into AVR development to come across that, but remember having read that one of the advantages of AVR over PICs is lack of bank switching, but apparently that’s not the case.

@Bjarne at least we don’t have to worry about Anushri compatibility because that synth uses a 328p, so this adapter board won’t fit in the DIP socket :wink:

1 Like

Btw @pinchenettes I’d be happy to assemble and send you some of these boards too of course, but I suspect you’ve moved on to greater things :wink: As always, thanks so much for developing and open-sourcing Shruthi and Ambika and all the other wonderful musical tools you make!

This was the case as long as they kept selling 64kb chips, since in the AVR architecture, the instruction that loads data from flash memory (LPM) uses a 16-bit register (Z) for the address.

With the 1284p, Atmel had to come up with a kludge - an extra register called RAMP Z that contains the upper bits of the address.

So once you start making modifications and the code starts exceeding 64kb, you have to make sure all the data that is going to be used by an LPM opcode (everything in resources.cc to start with) fits in the first 64kb or in the last 64kb (with __attribute__ ((section (".data")) in the code and --section-start=.data=0x10000 in the linker flags). Then you’ll have to sprinkle the code with OUT RAMPZ, r0 or OUT RAMPZ, rXX to make sure the right bank is selected.

I think a clear split of the flash for code and data may be the way to go for my experiments. A full 64kb for flash resources are still a welcome increase of space.
Regarding Anushri I’m actually eager to do some veroboarding to be able to use atmefa644/atmega1284 for more drums etc.
Cheers

The lack of a dedicated DAC for the drums has always been the achilles heel of the Anushri, in my opinion. Adding more 8 bit PWM drums is just going to highlight that, I think.

Adding velocity triggering of accent would be cool, though :slightly_smiling_face:

Also, I’d love to see an alternative sequencer mode, like the one used for the drums, but applied to the bass synth, too. I don’t know if the UI would support this (always the problem with alternative firmwares).

a|x

I know, that’s why I also plan to fool around with an additional DAC for the drums on my veroboard :wink:

That would be cool! If you’re going to redesign the board, though, it would probably make more sense to ditch the ATMega completely, and go for a Cortex-based MCU instead.

a|x

You’d need to redesign the whole board to work on 3.3 rather than 5V, I guess. Would open up a lot of possibilities, too.

a|x

That’s not going to happen due to (a) my electronic skills and (b) the need to rewrite the complete firmware. I’m just fiddling for my own amusement - I’m not designing instruments grounds up.

That doesn’t mean I think it’s a bad idea.

Cheers

Was just thinking out loud, really :wink:

a|x

You guys are awesome. Seriously.

still have any of these?

Yep! Got plenty of bare boards and a couple of built ones. Do you want assembled or bare, and how many? Bare boards are free + shipping, assembled are €8 each + shipping.

@Bjarne have you been able to come up with a “template” for this? I need to modify my Ambika to send some cc messages whenever a new program is loaded, and the only way I could fit that was to remove the sequencer code. So, while I managed to do this, I am not really a programmer and I guess doing what you describe is way over my head. Still I’d be very interested in this… And yes, it has to do with my TSFKAA.

Hi,

Love your project. No I haven’t done this yet - less time for DIY in general, and focusing on other things, e.g. building and modding Anookum and things like Another modified Ambika SMR-4 voice card .

By chance, I did just commit a UNTESTED memory diet for YAM that saves approx 2kb by reducing number of samples per lfo from 256 to 128:

Cheers