EmbeddedRelated.com
Forums

interfacing ADS7825 with lpc2148 blueboard

Started by shweta July 31, 2010
--- In l..., jtd wrote:
>
> On Tuesday 03 August 2010 21:05:23 rtstofer wrote:
>
> Jeez!!! you actually have the patience ;-).
>

Another home work assignment gone bad.

don

An Engineer's Guide to the LPC2100 Series

On Wednesday 04 August 2010 04:04:13 Donald H wrote:
> --- In l..., jtd wrote:
> > On Tuesday 03 August 2010 21:05:23 rtstofer wrote:
> >
> > Jeez!!! you actually have the patience ;-).
>
> Another home work assignment gone bad.

Nooo. It's professional top secret sauce. Part of the job assignment.

--
Rgds
JTD
i put my code into file section "ADS LCD.rar". From that you are know
about the pin connection.

On 8/3/10, rtstofer wrote:
> --- In l..., Shweta Parmar wrote:
>>
>> thanks
>> Actually i am getting data into LCD and uart1 by writing like this:
>> temp = IO0PIN
>> but i am not getting 0Volt for value 0000 and 5Volt for FFFF.
>> so what should i do?
>>
>> Clearly, that is NOT how you are getting data to the LCD or UART1. There is
> no way that readng IO0PIN and storing it in a variable 'temp' s going to
> send ANYTHING to the LCD or UART1.
>
> Second, your pseudo code (macros?) are pretty useless in terms of trying to
> help with your project. We need to know how the A/D is wired, how the IO
> port is initialized and how each of those statements results in C code. It
> doesn't help that the connection details are in a message that is pretty
> old.
>
> I suppose it matters how fast the peripheral bus is operating and whether
> the port is toggling faster than the A/D chip can accept.
>
> It isn't clear to me that you have ever gotten UART1 to send even a text
> string ("Hello World!\n") to a PC or whatever. That would be my very first
> step (right after I got an LED to blink). Get the UART to send strings.
> Then I would write numeric conversion routines to convert the binary data
> from the A/D to character strings. I might use "The C Programming Language"
> by Kernighan & Ritchie to get some of this code rather that rely on things
> like printf().
>
> I might just write a collection of functions (probably 5) that 1) emit a
> '0x' prefix, 2) break a word into shorts and call the short conversion
> function, 3) break a short into bytes and call the byte conversion function,
> 4) break a byte into nibbles and call the nibble conversion function and,
> finally, 5) convert the nibble to an ASCII hex character and send it to the
> UART.
>
> Once I was absolutely certain that the hex conversion functions and UART
> were working, I would start with the A/D.
>
> Eventually, you will want to ZIP up your code (the real code, not pseudo
> code) and post it in the Files folder.
>
> Oh, and don't count on spin loops to implement time delays. If the loop
> variable isn't declared 'volatile', many compilers will just scrap the loop
> at any optimization level above 0. How this is handled is compiler specific
> and, thus, not portable. Check the assembly code to see if the spin loop is
> still included.
>
> Richard
>
On 4/08/2010 3:56 PM, Shweta Parmar wrote:
>
> i put my code into file section "ADS LCD.rar". From that you are know
> about the pin connection.
>
Are you sure?? I can see ads7825.rar

but not "ADS LCD.rar"

Peter
On 4/08/2010 4:11 PM, Peter McConaghy wrote:
>
> On 4/08/2010 3:56 PM, Shweta Parmar wrote:
>
>> i put my code into file section "ADS LCD.rar". From that you are know
>>
>> about the pin connection.
>>
> Are you sure?? I can see ads7825.rar
>
> but not "ADS LCD.rar"
It appeared just after I sent that... 15mins after the message saying it
was there.

I don't want to sound rude but your code is a bit of a mess. How about
some comments in there explaining what you're trying to do. Looking at
it you don't seem to have a good understanding of what is going on.

For example:
- line 35 (IO0PIN = ADC_DATA_CLR;) reads from a write only register
(IO0CLR) and then writes it to the output pins. Why would you do that??
- line 36 ( while(ADC_BUSY == 0);) doesn't do anything because elsewhere
#define ADC_BUSY (1 << 29)
- you never clear "temp" yet you OR stuff into it on line 43

That's just a few of your problems - there are many more. Good luck with
it!

Peter
--- In l..., Shweta Parmar wrote:
>
> i put my code into file section "ADS LCD.rar". From that you are know
> about the pin connection.
>

Looking at main():

while(1)
{
U8 i,j,rc,byte;

byte = 0;
rc = 0;
wait(1);
rc = 1;
while(ADC_BUSY == 0);
i = IO0DIR ;
lcd_gotoxy(0, 0);
lcd_putchar(i);
byte = 1;
j = IO0DIR;
lcd_gotoxy(0, 0);
lcd_putchar(j);

// i = FIO0DIR;
//if(i >= 0 && i <= 10922)
//{

//}
}

