NGW100 and TFT

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

Hi gentlemen:

First of all, i must say that I'm totally noob with AVR32 and Linux, but I have some experience with AVR(8), Windows, MSDOS, and PC programming.

Now, my boss told me to dig for some dev board with TFT support, Ethernet, CAN, I2C (TWI), and touch panel support.

After some digging, the closest thing I found is NGW100, that forces us to put an external SPI-CAN interface (MJ1000 or similar?).

But since I'm noob in this matters, I want to know from you, expert users, if is easy to interface an 800x480 TFT (IMHO, the HW side is easy, so my problems will became with software drivers) and to an external SPI-CAN or similar device.

Any tips, links, starting points and guidance where can I find information about this will be welcome.

Our idea is to develop everything, as well as debug, under Linux, trhough Ethernet, and avoid if possible any JTAGICE MkII or AVRONE. Is this a good way to do it or any JTAG debugger is mandatory?

Thank you in advance,

Guillem Planisi.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

If you look at the stk1000 you have an integrated display with a 640*480 resolution.

I also think that the ap7200 come's with a can bus integrated.

http://www.mediamatech.com/files...
http://apps.mediamatech.com/Blog...

Not sure but I think the stk1000 + a stk1005 should give the setup you are looking fore. But I really do not know for sure... The sp7200 is not yet released to the public.

Life's to short for waiting on slow CPU's

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

Quote:

If you look at the stk1000 you have an integrated display with a 640*480 resolution.

The display is 320x240, QVGA.

Hans-Christian

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

Hello:

Thanks for the information. Meanwhile, I had digged a little bit more into this forums and at some links (http://avr32linux.org/twiki/bin/...) I found, it seems that LCD drivers are supported in mainline (lcdc?). It seems also that there are drivers for SPI and TWI, as well as for USART, MMC, SD, etc. Doesn't look too complex for Linux experienced people (that is not my case, though).

I will dig further to get a better grasp about how all that puts together. This forum is a mine of information, and it seems also that attaching TFT's to NGW100 is a common place. Sorry to post again about this subject.

But in my case, I **need** 800x480 pixels resolution... because this board is intended as a test tool that should display patterns on the LCD, that is the 'Device Under Test'. It should respond (not so fast, no real time) at ethernet commands, send some CAN messages, probably Lin messages also, as well as I2C/TWI comms, load data from SD card, and display it on the LCD.

We have to make only few test tools, so any other option is totally overkill, as well as too big (our space is somewhat limited). My boss told me to investigate on this way this morning, and have some feedback this afternoon, since he would order it today. Finally, it seems that we well wait a little bit more.

Thanks again for the info.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

One could easily build another board along with the NGW100 and have a display on it (or rather a connector or likewise or whatever other electronics that is needed). All the LCD lines are taken out on the expansion connectors on the NGW100.
But, the NGW100 has the 16-bits wide SDRAM interface which reduces the bandwidth of the data transfer as opposed to the STK1000 which has the 32-bits wide interface.. And hence not sure whether you will be able to get the TFT resolutions that you mention here. May be some of the folks who have exp. on Linux might comment on it.

-drt

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

Here is some of my experiences with 800x480 16bpp displays:
With NGW100's CPU clocked at 180MHz, it has troubles coping at 60fps. Trying to transfer a sustained 23MWord/s off a ~85MWord/s bus, nevermind doing anything else.
Reduced the frame rate to 30fps, and no problems.
On another AP7000 board with 32-bit SDRAM, 60fps was not a problem (makes sense).

Regards,
Pete
www.mediamatech.com

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

Ouch. That maybe a problem. LCD specs report 33MPixels per second, and 60Hz at the VSync signal. If my math is right, that means 60fps, at 16bpp (native is 18bpps, so this is simple).

Of course I already know that I had to make an adapter PCB, but I have some experience with that part of the project.

Anyway, I begin to suspect that I would have to move to a different platform, FPGA probably. A pity.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Or if you do not want to do development on Linux. I have a system build around the NGW100 on which I drive PC TFT monitor with resolutions of 1024x768 16-BPP.
But, you wil have to write all the drivers, as I did. The amount of work depends upon the functionality you desire.

There are other devlopment boards with 32-bits SDRAM, which would give you higher bandwidth. Grasshopper is an option.

http://www.ic-board.de/index.php...

http://www.embedded-projects.net...

-drt

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

Nice link. This thingie probably fits our bill a little bit better. Although it needs some little HW more (SD card, connectors), that wouldn't be a problem.

Thanks for the tip.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Hello,

there is a little project for Grasshopper:
http://www.mikrocontroller.net/t...

Regards
Udo

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

Thanks for the link. Although I don't speak german, my boss does. Looks promissing.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Hi, I'm back again. Finally I've managed to order grashopper board, and a colleague had plugged a 640x480 TFT panel onto it. It works with that panel at 27.5MHh.

But for the project I'm working on, I had soldered a 800x480 TFT panel that requires a 33MHz pixel clock, but I can't manage to change this frequency. Maybe I'm a dummy with this (well, in fact >>I'm a dummy<< and totally noob with Linux kernels) issue, and the settings in the struct fb_videomode at icnova_base.c file simply is ignored. My value is .pixclock = KHZ2PICOS(33000), but it doesn't respond to any change, even when changing the resolution or any other parameter, it responds correctly.

My colleague told me that perhaps I should change some parameter for the PLL used in another file, but he can't remember what and where. Can someone help me and point me in the right direction?

Thank you very much in advance,

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

for prototyping, just use fbset from command line to set the vital data for the LCD panel.

Hans-Christian

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

Hello again:

Thanks for the info. I had tried fbset, and it works like a charm to change display resolution, but not to change display timmings. And given the application, where I have strict display timmings as well as display resolution, there is no choice than change pixel clock. How can I change that parameter? I tried to do it from icnova_base.c file, but it doesn't do anything but changing some of the margins and sync widths, within certain limits.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

fbset -pixclock

man fbset on any host with documentation installed or fbset --help on AVR32.

Hans-Christian

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

Yes, I had done exactly that, but there is no response. I had tried also with fbset -t 33333 200 ... and a bunch of settings, without any result. Even those extra settings (sync widths, positions, etc) can't be changed from fbset, and only from icnova_base.c. Even that, pixclock can't be changed in any way, while the other settins change accordingly rebuilding the root (BTW, I'm using NFS boot, so changes apply relatively fast).

Thanks for your help and patience,

Guillem.
"Common sense is the least common of the senses" Anonymous.

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