OLED SSD1306 via HW-SPI // AVR Studio - 328P

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Converting double value to string - Wrong output - direct intervention to 
display result.
- MCU = Atmega328P / F_CPU = int. 8MHz
- Temperature Sensor: TSIC 206 (digital)
- Volatage: Voltage divider, R1:169k, R2:10k
- 

What is the expected output? What do you see instead?
Expected:
*********
- Display converted temperature & voltage value on the ssd1306 128x64.
- TSIC (3 connections) VCC connected to PC3, Data to PC2, GND-GND. 
- Volatage divider - Measuring input voltage before analog voltage regulator 
PC4. 

Instead:
********
- Displayed values are inaccurate, it should display ~ +24°C but it jumps from 
-23.something to 6303.6 and back all the time. When heating the sensor the 
values change to -22..-21..(inclusive comma and jumping to 1000-values). Code 
was working for alphanumeric displays. Calculation is 100% correct. 

What version of the product are you using? On what operating system?
1.10 using AVR Studio 6.0.1996 on WIN7 x64. (AVRGCC - 3.4.1.95)

Please provide any additional information below.

I assume it has to do with the information conversion and display string, since 
it worked on an alphanumeric display. External functions of the display loop 
should not be interrupted by the display loop right? 

When adding a * to the voltage and temperature variable it directly influences 
the display result, the display takes a few seconds to create the picture and 
the values are incorrect (filling the line with pixels). Unfortunately i am not 
professional @ C, but why is it influencing the output on the whole line when 
it is just a string variable with a length of 5?? (attachment) .

Of course, you should add the Tsic.c & .h to your library if you like. 
It's the same for Tsic 206 & 306 zacwire protocol.
Tsic 206: http://www.mikrocontroller.net/part/TSIC206

Could you please have a look into this??
Thank you in advance /!\

Original issue reported on code.google.com by Tsku...@gmail.com on 1 Mar 2013 at 8:14

Attachments:

• Caroled.c
• Tsic.c
• Tsic.h

[GoogleCodeExporter]

Can you also provide the "100% working" code from the Character LCD?

What you claim is, that a certain string, which looks like
"20.435" is displayed as "6030.4" or something similar.
Please also provide a more simpler example were I see that 
drawStr(..., "20.435") will be displayed as wrong value.

Thanks, Oliver

Original comment by olikr...@gmail.com on 1 Mar 2013 at 10:03

[GoogleCodeExporter]

Of course, the code and a picture i still have of it is attached. It was for an 
8x2 LCD with an HD44780 controller.

Not quite, if i put out a constant string, like "u8g_DrawStr(&u8g, 20, 40, 
"T=");" it will be displayed correctly. If i have just integer variables as 
string - tested a simple counter counting up and it was displayed correctly. - 
attachment
If i use double variables (using dtostrf() instead of itoa()) and add 0.2 in a 
loop like counter.c for example, it works fine too. With sensor, it worked for 
the HD44780 - attachment. The sensor is active, values are changing rapidly 
when touching it :), just the value is wrong displayed. 

Thanks for looking into this!! J

Original comment by Tsku...@gmail.com on 1 Mar 2013 at 3:03

Attachments:

• LCD_Car.c
• lcdlib.c
• lcdlib.h
• HD44780_LCD.jpg
• Counter.c

[GoogleCodeExporter]

It seems that there is a problem with the calculation or conversion. 
The values are (when it should have ~ +24°C) from -22 to -24 with floating 
points, when heated -22..-21.. and jumps just to 6153,5 and 3151,5 like just 
these two values represent values inbetween. For example 22.1 - 6153,5 - 22.3 - 
3151,5 -... but not for every temperature value.. argh... this must be easy and 
obvious :D

Thanks for helping me out on this!!

Original comment by Tsku...@gmail.com on 1 Mar 2013 at 4:07

[GoogleCodeExporter]

so you fixed the error?

Original comment by olikr...@gmail.com on 1 Mar 2013 at 7:00

[GoogleCodeExporter]

No, unfortunately i haven't until now.