You are reading the direction control port (which does NOT contain useful data) and then sending the binary value (which is NOT necessarily a displayable character) to the LCD. And you are putting both bytes in the same location on the screen.

Perhaps you want to read IO0PIN, shift and mask the data byte and then convert the byte to two hex chars. This will display 4 chars on the LCD. Or, get the entire short (16 bits) and use a general purpose set of conversion functions to create '0x1234' style of output.

PINSEL (selecting the function for pins) is usually done only once in an application. IODIR might be constant for most pins and only needs to be changed if the pins form a bidirectional data bus. I'm wondering why the pin for the backlight keeps getting its IODIR rewritten.

Richard

yes i am sure. now check i load my code.

On Wed, Aug 4, 2010 at 11:41 AM, Peter McConaghy <
p...@circuitlink.com.au> wrote:

> On 4/08/2010 3:56 PM, Shweta Parmar wrote:
>
> i put my code into file section "ADS LCD.rar". From that you are know
> about the pin connection.
>
> Are you sure?? I can see ads7825.rarbut not "ADS LCD.rar"
>
> Peter
>
>
Hello,

> >> i put my code into file section "ADS LCD.rar".

perhaps my doc (data sheet or user manual) is wrong, not up to date),
but i see

"Pins P0.24, P0.26 and P0.27 are not available"

and you are using this port pin:

#define ADC_BYTE (1 << 27)

To which hardware pin have you connected ADC_BYTE ?

Also please read chapter 8 from user manual of LPC2148 again.
It explains the register of GPIO. From my point of view,
you just randomly access the registers
and don't know what they are doing...

Best regards,

Martin

> i put my code into file section "ADS LCD.rar". From that you are know
> about the pin connection.

Dear Shweta,
Looking at your code, I honestly suggest you to
1. Spend some more time with small program like LED blinking, UART, bin to
hex conversion, LCD etc.
OR
2. Ask your boss to appoint a consultant.

Warm Regards,
Mukund Deshmukh,
Beta Computronics Pvt Ltd,
10/1, IT Park, Parsodi,
Nagpur -440022, INDIA.

Meet us at -
K2010, Booth No. 12C40, 27th Oct - 3rd Nov 2010, Dseldorf, Germany.

I am doing some changes like this:

#define ADC_BYTE (1 << 4)
#define ADC_CONVERT (1 << 6)
#define ADC_BUSY (1 << 5)

#define ADC_D0 (1 << 15)
#define ADC_D1 (1 << 16)
#define ADC_D2 (1 << 17)
#define ADC_D3 (1 << 18)
#define ADC_D4 (1 << 19)
#define ADC_D5 (1 << 20)
#define ADC_D6 (1 << 21)
#define ADC_D7 (1 << 22)

uart1 data is changes automatically. when my input is 0Volt then it display
like this on uart1:
3B 57 57 7F 7F 23 23 7F 7F 7F 7F 41 41 49 49 7F 7F 59 59 7F 7F 79 79 7F 7F
08 08 7F 7F 59 59 7A 7A 7F 7F 7F 7F 7F 7F 6D 6D 7F 7F 71 71 5D 5D 7F 7F 7F
7F 4D 4D 43 43 7F 7F 11 11 2B 2B 3F 3F 7F 7F 0B 0B 43 43 2E 2E 7F 7F 7F 7F
0F 0F 6F 6F 5F 5F 63 63 7D 7D 79 79 49 49 3F 7F 7F 7B 7B 6F 6F 7F 7F 37 37
65 65 7F 7F 4B 4B 7F 7F 5C 5C 7F 7F 5F 5F 05 05 27 27 43 43 75 75 01 01 13
13 3F 3F 39 39 5F 5F 37 37 3F 3F 3F 3F 7F 7F
data is changed automatically. data is not change with the potentiometer.
what can i do?
On Wed, Aug 4, 2010 at 12:15 PM, capiman26061973 wrote:

> Hello,
> > >> i put my code into file section "ADS LCD.rar".
>
> perhaps my doc (data sheet or user manual) is wrong, not up to date),
> but i see
>
> "Pins P0.24, P0.26 and P0.27 are not available"
>
> and you are using this port pin:
>
> #define ADC_BYTE (1 << 27)
>
> To which hardware pin have you connected ADC_BYTE ?
>
> Also please read chapter 8 from user manual of LPC2148 again.
> It explains the register of GPIO. From my point of view,
> you just randomly access the registers
> and don't know what they are doing...
>
> Best regards,
>
> Martin
>
>
>