quote:

---

Originally posted by Madinventions
i=0;
while(numstr [ i ] !=0 && i<4)
{
lcd_gotoxy( i, 1) ;
lcd_putc(numstr [ i ] ) ;
i++;
}


Quick and dirty... there's a million ways to do it better!

[Edited on 6/1/10 by Madinventions]

---

Just used

xacc = ADC
yacc = 0 (Zero)
zacc = -5

Display shows

XACC YACC ZACC
482...0||2...-5||


Does this mean that the xacc=482 showed 482, yacc=0 showed 0||2, and zacc=-5 showed -5|| ? If so then stopping when the null terminator is detected will get rid of the || on the display and the extra '2' in the yacc example.

Adrian - can you confirm this?

Ed.

I wish I could type faster...!

Edit to say: I'm not sure if you can guarantee itoa() to put the null terminator in the right position. In my experience, -15 will convert to "-15<null>' (null in pos 3)and +15 will convert to "15<null>" (null in pos 2) so it is different for positive and negative values, let alone single digit values where the null is in position 1 for positive and position 2 for negative.


I added the ' && i<4' part as a safeguard just in case there is ever a case when the buffer overruns or the itoa() function has a wobbly moment. It's not strictly necessary but it's standard code practice in the line of work I do to make sure every event is covered. It makes for robust code if nothing else.

Ed.

[Edited on 6/1/10 by Madinventions]

[Edited on 6/1/10 by Madinventions]

quote:

---

Originally posted by Madinventions
Just used

xacc = ADC
yacc = 0 (Zero)
zacc = -5

Display shows

XACC YACC ZACC
482...0||2...-5||


Does this mean that the xacc=482 showed 482, yacc=0 showed 0||2, and zacc=-5 showed -5|| ? If so then stopping when the null terminator is detected will get rid of the || on the display and the extra '2' in the yacc example.

Adrian - can you confirm this?

Ed.

I wish I could type faster...!

---

Madinventions
Using ADC/25-19

will display from 10 to -10, still have the issue with the || symbol, but this is a later task.

Still finding it strange, when I have defined xacc as a signed 16 bit interger should it not have a range from - 32767 to + 32767 ?

So still not understanding why (ADC-480)/25 would not work when ADC/25 - 19 does????

I tried at one point ((ADC-480)*5)/2 at one point to get 100 range.

I need to read these replies for a bit longer.

This would have been an ideal thread for the chat room.

So

How do I cope with the variable null position?

Or changing null position even

[Edited on 6-1-10 by AdrianH]

quote:

---

Originally posted by AdrianH
Madinventions
Using ADC/25-19

will display from 10 to -10, still have the issue with the || symbol, but this is a later task.

---

quote:

---

Still finding it strange, when I have defined xacc as a signed 16 bit interger should it not have a range from - 32767 to + 32767 ?

---

quote:

---

So still not understanding why (ADC-480)/25 would not work when ADC/25 - 19 does????

I tried at one point ((ADC-480)*5)/2 at one point to get 100 range.

I need to read these replies for a bit longer.

This would have been an ideal thread for the chat room.

So

---

I have got to add that the members on this board really do blow my mind as to the varied knowledge that is on here.

Flick back to page 2... there's been some editing!

You need to do something like this to check for numstr [ i ] = 0 every time around the loop. If the terminator is found, the routine stops printing.

--CODE--

i=0;
while(numstr [ i ]!=0 && i<4)
{
lcd_gotoxy(i,1);
lcd_putc(numstr[ i ]);
i++;
}

--END OF CODE--

Ed.

[quote][i]Originally posted by AdrianH[/i]
How do I cope with the variable null position?

Or changing null position even

[Edited on 6-1-10 by AdrianH] [/quote]

i=0;
while(numstr[i])
{
lcd_goto...;
lcd_putc...;
i++;
}
This trundles through the string stopping when it gets to the first NULL. itoa had better be putting one in (or you are clearing the string out first as shown in my last post). madinventions code will work fine, but will add code that should never be called if itoa is doing its job.

Out of order threads are sooo hard to read

