Release candidate for Z-Uno software version 2.0.7

Discussion about Z-Uno product. Visit http://z-uno.z-wave.me for more details.
User avatar
PoltoS
Posts: 5887
Joined: 26 Jan 2011 19:36

Release candidate for Z-Uno software version 2.0.7

Post by PoltoS »

Dear advanced users!

We have released test version 2.0.7 for Z-Uno. To test it please follow this instruction: Change package source URL to http://z-uno.z-wave.me/files/z-uno/test ... index.json. Remove current Z-Uno file (better on the filesystem). Install 2.0.7 from Board Manager.

New features in 2.0.7:
  • IR controller
    - Learn IR commands into mark/space sequence
    - Send IR commands from mark/space sequence
    - Comparison of mark/space sequences
    - Coding/decoding for popular IR protocols: SONY/NEC/LG/RC5/RC6/SAMSUNG/PANASONIC
    - 3 ready to go sketches in examples: IRScanner/IR2ZWave/ZWave2IR
  • Meter Command Class
    - COMMAND_CLASS_METER version 4 support
    - Example for two channels (hot/cold) water meter: WaterMeter
  • Libraries:
    - New library ZUNO_MCP4725 for I2C DAC MCP4725. Community contribution by @michap.
    - New library ZUNO_BH1750 for light sensor BH1750. Community contribution by @A.Harrenberg
    - ZUNO_ONEWIRE lib can now scan the bus.
    - ZUNO_DS18B20 lib can search for all DS18B20 on the OneWire bus. Added example: DS18B20Sacnner.
    - ZMEKeypad new function isIdled() added to the lib to check if buttons are active or idle (to go to sleep only on idle).
  • Compatibility:
    - New parameter #12 added for correct work of Sensor Binary/Notification channels in Fibaro Home Center 2/Lite.
Fixes:
  • uCxx Compiler:
    - Multidimensional arrays definition fixed.
    - Dots in file names now work.
    - // comments in ZUNO_* macro work.
    - Warinings on local char * supressed.
    - Optimized pointer to this to minimize stack usage.
    - Optimized pointers parameters in function calls to minimize stack usage. All but char are now passed via XDATA instead of generic pointers.
    - Changed flags to SDCC to minimize stack usage (removed SLOCs).
    - Keypad restart after sleep fixed.
    - delayMicroseconds() precision up to 1 microsecond.
  • Libraries:
    - Wire. Bug with two bytes locations. Affected 16-bit registers in BMP180.
    - ZUNO_BMP180. Fixed inaccurate rounding of pressure.
    - ZUNO_ONEWIRE. Fixed intervals in OneWire bus handling with accurate delayMicroseconds.
    - ZUNO_DS18B20. Fixed timings depending on sensor resolution. Fixed problem with negative values. Thanks to @michap for contribution.

michap
Posts: 374
Joined: 26 Mar 2013 10:35
Contact:

Re: Release candidate for Z-Uno software version 2.0.7

Post by michap »

I have different problems with 2.07 compairing with 2.06

