Questions about SPI, Fonts and such

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And the answer is NOT 42 ...

So. I have put aside the largish GSM controller project "for a while" and started fiddling something that should have been easier...

This is an user interface for audio frequency generator (DAC based). My intention is to stack similar sized boards the top one being the user interface - which is now done hardware-wise.

It has a functioning 128x64 graphic LCD and a simple numeric keypad (buttons and switches scavenged from an old PC keyboard). Everything works just fine - even the new programming dongle which I used for the very first time.

The stacked boards are communicating using SPI. I would appreciate if You can pinpoint the caveats which I am going to be tangled with that. Can it be made fully IRQ driven (like RS232)? Does it interfere with counters of other device functionality ?

My other "problem" is the graphic display. It was quite easy to create two fonts for it. However I would like to have larger than 5x7 letters. Those are like fly excrements and I need to put on my goggles to actually read them.

I already have done interrupt driven keypad scanner, backlight PWM dimmer, the basic LCD library with those tiny fonts and some simple graphic routines (well - drawing a line is not really a simple thing). The LCD hardware is also supported fully by the library.

If You can give me some advice on SPI or the bigger font for the LCD, please do so.

The entire project including schematic and avr code can be seen at:
http://furpile.com/Projects/audi...

Thanks in advance !

P.S. The schematic is now A4 sized PDF as I got badly beaten after displaying a HUGE png schematic which caused nasty freeze-ups on some PC:s...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eskoilola wrote:
The stacked boards are communicating using SPI. I would appreciate if You can pinpoint the caveats which I am going to be tangled with that. Can it be made fully IRQ driven (like RS232)?

You mean UART? Yes.

eskoilola wrote:
Does it interfere with counters of other device functionality ?

Not more than any other interrupt: latency-wise.

Some possible caveats, assorted (not necessarily related to your particular setup): be careful with SS pin in your master, can turn it into slave surprisingly. Transmitter is not buffered, which is a pain with the slave (if AVR is slave). Don't expect any tremendous data flow, unless it's a simple master-slave where both the master and the slave have nothing better to do than "talk" at a given moment. There is no inherent start of transmission like in I2C, so you might need to packetize if the transfer is AVR-AVR. Multimaster is in theory possible, but I never tried to open that can of worms, in my application master polls slave regularly, and slave has a means to answer "no, thanks, I have nothing to say now".

Feel free to ask when you get to the particulars.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
in my application master polls slave regularly, and slave has a means to answer "no, thanks, I have nothing to say now".
Another way to do it is for the slave to have a signal to the master which tells the master, "I have something to say". If it is important to respond to the slave, that signal can tie to an interrupt on the master which will initiate a status request.

Both approaches work well.

One other thing with SPI: since it is inherently a single-byte transfer mechanism, sending variable strings to the slave requires (or perhaps suggests) that you send the length of the string before the string itself so the slave knows how big a buffer to allocate. It also helps the slave know when the transmission is done.

In our application we ended up defining a command structure so the slave always knew what was happening.

For a status message we included 3 bytes back from the slave to tell the master the current state of the slave and to help clear the communication channel.

When you first debug your link, expect the master and slave to get "out of sync" - the slave expects to send more data while the master thinks it is done, or vice versa. Plan on some mechanism to "flush" the two sides and get them back in sync. Even if it is sending the status request repeatedly until you get the correct response, you will occasionally need it.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First of all - many thanks and a stadium sized hug for the answers.

I have been doing "RTFM" over and over again. The SPI is not well suited for data streaming. This is because it has the transmit and receive married together in a way that You are sending and receiving equal amounts of data.

Seeing this I ended up in a design that transfers memory blocks between master and the slave. The memory blocks are of identical size on both ends.

I include the sources as a zip. The headers are missing - use Your imagination.

The code has not been tested yet - I need the master first.... it is on it's way ;)

Attachment(s):