Article - Interfacing a character display

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

Hi everyone..

here there is a little 'article' I wrote, based on a LCD character display, avr32, linux and the NGW100. I thought it's time to give back something to the community, so here it is.

I'm open to opinions, corrections, etc. It hasn't been published anywhere on the web yet.

Here it is http://carlosbecker.com.ar/avr32...

Carlos

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

Great ,
Congratulations.

Viron.

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

Very nice article! I especially like the modular design of the driver.

Some hints:
Do not implement empty fop_functions (like ioctl or read). Simply leave them out. Otherwise this might confuse the user since they return 0 (success) but don't do anything.
Concerning the very long mdelay: simply use msleep from
which is a non-busy waiting :)

These delays are really a big problem. Have to fight them with my 256x64 graphical display, too. The controllers on the LCD are so slow, writing just 8 pixels take some microseconds!

Again, nice work!
hardy

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

Thanks for the feedback!

The idea about read() and ioctl() looks nice, I'll modify it and repost the article.

I thought that msleep() was for user-space programs only, I have to try that, thanks!

I will see if I can make a little example about using mmap() and /dev/mem to include it in the same text, since it might be useful.

I'll repost the pdf tonight or tomorrow,

thanks!

Carlos

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

here it goes.. added some more info about mmap() and an example.

http://carlosbecker.com.ar/avr32...

Hardy: please read the final page which contains some credits about your comments. I don't know your name so I just wrote 'hardy'. I can live it that way or put your name there, just PM me or contact me by mail with your real name, nick, or whatever you would like to appear there.

thanks to all again

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

Hardy is just fine :)

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

well finally it's published at avr32linux.org
http://avr32linux.org/twiki/bin/...

thanks to everybody!

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

Fantastic, thanks!

A few comments (mainly nit-picks :) ):

- You should probably include pio.h rather than coding all your own addresses and pio writey-gumph. This will make it more portable across various processors.

Better yet, use the gpio framework and it'll be completely portable across any architecture. Maybe slightly slower but probably not so as you'd notice.

- Dynamic major number? Probably something to put under todo if nothing else

- In init_module(), what's the '-5' in the return and why is it open-coded rather than, eg, return -EOBFUSCATEDCRUFT ?

- This is your own module coming nowhere near core kernelness but you may want to run your thing through checkpatch.pl (in new kernel trees), see if it throws out anything you care about.

Thanks again for doing this and forgive the lateness of my review, have been out of the office (down at the beach) for the last week-and-a-bit :)

-S.

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

comments are always welcomed!
About PIO, you are right, but I wanted to show how to access registers directly, but I will see if I can mention some of that in the new revision./
The '-5' is a total fantasy (laughs...), I will see if I can find a meaningful -E*****.

I will post here as soon as I have the new version out.

thanks!

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

Fair enough wanting to access registers directly but it should almost never be done :). For example pio.h provides the pio_{read_write}l wrappers around __raw_{read,write}l for the sake of clarity. And clarity is good.

Then again, if you're coming from an 8-bit background one probably finds writing directly to the registers easier to understand!

Thanks ^^
--Ben.