The display loop shouldn't affect other variables and functions right? 
Then i cannot explain why this is happening. Maybe it is a faulty sensor, but i 
doubt it.. i have to do some tests..
Could the compiler "optimize" something it shouldn't optimize? 

Original comment by Tsku...@gmail.com on 2 Mar 2013 at 8:28

[GoogleCodeExporter]

Also by comparing both c files, i do not see something completly wrong.
Some ideas:
     Temp_celsius = ((float)temperatur / 2047 * 200) - 50;           // (temperatur * 0.097704) -50; calculate temperature value from 11-Bit temperature information
should be better replaced by
     Temp_celsius = ((float)temperatur / 2047.0 * 200.0) - 50.0;           // (temperatur * 0.097704) -50; calculate temperature value from 11-Bit temperature information

At least during testing.

Another point: I do not know the string conversion procedure. Maybe t[10] 
should be a larger array.

Finally: In order for me to support you better, i need a hardware independent 
piece of software, which reproduces the problem.
For example read_tsic retuning a sequence of fixed numbers, so that i can see 
the problem withing u8glib.

At the moment i do not think that u8glib is causing trouble here.

Original comment by olikr...@gmail.com on 2 Mar 2013 at 9:01

[GoogleCodeExporter]

I know what is causing the problem now, but i don't know how to fix it.. i need 
to try a few things.. 
The compiler optimizes something away which it shouldn't. Tampering with the 
options led me to this - it directly influences the displayed values. Is there 
a possibilty to only optimize for size and nothing else for the Tsic?, some 
kind of attributes ?

Yes, u8glib is not causing this issue. 
As so far, Tsic.c & .h should work fine, but i only have used optimize for size 
before, but no garbage collecting nor -fdata & -sections. It seems this is 
causing trouble. So i have to use the "volatile" attribute on some variables 
right? 

Thanks for taking time for this!

Original comment by Tsku...@gmail.com on 2 Mar 2013 at 10:28

[GoogleCodeExporter]

I do not know how "-fdata & -sections" could have effect on the code. Maybe you 
have used some other options. "-Os" was suggested for AVR development. Usually 
"volatile" is only required if you share information between interrupt and 
none-interrrupt procedures.

Original comment by olikr...@gmail.com on 2 Mar 2013 at 10:58

[GoogleCodeExporter]

Yes, i do not have too much experience with C. 
- OK. -fdata & sections do not have any affect on code generation as well as 
garbage collection. No other options were used. 
For the library, it is -Os. 
For the test file it is -O3 and the flickering to 6153 goes away.. but the 
value is still wrong. No other optimization level makes any difference - only 
in size. 
-Could it be possible that the Hardware SPI routines are interfering??
As far is i understood "volatile" tells the compiler not to optimize the 
virtual data -for example a button press value from a random subroutine.. & pin 
states - if not volatile, it would read out some virtual value..

Original comment by Tsku...@gmail.com on 2 Mar 2013 at 12:31

[GoogleCodeExporter]

A memory location which has been declared with the "volatile" statement tells 
the compiler to always use the value from that memory location for any 
calculation.
The compiler is especially not allowed to store the value in a processor 
registor for a long time.

Original comment by olikr...@gmail.com on 2 Mar 2013 at 2:37

[GoogleCodeExporter]

I have found the error. Please close the issue :)

The Tsic.c and Tsic.h are totally fine. (so are the lcd files if you want to 
add all of them)
- Use boolean return value of getTsictemp(&variable) 0=Parr err. 1=measured, 
wrote to variable. 
- Use any variable as "variable" with at least 11-Bit so uint16. 
- Measurement just via software - no interrupts

If you need anything/sth. missing let me know before you close.

Thank you for investing time and trying to help me out !!

Greetz, Joseph

Original comment by Tsku...@gmail.com on 4 Mar 2013 at 10:21

[GoogleCodeExporter]

Thanks for keeping me informed. I will close this issue.

Original comment by olikr...@gmail.com on 4 Mar 2013 at 12:29

• Changed state: Done
• Added labels: Milestone-1.12, Type-Other
• Removed labels: Type-Defect