Embarrassing-16 bit port

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Embarrassing-16 bit port

1,775件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by js-nxp on Wed Nov 23 17:31:53 MST 2011
So after more than 30 years using 8 bit micros I'm trying my hand with the LPCXpresso and the LPC1114 which came with it. (had lots of problems in the past with the debugger as I had some corrupted files on my PC)

I'm trying to implement a 16 bit parallel port to talk to a GLCD and porting some code from an Atmel Xmega chip (uses 2x 8 bit ports).

How in the world can I do that with a chip which uses 12 bit ports? :confused:

The only ones I can see which can be used is PIO2 (12 bits) + PIO3 (6 bits) which would mean several shift to get the 16 bit data in the right location. 
PIO0 and PIO1 are littered with JTAG or ADC which I would also need.

This will probably mean a slower operation than with the current 32MHz chip.
0 件の賞賛
返信
10 返答(返信)

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by js-nxp on Sat Nov 26 18:50:31 MST 2011
There may be an interesting explanation as to why the ports are set up as 12 bits rather than the "usual" 8 bits or even 16 bits.

If they were set up that way we would not be wasting all of these electrons. ;)
0 件の賞賛
返信

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by atomicdog on Sat Nov 26 18:41:02 MST 2011

Quote: js-nxp
Fancy meeting you here. :) But 4 of those pins go also to the LPC-LINK for debug. Isn't there any activities on those pin during debug like "other" debuggers and therefore not useable?

Yeah, there is activity on those pins but writing to the GPIO data register only effects the pins that are setup as GPIO on that port. So if a pin is setup for debug, analog or something other then GPIO it's not effected by the read/write of the ports GPIO data register.
0 件の賞賛
返信

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by js-nxp on Sat Nov 26 16:49:08 MST 2011

Quote:
You can still use Ports 0 & 1. Non-GPIO pins in a Port can be masked out and the whole port written to.

Fancy meeting you here. :) But 4 of those pins go also to the LPC-LINK for debug. Isn't there any activities on those pin during debug like "other" debuggers and therefore not useable?

Quote:
Is your 16 bit port a "16bit data + ctrl lines" ?

Yes the GLCD code at the moment is in 16bit mode. I have seen a GLCD project using 8 bit mode but I'm trying to use 16bit mode for a 7" display. I don't really want to add extra hardware.

Quote:
For a 128x64 b&w LCD this is more than fast enough

This is for a 800x480 RGB touchscreen display. The GLCD can be driven in 8 bit mode and SPI mode but I haven't played around with those yet. ie I'll need to add a bit of code. This should also answer other questions posed here.

This is a smaller GLCD running with a 8MHz AVR. Fast enough for that size screen but a little sluggish for the above 7" screen.
http://vimeo.com/31946943 if it doesn start go to "couch mode"
0 件の賞賛
返信

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by js-nxp on Sat Nov 26 16:24:57 MST 2011
I'm really terribly sorry for ignoring this thread. I just did not get a notification of any replies. I'll check my settings to see what's happening.

Thanks for your time to respond, I'll read through the above now.
0 件の賞賛
返信

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ktownsend on Thu Nov 24 16:04:12 MST 2011

Quote: Zero
Just to note it: Today there are wonderful 240x320 Touchscreen LCDs available :)

Something like this: http://www.watterott.com/en/MI0283QT-2

It's amazing how simple a SPI connection can control a color LCD and a touchscreen. That's not very fast, but impressive colorful :rolleyes:



You can get very good performance out of these things using bit-banding on an M3 and a bit of careful coding.  SPI is of course a nice option if you only have a few pins, but an 8-bit bus plus the control pins is still pretty easy to bit bang with great performance (instant feeling screen updates).

But it is pretty amazing how cheap these things can get in small quantities!
0 件の賞賛
返信

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Thu Nov 24 15:52:50 MST 2011
Just to note it: Today there are wonderful 240x320 Touchscreen LCDs available :)

Something like this: http://www.watterott.com/en/MI0283QT-2-Adapter

It's amazing how simple a SPI connection can control a color LCD and a touchscreen. That's not very fast, but impressive colorful :rolleyes:

Video: http://www.watterott.net/projects/mi0283qt?lang=en
0 件の賞賛
返信

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by NXP_Europe on Thu Nov 24 15:30:14 MST 2011
If you can provide a bit more information it will probably be easier to give a solution, but it shouldn't be too difficult to find a workable solution. Which LCD controller is being used first? If it's a simple 128x64 monochrome display these can often be configured to use less than a 16-bit interface (indeed, this is even serious overkill in this case). If it's a TFT LCD with a built in controller (ILI9325, ILI9320, etc.), these will indeed give you the best performance using a 16-bit bus but you can still get excellent performance using an 8-bit bus on one GPIO bank for the data sending the commands and data out in two pieces. 20-30fps is perfectly feasible bit-banging a 320x240 display with good coding and using some of the features available in the Cortex M chips like bit-banding on the Cortex M3 LPC1343 (unfortunately not available on the LPC1114 based on the smaller and lower power Cortex M0).

If you can clarify a bit more your setup, though, it will be easier to provide better answers. The learning curve might feel a bit steep at first, but once you wrap your head around the basics the LPC1114 is a great little chip with a lot of potential for the price tag, and it's a good starting point getting into 32-bit.  One big advantage of the LPC1114 is that if you hit a ceiling with it, it's an exceptionally painless upgrade to the almost identical Cortex M3 based 72MHz LPC1343 (also available on an LPCXPresso board).
0 件の賞賛
返信

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Rob65 on Thu Nov 24 02:42:57 MST 2011
It all depends on the LCD and what you want to do with it but I'd rather think that an LCD controller with a 16 bit bus is a bit of an overkill for a processor like an lpc1114.

I have almost standardized my embedded solutions to use an LCD with SPI interface and even then (with lpc17xx) I am still struggling with the amount of I/O available. For a 128x64 b&w LCD this is more than fast enough to show UI pictures and menus.

Do you need a bidirectional bus (i.e. are you also reading data from the LCD?) If not then you could use a standard 16 bits shift register (e.g. a pair of 74hc595) to create your 16 bits bus using just one SPI port.
The hc595 is nice, it has a separate parallel latch so the data is always stable at the outputs, and an output state with tri-state possibility.

But maybe there is a way to use your LCD also with SPI or parallel 4/8 bit bus ?

Regards,[INDENT]Rob
[/INDENT]
0 件の賞賛
返信

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Polux rsv on Thu Nov 24 02:09:14 MST 2011
Is your 16 bit port a "16bit data + ctrl lines" ?
Or a "8bit data lines + 8ctrl lines" ???

These ARM chips are so fast that you will need to add software delay loops to implement the LCD timings. This will leave you enough time to bitbang the bus with some external latch. This will also spare some IOs.

Angelo
0 件の賞賛
返信

1,699件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by atomicdog on Wed Nov 23 22:37:50 MST 2011
You can still use Ports 0 & 1. Non-GPIO pins in a Port can be masked out and the whole port written to.
0 件の賞賛
返信