Some calculations get wrong and some calls do not work more inside my libs (I had to make these calls more correct)
So a good testing would be fine (not sure, I'm the only one with problems ;) ....)

(Working) sketchs seems to be smaller after compiling.

Michael

A.Harrenberg
Posts: 201
Joined: 05 Sep 2016 22:27

Re: Release candidate for Z-Uno software version 2.0.7

Post by A.Harrenberg »

Hi,

I updated yesterday night and did some very short testing this morning while eating my breakfast...
I also noted something strange... I am at work now, so I have to describe it based on my (limited) memory..

I have a byte declared in one function, let's say

Code: Select all

byte bufferSize = sizeof(buffer_array);
, which is "2" as the array is defined with size 2. Then a pointer to that variable is passed to another function call. Like this:

Code: Select all

testfunction( &bufferSize);
where testfunction is declared as "testfunction (byte *size)"
In "testfunction" the variable size is evaluated as "0" and not "2", so something seems to be wrong when passing arguments.

I don't know what this:
- Optimized pointers parameters in function calls to minimize stack usage. All but char are now passed via XDATA instead of generic pointers.
exactly means, but I guess it is connected to what I see here.

Regards,
Andreas.
fhem.de - ZWave development support

p0lyg0n1
Posts: 183
Joined: 04 Aug 2016 07:14

Re: Release candidate for Z-Uno software version 2.0.7

Post by p0lyg0n1 »

Hi, Andreas.
Can you, please, check the same code with this:

Code: Select all

static byte bufferSize;
bufferSize = sizeof(buffer_array);
testfunction( &bufferSize);
This code will be 100% work if you create bufferSize in the global area.

A.Harrenberg
Posts: 201
Joined: 05 Sep 2016 22:27

Re: Release candidate for Z-Uno software version 2.0.7

Post by A.Harrenberg »

Hi,
I can only try this earliest tomorrow evening and will give a feedback as soon as I have analyzed it.

Regards,
Andreas.
fhem.de - ZWave development support

michap
Posts: 374
Joined: 26 Mar 2013 10:35
Contact:

Re: Release candidate for Z-Uno software version 2.0.7

Post by michap »

Can you tell me why this is not working more?
(was working in 2.0.6)

Code: Select all

long uP; //defined in .h file
char data[8]; //defined in .h file

in .cpp file:
uP = (data[0]*4096) + (data[1]*16) + (data[2]/16) ;
result will be wrong, like 79*4096+ 108*16 + 48/16 -> 4294963200
(printed out from debug print)

Already tried different things (with (long) inside ... etc.) , no idea.

Michael

michap
Posts: 374
Joined: 26 Mar 2013 10:35
Contact:

Re: Release candidate for Z-Uno software version 2.0.7

Post by michap »

Some more details:
Working only (in 2.0.7):

Code: Select all

uT = (int32_t)(data[3])*4096 + (int32_t)(data[4])*16 + data[5]/16;
And Working:

Code: Select all

  uT = (int32_t)data[3] << 16;
  uT |= (int32_t)data[4] << 8;
  uT |= data[5];
  uT = uT >> 4;
Michael

p0lyg0n1
Posts: 183
Joined: 04 Aug 2016 07:14

Re: Release candidate for Z-Uno software version 2.0.7

Post by p0lyg0n1 »

It have to fail on 2.0.6 too....

Just do it together step by step.

There are some very important moments for 8051 that we have to check and discuss.

1. Check the code. "The black box" method.

Just create a simple sketch with your code inside:

Code: Select all

long uP; //defined in .h file
char data[8]={79,108,48,00,00,00,00,00}; //defined in .h file

void setup() {
  // put your setup code here, to run once:
  Serial.begin();
}

void loop() {
  // put your main code here, to run repeatedly:
  uP = (data[0]*4096) + (data[1]*16) + (data[2]/16) ;
  Serial.print("uP =");
  Serial.println(uP);
  delay(100);
  
}
Try to compile it with 2.0.6 first
and we have an output:

Code: Select all

uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
What!? We have to see 79*4096 + 108*16 + 48/16 = [where is my calc!?] = 325315
May be 2.0.7 will be ok?
...and we have

Code: Select all

uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
uP =-2365
What did happened?
The first problem there is an evident overflow:

(data[0]*4096)

the first operand is byte, the second is word (constant).The result have to be 323584. But, by default any compiler will try to use the size of the architecture accumulator. The size of this for 8051 is 8bits and it fails. This code will work normally on x86 because its accumulator register (EAX) is 32bit long.

try

Code: Select all

#include <stdio.h>
long uP; //defined in .h file
char data[8]={79, 108,48,00,00,00,00,00}; //defined in .h file

void main()
{
        uP = (data[0]*4096); //+ (data[1]*16) + (data[2]/16) ;
        printf("uP = %d\n", uP);

}

gcc test.c
./a.out

You will see:
uP = 323584
Pretty cool.
We have to say on 8051 that he have to use 32bit result instead of 8-bit:

Code: Select all

uP = ((unsigned long)data[0]*4096);
and it works right:

Code: Select all

uP =323584
uP =323584
uP =323584
uP =323584
uP =323584
With the second part we have the same problem, cause you shift 180 4 bits left and have a byte overflow too. Just fix it like this:

Code: Select all

uP = ((unsigned long)data[0]*4096) +  ((word)data[1]*16) + (data[2]/16);

Now we have

Code: Select all

uP =325315
uP =325315
uP =325315
uP =325315
uP =325315
uP =325315
uP =325315
uP =325315
uP =325315
uP =325315
We can write the final statement another way (using shifts and bit operations):

Code: Select all

uP = data[0];
uP <<= 8;
uP |= data[1];
uP <<= 4;
uP |= (data[2] >> 4);
and we have:

Code: Select all

uP =325315
uP =325315
uP =325315
uP =325315
uP =325315
uP =325315
uP =325315
The final question why do we use signed values for data?
The range of char is [-127;128]. I think that we have to use byte instead of this. This prevent us from many strange errors in case if we use operators * and / instead of shifts and bit wise operations.
Use the last variant of code it will be optimal by speed and size and it's a "pro" style.

Hope this small post will help you with your code. ;-)


PS. I tested all code with 2.0.6 & 2.0.7. They have the same output. You can try it yourself.

Alex.

michap
Posts: 374
Joined: 26 Mar 2013 10:35
Contact:

Re: Release candidate for Z-Uno software version 2.0.7

Post by michap »

Hi,

thank you for explaining.

But it was not a dream ;) - The lib was working in "my" 2.06 before updating to 2.0.7.
I do not know why, but it was happen.

Can not demonstrate it more, because of the current 2.0.6 is an other as the old one.
Maybe it was updated in the meantime?

I had a working BMP280 and BME280 lib - some people here in office have it seen ;)

It's ok to do it right now, I was only really confused ;)
---------------------------------------
There is another change in 2.0.7:
I have a function:
char BMP280::readBytes(char address, char length)
{....
data[x] = Wire.read();
return (1);
}

then I have used in other function the call
readBytes(0xE4,1);
instead of
result = readBytes(0xE4,1);

new compiler does not like if function will give return value - but you do not assign the return value to anything when calling function
(the return value is used for error detection)

This is of course not a compiler error - but was my mistake.

Thanks again!
Michael

michap
Posts: 374
Joined: 26 Mar 2013 10:35
Contact:

Re: Release candidate for Z-Uno software version 2.0.7

Post by michap »

BTW: my 2.0.7 "issues" about the calculation tests happen because of a simple typo :-D

I used in my tests
test=(unsigned long)(1000*4096);
instead of
test=((unsigned long)1000*4096);

Then you will get such funny results :-D

But anyway my old sensor with BME280 is still working with old 2.0.6 code - not more compiling at 2.0.7
I think there are some declaration errors inside my code- and the previous compiler have skipped it and "corrected" it.

So it's a good idea to check this test code in detail (it was still not prepaired for "production") and make it right :)

Thank you again for your help!

Michael

Post Reply