components on a mega 2560 based board

Hi
I have a project where space is very limited but file size is large.
The best idea I can think of is to design my own board with a mega 2560 at its heart. the chips would probably come without a bootloader so would need components to load that onto the chip, programming would be with a seperate board like a pro mini uses.
What I need to know is what is the components that are vital for the mega 2560 to work, I would be using both an I2C bus and SPI some of the digital pins would be used as would a few interrupts and analog output ports.
kendrick

Programming (at least the bootloader) uses SPI. A chip with bootloader is programmed via Serial1.

But just to straighten the XY problem, what are you making that uses a lot of flash / RAM (because "file size" isn't a thing with programming an AVR)?

There are small Mega boards; have a look at the CORE products of inhaos. Might safe you some work.

septillion:
Programming (at least the bootloader) uses SPI. A chip with bootloader is programmed via Serial1.

But just to straighten the XY problem, what are you making that uses a lot of flash / RAM (because "file size" isn't a thing with programming an AVR)?

I'm using the SPI bus for a ST7920 128x64 display once I have worked out the correct pins to program the bootloader I can alter the line of code that links the display to the mega 2560 this should reduce the number of connections I have to draw.

As for file size I first did tests on the display using an arduino nano the compiler stated that the memory was almost full and I had not added any of my code! as a result I changed to a mega 2560 board, a standard board is too big one from robotdyn (similar to the one from inhaos) fits but has a lot of output connections I will not need, the best solution I think would be to build a custom board that has only what I need on it.

what I am trying to find out is what is the bare minimum of components required.
the power supply will be 5v fixed, no 3.3v supplies will be needed, no onboard USB port just TTL pins, there is no need for an on LED or a pin 13 led.

I have just been doing some web trawling and have found some gems that should solve my problems
DIY ARDUINO MEGA 2560 OR 1280 By TSJWang.

Minimum, assuming stable 5V: uC, crystal (assuming default configuration), crystal capacitors, 100nf decouple capacitor close to the uC.

And ahh, graphic displays can eat some RAM. Again NOT file size! If you use U8G2 you can probably reduce the RAM use (at the cost of writing to the display being a bit slower). U8G2 can use a page buffer of just 128bytes instead of the full 1024bytes for the full frame buffer.

And SPI is a bus, it can handle multiple things. And as you don't case what the LCD does when you program the chip they can both use the SPI bus.

Also a quick note, the ST7920 is NOT SPI compliant... It will work on SPI just fine but it is annoyed if you try to access other devices on the SPI bus. SCLK and MOSI of the ST7920 may not change. See here.

But as said, during programming you don't care about the screen so it's not a problem to share the SPI bus :slight_smile:

If it’s RAM you care about, but flash and pin count is not an issue - the 1284p has half the flash, but twice the ram of the 2560 (but also far fewer pins).

And, in general, for AVRs you need:
Crystal, if you’re using one.
Loading caps for crystal, if applicable. Traces to crystal+caps from avr should be kept short.
The AVR itself
0.1uF ceramic caps - 1 per vcc or avcc pin, connected between that pin and ground, right next to the chip.
10k resistor from reset to vcc (not needed, strictly speaking, if not using autoreset for serial programming, but always a good idea for noise rejection on reset pin.
a 2x3 pin ISP header, connected to gnd/vcc/reset/SPI pins with the standard pinout, for bootloading (or programming via ISP if you choose not to use a bootloader). Every time I haven’t included one, I’ve been kicking myself afterwards for my foolishness, so I recommend that this always be incorporated into a design.
a 1x6 pin header (FTDI pinout) for programming over serial, if this functionality is desired.
a 0.1uF cap (ceramic is fine) between DTR pin of above header and reset pin of AVR for autoreset for programming. You can put a 1x2 pin header inline here so you can use a jumper to enable autoreset.

your help is much appreciated, the only thing I have that uses the SPI bus is the display the rest of the devices that are on a bus are all I2C.
With luck I should be able to fit everything onto one board with a set of pads matching up to the SPI pads on the ST7920.

Time to move from a full size mega to the shrunk mega2560 pro moving the SPI bus from 10,11,13 to the ISP.
kendrick

If you want to program via ISP (on the SPI bus) do check that any devices on the SPI bus do not prevent programming.

During programming the IO pins will be floating which may cause problems with some SPI devices, you could may need pullps on some device select lines for instance.

Don’t think it’s an issue here. He only uses MOSI and SCLK to the display, not MISO. Yeah, they may be floating and yeah the display may act weird. But not an issue while programming.

Kendrick:
moving the SPI bus from 10,11,13 to the ISP.

Huh, what? You do know the ISP header is also simple connected to the SPI bus aka to the same pins as 10, 11, 12 and 13…

Kendrick:
your help is much appreciated, the only thing I have that uses the SPI bus is the display the rest of the devices that are on a bus are all I2C.

Depending on what is connected to I2C & SPI and if the libraries are compatible then maybe consider a different MCU altogether. Maybe an ESP8266, ESP32 or STM32 will do the job and have a lot more memory and faster clock speeds.

Every uC is possible. But without knowing the rest of the requirements the Mega already sounds overkill...

septillion:
Huh, what? You do know the ISP header is also simple connected to the SPI bus aka to the same pins as 10, 11, 12 and 13...

But not on the Mega.