Using PIO0_4 and PIO0_5 as I\O

lpcware · ‎06-15-2016

Content originally posted in LPCWare by js-nxp on Thu Dec 29 22:23:14 MST 2011
So after wasting a whole day I got my "16 bit data port" working.:confused:

I have used PIO0_1 - PIO0_8 as the lower 8 bits and PIO2_0 - PIO2_7 for the high 8 bits. The LED has been moved to a pin so it can be connected anywhere.

As you MAY GUESS I could not get those 2 bits to behave as normal I\O pins even though I2C is NOT enabled and have tried the IOCON set to both standard and I\0 mode and the pis set as PIO0_4 and PIO0_5 and not as SCL and SDA.

In all modes I tried the pins behaved as O\C outputs. By setting each bit in turn to 1 with the debugger all other pins responded to 0 and 1 but those 2 pins can only sink current.

At the moment all is working with 2 x 3K3 resistors on those pins. How do I get rid of them and get the pins to behave as normal I\O?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by js-nxp on Sun Jan 01 14:32:27 MST 2012

Quote:
as the 8-bit parallel port pins for LCDs

The ISSUE has been trying to get a [COLOR=red]16 bit port[/COLOR] to talk to GRAPHIC LCD. No so easy with the LPC1114.:(

lpcware · ‎06-15-2016

Content originally posted in LPCWare by vasanth on Sun Jan 01 03:51:22 MST 2012
New year greetings.....:p

I 've been using either (P2_3.....P2_10) or (P2_4.......P2_11) as the 8-bit parallel port pins for LCDs on my LPC1114.These pins act only as dedicated GPIO pins. Well almost...;)

[COLOR=BLUE]Who am i ?[/COLOR]
I am an ARMulan speaking NxPian dialect. I was a PICian previously....:D.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rmteo on Sat Dec 31 07:44:11 MST 2011

Quote: Rob65

As a native Armulan (almost native ... I was there when the nation was formed and joined about 15 years ago) I am now trying to learn how to use PICs since there are cases where a PIC is just the better choice.

Started out as a PICian (8 and 16 bit) several years ago, switched to being an ARMulan two years ago and use Cortex based devices exclusively now. Don't see a need to use a PIC - except when a customers insists and is prepared to pay more for it. Have not used Atmel but it is interesting to see that they are moving to ARMs besides their proprietary 32-bit architecture.

I see ARMulan as comprising several dialects. My portfolio includes STMian and Kinetisian as well as NXPian. :):):)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by js-nxp on Sat Dec 31 02:39:29 MST 2011

Quote:
there are cases where a PIC is just the better choice.

SACRILEGE!! AVRs are much better, that's why I'm using them instead of PICs for the past 12 years. (Previously a Motorolian for about 20 years)

Just got the masked access working after a couple of hours of Googling etc. The biggest hiccup was that the manual says to use bits 2-13 which would translate to bits 0-11, but the compiler did not want to have a bar of that.

After trying all sorts of things I ended up using

LPC_GPIO1->MASKED_ACCESS [1<<11 | 1<<10 | 1<<9 | 1<<8]

and the errors went away. :eek:

Maybe another video is in the making.....:D very useable now.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Sat Dec 31 01:34:22 MST 2011

Quote: NXP_Europe
maybe I missed it, but which controller did you use?

Is DMA a faster solution?

Not really.
Let me summarize:

John is an old dog trying to learn new tricks.
Looking at his website I'd guess to find a whole bunch of 68HC11, 1802 and maybe even a 4004 in his junk box. Not junk, he is still using some of that 'old stuff' it looks.

I guess he evolved in to an Atmelian. The world was divided into two major races of embedded engineers: the Atmelians and the PICians.
We are looking here at an Atmelian learning the Armulan language :D
His Atmelian background still provides him with what he needs to survive but he is surely interested in what the Armulans are doing.