[Edited on 6/1/10 by iank]

[Edited on 6/1/10 by iank]

I am editing code and trying out in the next few minutes. Will report back, yes posts are getting fun to follow, going back over them and can now see the code from a few posts ago.

Need two computers one to follow and one to programme.

Here is the code section.

code:
 

 

                if(plen==0){ 

                lcd_clrscr(); 

				lcd_puts("Xacc Yacc Zacc"; 

				//select ADC1 and Use 3.3 Vcc as reference with cap at AREF pin 

				//Also set right adjusted in the result 

				ADMUX =0x41; //ADC1 

				delay_ms(1); 

				// start the conversion 

				ADCSRA |= 0x40; 

				while((ADCSRA&0x40) == 0x40){ 

				continue; 

				} 

				xacc = (ADC/25)-19; //put value into xacc 

				itoa(xacc,numstr,10); // convert integer to string 

				i=0; 

				while(numstr [ i ]!=0 && i<4) 

				{ 

				lcd_gotoxy(i,1); 

				lcd_putc(numstr[ i ]); 

				i++; 

				} 

//	ADC2 

				ADMUX =0x42; //ADC2 

				delay_ms(1); 

				// start the conversion 

				ADCSRA |= 0x40; 

				while((ADCSRA&0x40) == 0x40){ 

				continue; 

				} 

				yacc = 0; //put value into xacc 

				itoa(yacc,numstr,10); // convert integer to string			 

				i=0; 

				while(numstr [ i ]!=0 && i<4) 

				{ 

				lcd_gotoxy(i+5,1); 

				lcd_putc(numstr[ i ]); 

				i++; 

				} 

//	ADC3 

				ADMUX =0x43; //ADC3 

				delay_ms(1); 

				// start the conversion 

				ADCSRA |= 0x40; 

				while((ADCSRA&0x40) == 0x40){ 

				continue; 

				} 

				zacc = -5; //put value into xacc 

				itoa(zacc,numstr,10); // convert integer to string 

				i=0; 

				while(numstr [ i ]!=0 && i<4) 

				{ 

				lcd_gotoxy(i+10,1); 

				lcd_putc(numstr[ i ]); 

				i++; 

				} 

				delay_ms(500);				 

				// Ending accellerometer section here				 

				        continue; 

                } 

 

code:
 

 

Xacc  Yacc  Zacc 

0        0      -5 

 

or 

 

Xacc  Yacc  Zacc 

4       0      -5 

EDIT to say 'Yippee!' too!


Ok, there's going to be a formatting problem with my previous code as it doesn't do the decimal point positons for you.

Here's some code that should do it and includes the numstr clearing correctly suggested earlier. Again, I've unwrapped the code to make it easier to follow (hopefully)!! It's not pretty, but...


--CODE--
int16_t xacc=0, // signed integer value for g
char numstr[4]; // string variable

numstr[0]=0;
numstr[1]=0;
numstr[2]=0;
numstr[3]=0;

xacc = (adc/25)-19;
itoa(xacc,numstr,10); // convert integer to string
// 0 = "0", -1 = "-1", -10 = "-10", 1 = "1", 10 = "10"
// Modify so 0 = " 0.0", -1 = "-0.1", -10="-1.0", 1=" 0.1", 10 = " 1.0"
// This will get messy!

if (xacc>=0 && xacc<10) // 0 to 9 -> " 0.0" to " 0.9"
{
lcd_gotoyxy(0,1);
lcd_putc( ' ' ) ;
lcd_gotoyxy(1,1);
lcd_putc( '0' ) ;
lcd_gotoyxy(2,1);
lcd_putc( '.' ) ;
lcd_gotoyxy(3,1);
lcd_putc( numstr[0] ) ;
}

if (xacc>=10) // 10 to 99 -> " 1.0" to " 9.9"
{
lcd_gotoyxy(0,1);
lcd_putc( ' ' ) ;
lcd_gotoyxy(1,1);
lcd_putc( numstr[0] ) ;
lcd_gotoyxy(2,1);
lcd_putc( '.' ) ;
lcd_gotoyxy(3,1);
lcd_putc( numstr[1] ) ;
}

if (xacc>=-10 && xacc<0) // -9 to 0 -> "-0.9" to "-0.1"
{
lcd_gotoyxy(0,1);
lcd_putc( '-' ) ; // could use numstr[0] here...
lcd_gotoyxy(1,1);
lcd_putc( '0' ) ;
lcd_gotoyxy(2,1);
lcd_putc( '.' ) ;
lcd_gotoyxy(3,1);
lcd_putc( numstr[1] ) ;
}

if (xacc<-10) // -10 to -99 -> "-1.0" to "-9.9"
{
lcd_gotoyxy(0,1);
lcd_putc( '-' ) ; // could use numstr[0] here...
lcd_gotoyxy(1,1);
lcd_putc( numstr[1] ) ;
lcd_gotoyxy(2,1);
lcd_putc( '.' ) ;
lcd_gotoyxy(3,1);
lcd_putc( numstr[2] ) ;
}
--END OF CODE--

Ed.

[Edited on 7/1/10 by Madinventions]

Can I thank you all enough!

Excellent

There's plenty of tidying up/optimisation possible but that's easy once it's producing the right results.

No problem, glad we could help!

It just goes to show that LocostBuilders can normally come up with an answer for anything!

Ed.

how did i miss this one you guys had all the fun without me.

oh that was it i was out dragging the other half home.

Just re tied thexacc (ADC-480)/25 and whilst it goes positive when I go negative it displays 2612.

So that is another evening play, the display being sorted goes a lot further to my understanding of it all.

The project when completed will hopefully have, and this will be many moons away, a 3 axis g meter, rev counter and a wheel turns counter providing mph.

In effect a simple tech meter along the lines of the Gtech gear.

Also plan to send data to USB stick if at all possible for Excell work.

It keeps the grety matter ticking and at passed mid-life I need it.

Thanks again for the help from you.



Hi Ash you can tell the weather is crap, I'm back at the computer for hours!

[Edited on 7-1-10 by AdrianH]

Oooh this is starting to sound stunningly familiar! I made a touchscreen controller for my Mojo that reads a 3 axis accelerometer, tacho, speed and the OBD data from the Ford ECU! It also had datalogging to a SD card, and I added shift lights and a 0-60 timer just for fun. The code for this will be getting an overview soon as I'm upgrading to a Megasquirt system so I need to rehash it all to interface with that to get coolant temperatures etc. I used a PIC 18F8722 for my board and coded it all with the Swordfish PICBasic compiler.





Link to my website...

Anyhoo - I couldn't resist having another little fiddle with the code so far!

void PrintAcc(adcval as int16_t, pos as int8_t)
// adcval is 0-1023 adc reading, pos is position to print on the lcd.
{
char numstr[4]; // string variable

numstr[0]=0;
numstr[1]=0;
numstr[2]=0;
numstr[3]=0;

adcval = (adcval/25)-19;
itoa(adcval,numstr,10); // convert integer to string

//This is the formatting that needs to occur:
//value itoa() display
//-10 "-10" "-1.0"
//-1 "-1" "-0.1"
// 0 "0" " 0.0"
// 1 "1" " 0.1"
// 10 "10" " 1.0"


if (adcval>=0 && adcval<10) // 0 to 9 -> " 0.0" to " 0.9"
{
lcd_gotoyxy(0+pos,1);
lcd_putc( ' ' ) ;
lcd_gotoyxy(1+pos,1);
lcd_putc( '0' ) ;
lcd_gotoyxy(2+pos,1);
lcd_putc( '.' ) ;
lcd_gotoyxy(3+pos,1);
lcd_putc( numstr[0] ) ;
}

if (adcval>=10) // 10 to 99 -> " 1.0" to " 9.9"
{
lcd_gotoyxy(0+pos,1);
lcd_putc( ' ' ) ;
lcd_gotoyxy(1+pos,1);
lcd_putc( numstr[0] ) ;
lcd_gotoyxy(2+pos,1);
lcd_putc( '.' ) ;
lcd_gotoyxy(3+pos,1);
lcd_putc( numstr[1] ) ;
}

if (adcval>=-10 && adcval<0) // -9 to 0 -> "-0.9" to "-0.1"
{
lcd_gotoyxy(0+pos,1);
lcd_putc( '-' ) ; // could use numstr[0] here...
lcd_gotoyxy(1+pos,1);
lcd_putc( '0' ) ;
lcd_gotoyxy(2+pos,1);
lcd_putc( '.' ) ;
lcd_gotoyxy(3+pos,1);
lcd_putc( numstr[1] ) ;
}

if (adcval<-10) // -10 to -99 -> "-1.0" to "-9.9"
{
lcd_gotoyxy(0+pos,1);
lcd_putc( '-' ) ; // could use numstr[0] here...
lcd_gotoyxy(1+pos,1);
lcd_putc( numstr[1] ) ;
lcd_gotoyxy(2+pos,1);
lcd_putc( '.' ) ;
lcd_gotoyxy(3+pos,1);
lcd_putc( numstr[2] ) ;
}
}

void convert()
{
delay_ms(1);
// start the conversion
ADCSRA |= 0x40;
while((ADCSRA&0x40) == 0x40)
{
continue;
}
}

void main()
{
while(1)
{
lcd_clrscr();
lcd_puts("Xacc Yacc Zacc";
//select ADC1 and Use 3.3 Vcc as reference with cap at AREF pin
//Also set right adjusted in the result
// ADC1
ADMUX =0x41; // ADC1
convert(); // Start the conversion and wait for completion...
PrintAcc(ADC,0);// Convert, format, and print the result.

// ADC2
ADMUX =0x42; // ADC2
convert();
PrintAcc(ADC,5);

// ADC3
ADMUX =0x43; // ADC3
convert();
PrintAcc(ADC,10);
}

delay_ms(250);
}

I've basically chucked a few of the parts into subroutines and tidied up a few bits. It may or may not help?

Ed.

[Edited on 7/1/10 by Madinventions]

That looks very good indeed.

Just using the Atmega 168 here with free software from Atmel the Studio 4 package that also uses GCC. I play and fiddle until stuff works, as you can probably tell.

But! and this is a big but for me. I need a reason to learn code, to just try and follow a book does not get it in my head. I need a reason to continue with something or else I can give it up.

All done on the cheep side here, as mentioned my board came from tuxgraphics together with the programming lead. The board is the surface mount one with a web type interface. Have used it before as a type of link between two boards to measure latency through the Internet and monitor TTL and battery voltage. A sort of remote monitoring tool if you will.

But now want something for the car.

I will go through your code later today, try and understand what it is doing and go on from there. I now understand the null pointer section and now realise I need to reformat it to show 0.x value or - 0.x value.

The maths will work if I use (ADC/2.5)-192 to give 0 to 100 display. So still to figure why (ADC-480)/25 will not work out.

But too late for now.

Cheers and thanks again.

Adrian

p.s

sure the last posts and this one disappeared from the forum, then came back again. Must be me!

[Edited on 7-1-10 by AdrianH]

Ok, one last quick thought before I go and find somewhere warm (I'm in the workshop and my calor gas heater has just run out... brr!!)

You'll probably find that the ADC variable is declared somewhere as a uint16. Therefore if you have an ADC value of say 230 and the routine has the function (ADC-480)/25 then the compiler will first try to calculate 230-480 (ignore the /25 for now). Using signed math this will be = -250. Correct. However, if ADC is a uint, the compiler will assume that the '480' is also a uint and will do the calculation using unsigned integers (0-65535). Negative values are not allowed in the result so it will 'wrap-around' and give you a value of 65536-250 = 65286. When this is divided by 25 you get the 2612 you see on the display.

So, you either need to copy the ADC value into a int16 variable before using it in this formula, or you need to typecast the ADC variable to force the compiler to use signed math and be aware that it may have to handle negative values.

int16_t adcval;
adcval = adc;
xacc = (adcval-480)/25;

or the typecast version:

xacc = ((int16)ADC-480)/25;

The actual syntax may be slightly different from this but this is one of the standard pitfalls of integers and C coding!

Hope this helps, let us know how you get on.

Best regards,
Ed.

[Edited on 7/1/10 by Madinventions]

Wish I never started reading this thread my brain really hurts now.
Cheers,
Bob

all of a sudden i feel really stupid!

Yep - that's how I feel when I try to weld 2 bits of metal together!

Microcontroller programming: no problem.
Welding: Fire, pain, pigeon poo, disaster.



Ed.

quote:

---

Originally posted by AdrianH

The maths will work if I use (ADC/2.5)-192 to give 0 to 100 display. So still to figure why (ADC-480)/25 will not work out.

---

not sure if i'm talking down & apologise if i am. Just in case you're not aware ...


Integer - whole number only eg 3, 12, 21. Can't do 2.4. Has a range of 0-???? if 8bit 256, if 16 bit 64,000ish (ok 65,500ish)

Signed integer - same as integer but the first half of the number is classed as negative. Eg 16 bit signed integer is -32000 to +32000 instead of 0 to 64000. If you started with the very first value and added 1 to it it would be classed as -31999, if you add 32000 to it, the computer thinks its actually 0.

If you want to have a value with a decimal point it it, ie a real number you need to use floating point. the problem with floating point point is that its a) slow and b) (scarily) imprecise. For reasons i won't go into the computer doesn't hold the actual number like 2.5 is holds an approximation that would be something 2.500000000001. This can then mess you up when you start doing something like 2.5 - 2.5 and expecting 0.

If you try to do integer / floating point the computer will (depending on the complier) try to do something - but you can't guarantee what it will do without experimentation and its likely to not do what you want unless you're being REALLY clever. We used to do tricks of writing 100 character strings into a 1 character strings knowing it would overwrite the next 99 characters. This was deliberate as it was faster than 20 or 30 separate writes which is what it really needed.

quote:

---

Originally posted by MikeR
not sure if i'm talking down & apologise if i am. Just in case you're not aware ...



Signed integer - same as integer but the first half of the number is classed as negative. Eg 16 bit signed integer is -32000 to +32000 instead of 0 to 64000. If you started with the very first value and added 1 to it it would be classed as -31999, if you add 32000 to it, the computer thinks its actually 0.

---

eeek - its been a while. having to read up again now to relearn what i've obviously forgotten from my PC coding days. Sorry for the miss-information.

(i do vaguely remember at uni make up a adders circuit using logic gates - which i seem to recall needed two half adders which was a combination of AND gates plus something else).

quote:

---

Originally posted by MikeR
If you want to have a value with a decimal point it it, ie a real number you need to use floating point.

---

code:
 

while( ( numstr[ i ] !=0 ) && ( i<4 ) )  

{  

	lcd_gotoxy(i+10,1);  

	lcd_putc(numstr[ i ]);  

	i++;  

}  

 

 

lcd_gotoxy(10,1);  

while( ( numstr[ i ] !=0 ) && ( i<4 ) )  

{  

	lcd_putc(numstr[ i ]);  

	i++;  

}  

code:
 

/** 

 * Write a null terminated string to the LCD. 

 * Assumes cursor is at correct location prior to calling. 

 * @param str Pointer to null terminated string. 

 */ 

void lcd_puts( char *str ) 

{ 

    while( *str ) 

    { 

        lcd_putc( *str++ ); 

    } 

} 

 

 

/** 

 * Write a null terminated string to the LCD up to specified number of characters. 

 * Assumes cursor is at correct location prior to calling. 

 * @param str Pointer to null terminated string. 

 * @param len Number of characters to write. 

 */ 

void lcd_putsn( char *str, unsigned int len ) 

{ 

    while( *str && len ) 

    { 

        lcd_putc( *str++ ); 

        len--; 

    } 

} 

quote:

---

Originally posted by MikeR
eeek - its been a while. having to read up again now to relearn what i've obviously forgotten from my PC coding days. Sorry for the miss-information.

(i do vaguely remember at uni make up a adders circuit using logic gates - which i seem to recall needed two half adders which was a combination of AND gates plus something else).

---

quote:

---

Originally posted by MikeRJ

quote:

---

Originally posted by MikeR
If you want to have a value with a decimal point it it, ie a real number you need to use floating point.

---

You only need floating point maths when you are dealing with numbers that have a very large range, i.e. they can be very small or very large, and the floating point allows you to trade off resolution against range.

In the vast majority of embedded applications you can get away without using floating point maths, by using fixed point maths instead. Normally you would not scale intermediate values by factors of ten, but rather by factors of two since this gives you the most efficient/fastest calculations (though obvioulsy you need to scale the final result by a power of ten to display decimal places).

---

More and more input, will have to catch up after a club meet.

On number types types I will work out how the compiler is working but putting in fixed values and seeing what the result is working out at.

I believe some compilers could work out the maths in floating point if a floating point number was used, but if the end result was an integer, you would loose the decimal at the end. Could well be wrong, as I am really only a beginner, it is a pass time not a careerer with me and just helps me think logically sometimes!

The LCD routines are all pre written, using 4 bits of the I/O port, there is clear screen which sets cursor to top right, has functions for characters and strings and cursor position and probably a few I do not know yet.

On the AVR forum there are others the atmega devices to USB, sticks, but memory cards would be fine also.

Things have moved on a lot since I originally did a weather satellite decoding system with 8 bit resolution (grey ) on the old Z80 processor.

Anyone remember Nascom?

Adrian

quote:

---

Originally posted by AdrianH
...
Anyone remember Nascom?

Adrian

---

I have tried something simple to check out the maths bit, that is to see how the compiler is dealing with the division by 2.5.


So I used xacc = (500/2.5)-196 and the answer on the screen was 4

So it looks as though the compiler is dealing with the decimal divide correctly.

This was my thinking. If it trunkated the 2.5 to 2 the answer would have been 54

If it rounded 2.5 up to 3 then the anser would have been -29

I then checked with xacc = (600/2.5)-196 and the answer on the screen was 44. This just seeming to confirm the bit above.

I then used xacc = (303/2.5)-196 On a calculator the answer is -74.8 and the display is -74 s

xacc = (503/2.5)-196 indicates 5 on the display(should be 5.2)

So it is showing that the compiler uses what ever number type it thinks is correct, but then chops the decimal point for the integer required result. I think this is good as the error should be minimised.

Adrian
o it is indicating to me that

I think that when the compiler sees '2.5' it knows it has to do the calculation with floating point math. If you put in a '2' it would use integer math.
The reason it is losing the decimal after conversion is that xacc is defined as an integer.
If speed isn't an issue and you're not trying to conserve memory, then floating point will be fine. Integer math will be considerably faster, but the conversion to readable format is a bit more involved as we've seen.

Try making xacc a float variable, and use ftoa() instead of itoa(). You should get decimal values on your display if that's what you want.

Ed.

Sorry for not getting back to you before.

Just playing around a bit more with code and following one of your previos posts on why I got the 26612 number.

and as you said it must be down to the type of ADC.

Using another variable as

int16_t acc =0;

then in the code

xacc= (acc-480)/2.5 it all works as expected.

Using the time to go through the posts and slowly learn by trying it all out step by step and trying to follow what is happening. Time for sleep I think and more tomorrow, I will look for ftoa in the complier liberies and see if in there and how it works etc.

quote:

---

Originally posted by AdrianH
I have tried something simple to check out the maths bit, that is to see how the compiler is dealing with the division by 2.5.


So I used xacc = (500/2.5)-196 and the answer on the screen was 4

So it looks as though the compiler is dealing with the decimal divide correctly.

---

quote:

---

Originally posted by AdrianH

xacc= (acc-480)/2.5 it all works as expected.

---

Thanks for the input Mike.

I had a bit of time and stripped off of the superflous code out of this programme, I had it answering pings and had a web page etc.

So now all it will actually do is use the ADC and write the results to the screen

The programme was just over 3 K at 20%

With the change so not using 2.5 as above reduced to 9% at 1.5 K sh programme.

Speed has not really increased but this will be down to use of simple delays I have so I can read the LCD.

Cheers

Adrian