LCD, buttons and LEDS all on the same SPI?

I have edited the start post to contain the schematic, thanks.

4899x3492 - that's like 5 screens wide by 4 tall.
Export in eagle, under Area select Window, then decrease the resolution so its ~1000 wide x whatever.

Hi Leo24DF,

So you have changed the design from an attiny85 to an atmega328. But you still have all those shift registers. I count 14 unused pins on the atmega. What will you be using those for?

Paul

I honestly could not make up my mind of what to use them for. The easiest solution would be to discard the 74HC165N's altogether and connect all the buttons on the atmega328.
After doing that I would have only 2 unused pins left.

Edit: Apparantly it's four pins, as in the edited schematic.

Also It seems that I have connected the ULN2003 the wrong way around right?

Yes,the ULN2003 needs to have the Is connected to the shift register, the Qs connected to the LED cathodes, and Gnd connected to Gnd. COM is left open.
Reset needs a 10K to Vcc.
If you move two switches off the Rx & Tx pins to the free PortC pins, and add a cap with one end connected to the reset pin and the other end to a header with Rx, Tx, Vcc, Gnd, you can connect an offboard USB/Serial adapter and download sketches into a bootloaded processor without having to pull it out of the board for every software change.

I've been thinking, and I recon you could do all that with no shift registers. Just the uln2003 to sink current from the common cathodes.

Extend your current led matrix to include the bicolour leds (2 more rows) and the switches (2 rows, bypassing the uln). So that's 9 rows x 7 columns. Drive the 9 rows directly from 9 atmega pins. Drive the uln2003 directly using 7 more pins from the atmega. Use 8 of the 9 row pins to drive the lcd in 8 bit mode. One more atmega pin for the lcd enable line.

Not 100% sure on this yet, but would save you alot of chips and complexity!

Paul

I have tried to put the switches and duo leds in the matrix, only I am not sure how I should connect the lcd module ( standard 2x16 arduino lcd library compatible type). This seems about right, since writing to the lcd is only possible when the 'write enable line' is high right?

Yes, that looks pretty much like I was imagining. Excellent work.

I would free up the tx and rx lines as Bob suggested. You have 3 other lines to use instead.

I think the lcd connections look fine. Can't remember exactly which pin is which off top of my head, but I remember 6 are needed for 4 bit mode. Strictly speaking I think it reads the data on a falling edge on the enable pin, but essentially you are correct.

So what do you think of the idea?

Can anyone see any problems with this approach. Obviously some careful coding will be needed...

I have edited the schematic, and added a 5 pin connector which is supposed to go to a ttl-232 usb interface. And I have almost finished a pcb layout for it, although the multiplexing is not making a pretty layout very easy. Hopefully this schematic is completely correct now.

Looks good but I think we still need at least one extra set of experienced eyes to look over the design. Anyone?

A simplification to consider: is 16MHz speed or precise timing required for this design? I doubt it, in which case you could ditch the crystal & caps and use the internal 8MHz clock. That would free up 2 more pins, not that they seem to be needed!

Its great that you have pcb layout nearly complete, but to me that feels like running before you can walk. I'm never that confident. I always prototype on breadboard first. You will need quite a few breadboards clipped together for this one! I like to start with my nano 3.0 on the breadboard, then later substitute a bare atmega328 (either with bootloader, or load up arduinoISP on the nano and use that to program the atmega).

Paul

Well the 16mhz crystal and two caps are really not in my way atm. And well I have worked on a layout for each iteration of the schematics you see here. Just for practice purposes, this is my first layout work using eagle after all.
But I will breadboard parts of the schematic tonight to see if it works, since I guess I have all parts now, except the 2x16 LCD which got delayed.

All good then, barring any advice to the contrary from other forum members?

Looking forward to seeing something working when you have it.

In terms of the sketch, I think I would start with a simple loop to perform the multiplexing, just getting all leds lit simultaneously to begin with. Check for acceptable levels of brightness and flickering. Then move on to indiviual control of the leds, trying out a few pre-determined or random patterns. After that, build in the key-scanning, echoing the switch statuses back to the PC. Obviously leave the lcd stuff until that arrives! Then finally add the actual game code. In other words don't try to code it all at once and then struggle to de-bug it, but I'm sure you know that.