As part of this he is discovering what is possible with those nice chips. When he first presented his problem (trying to interface a full color 3.5"LCD to the lpc1114) I was a bit concerned about his goals but (for now) he is just comparing the speed of an Atmel variant @ 8 MHz driving the same display with the lpc1114 @ 48 MHz.
He was a bit surprised to find that a 32 bit MCU with this many I/O pins has such a strange organization of I/O ports: 12 bits ports with all kind of bits missing in between and - to top it off - a few of those bits have a very strange behavior (Open Drain only).
This must almost feel like a culture shock :eek:

Some Armulans might think that everything could (should) be solved using an ARM (preferably an LPC variant) and that all Atmelians and Picians should immediately become Armulans.
But John notices that this might not be true at all. There are solutions where other chips are the better choice.

He may never want to become an Armulan and I do surely understand this.
As a native Armulan (almost native ... I was there when the nation was formed and joined about 15 years ago) I am now trying to learn how to use PICs since there are cases where a PIC is just the better choice.

I see similar thing happening with John and I just hope we both find our way selecting the right chip for the problems we are faced with - or create ourselves.
I just hope he loves our language and I hope even more that he will stay in our LPC country for some time - maybe not to work in but just for some nice holidays ;)

Cheers,
[INDENT]Rob
[/INDENT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by js-nxp on Fri Dec 30 20:26:00 MST 2011
I have reorganised the ports as above and it is somewhat better now.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Dec 30 17:36:47 MST 2011

Quote: NXP_Europe
Hello js-nxp,

maybe I missed it, but which controller did you use?

Is DMA a faster solution?

Not really :rolleyes: It's a LPC1114 :eek:

http://knowledgebase.nxp.com/showthread.php?t=2740

lpcware · ‎06-15-2016

Content originally posted in LPCWare by NXP_Europe on Fri Dec 30 16:43:21 MST 2011
Hello js-nxp,

maybe I missed it, but which controller did you use?

Is DMA a faster solution?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by js-nxp on Fri Dec 30 15:08:33 MST 2011

Quote:
blame yourself for not reading the manuals

MANUALS! What a novel idea, I'll have to download it when something catches fire to see why it happened.......:D

But yes, it's an old dog trying to learn new tricks and he doesn't really need to because the old bag of tricks get him enough dog biscuits and dog food. :p

I will reorganise the data ports using PIO2 in full as the lower 12 bits and the top 4 bits of PIO1 as the top four bits. This will eliminate 5 rotates, so even without "masked access", whatever that is, :o it should be somewhat faster.

If I can get my head around the masked access for PIO1 all the better I guess.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by gbm on Fri Dec 30 01:44:32 MST 2011
You don't need to "read, or and write" the ports. You may use masked access mechanism for fiddling with the bits you want to change. Don't blame LPC for being too slow, blame yourself for not reading the manuals... ;)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by js-nxp on Fri Dec 30 01:29:27 MST 2011
Oh well, that puts it to bed.

I'm a little disappointed with the overall writing speed to the GLCD. Although a bit faster that the 8MHz chip it loses quite a few cycles because of the port reading, clearing the used bits, shifting the bits by one and then oring the new value to the port. This is for every pixel and there are 384,000 of them. :(

Enough of the NXP for a while. :) I managed to get it all working with a bit of head banging. Thanks to all the helpers.

I have uploaded the 8MHz chip video with the 7" display but it is dreadfully slow, no point doing the Xpresso video as it is not much better.
http://vimeo.com/couchmode/user2128302/videos/sort:newest/34349056

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Fri Dec 30 00:33:42 MST 2011
Sorry to say but Elef is right.
The two I2C pins are different from all other I/O: There is no totem pole output, only O/C (actually O/D since the pins are driven by a FET) and no internal pull up/down is available.

Are you using this as a bi-directional port or output only?
If it's just output the 3k3 resistor won't bite you that much. If the LCD controller assumes this is a 3-state bus then you're scr... stuck with a bunch of wallabies :eek:

Cute but tp keep those off your road you need proper fences (I've used 74hc245 fences for a project)

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by elef on Thu Dec 29 23:25:12 MST 2011

Quote: js-nxp
By setting each bit in turn to 1 with the debugger all other pins responded to 0 and 1 but those 2 pins can only sink current.

At the moment all is working with 2 x 3K3 resistors on those pins. How do I get rid of them and get the pins to behave as normal I\O?

Yer that's a bummer.
Pretty sure you can't, they are only open drain IO. See section 7.4.11 and 7.4.12 of the UM.