Paul

I am running into a problem, how can you use 'digitalread' if a switch is being pressed when all pins are set to pinmode'ouput'? Is this possible using a workaround? Or should I build a seperate 3x4 matrix for the switches alone?

On your schematic, you have ports PC1 and PC2 connected to the buttons. I think you should have these set to input (perhaps with pullup to prevent the pins floating when no buttons are pressed). Set all of PB3/2/1/0/PD7/6 to high. Then if you change each of those to low, in turn, you can use digitalRead on PC1/2 to pick up the state of each button. They will read 0 when a button is pressed. Alernatively put 10K pulldown resistors on PC1/2 and read them as you scan your led matrix, in which case you will read 1 when a button is pressed.

Ok I have succesfully written some sample code for 9 leds and six buttons, the buttons are determined like you suggested and then using row scanning the correct leds are lit.
Due to the slow nature of digitalRead and digitalWrite, I am using port manipulation methods to speed things up. But this alters the entire register So if I use this

PORTB = B11111111;

Will this have an effect on the external oscillator ports PB7 and PB6 ? Or are these overruled by cetting certain fuses in the bootloader?
Also for ease of programming I want to use port PD1 ( TX ) as an output, since this is also possible on a regular UNO I looked at its schematic and saw I would just need to put a 1k resistor on tx and rx before plug SV1, does this pose any limitation on the output load, if so would a 470 ohm resistor for the leds be a problem? This problem would only occur when reprogramming the 328 in circuit or during serial communication right?

Edit: Ofcourse using a dip switch or a four (2x2) pin header I could disconect tx and rx from the rest of the circuit, and therefore avoiding problems with reprogramming.

Leo24DF:
Due to the slow nature of digitalRead and digitalWrite, I am using port manipulation methods to speed things up. But this alters the entire register So if I use this

PORTB = B11111111;

Will this have an effect on the external oscillator ports PB7 and PB6 ? Or are these overruled by cetting certain fuses in the bootloader?

First of all I would say that, yes, its true that digitalRead/Write are slower than direct port manipulation. But for your application, they should be more than fast enough. If you had performance problems while using them, I would look elsewhere for the problem. For example, I built a circuit to display Conway's Game Of Life on a 128 x 64 LCD which updated at up to 10 frames per second. That's 128 x 64 x 10 = 10,000 pixel updates per second, with several digitalWrite commands needed to update each pixel. That was on a 16MHz 328 also.

To answer your question, I'm 90% sure you are correct. The fuse settings for external oscillator will mean that any attempt to use PB6/7 will simply be ignored.

Leo24DF:
Also for ease of programming I want to use port PD1 ( TX ) as an output, since this is also possible on a regular UNO I looked at its schematic and saw I would just need to put a 1k resistor on tx and rx before plug SV1, does this pose any limitation on the output load, if so would a 470 ohm resistor for the leds be a problem? This problem would only occur when reprogramming the 328 in circuit or during serial communication right?

For one more LED, can't you just squeeze it into your matrix somewhere? I can't quite visualise your suggestion. Could you update your schematic to show it? Do you have any other available pins on the 328?

Paul

Considering my matrix is only about 7x7 leds combined with 6x2 switches and 5x1 for the lcd, I should have plenty of overhead when using digitalWrite and digitalRead.
If the code turns out to be too slow I'll post it here first before rearraging it. Here is the updated schematic, the only change are the two 10k pulldown resistors at PC1/2.

I meant draw in your suggested new leds on the scematic... but I can see 4 more spaces in the matrix for leds, on the same rows as the bicolour leds. If those series resistors are unsuitable you can bypass them with others for your new leds.

Your pulldown resistors for the switches are drawn wrong on that scematic, they should be between the atmega pins and ground.

Paul

I guess I said it wrong, I only wanted to free up the pin to get all 'row' pins on the same port, which would make port manipulation easier. I already have enough leds as it is for this thing.

And the pulldown resistors..... well that's a stupid mistake of mine. Since it's even in the name, they pull down to LOW which is ground in this case.