ZLLdemo bitcloud V3.1.0

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Currently I use AS6.2 with Bitcloud V3.1.0
Everything works OK but the compile time of the ZLLdemo takes really long, approx. 10min.

Does anyone now what might be the problem?
Is it in the makefile?

My pc is a i7-920 @ 3.5Ghz with 16GB ram and the OS is Windows 7 x64.
I have no network drives mapped and everything runs from a SSD.

Thanks in advance.

Last Edited: Fri. Oct 16, 2015 - 12:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are a lot of files to compile and Makefiles don't keep track of updated files, so it is forced to recompile everything.

 

Also be aware that ZLL is a very specific protocol with very limited usability for hobbyists.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your reply.

 

But it seems something goes wrong since I've build larger projects way faster than this.

When I compile the project using IAR it takes about 1 min.

 

I've enabled parallel build on Atmel studio 6.2.

Did anyone also compile the ZLLdemo project, if so how long did it take?

 

I also see other people complaining about AS being slow.

Could it be a problem in Atmel studio or Visual studio?

 

I also did try to compile the project on a Windows 8.1 x64 Intel Xeon E3-1230V2 machine but it was just as slow.

 

Hopefully someone can help.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In case of BitCloud application you can't blame AS. It just calls an external Makefile.

 

I don't remember it being that slow, but it is not fast. Mainly, GCC under Windows is very slow. I'm not sure exactly why.

 

With IAR it takes about a minute for me as well, but I've never tried to compile ZLL project from studio. Once again, your product build from that source might be not certifiable.  I believe we've only got CZP certification for IAR version. And I'm not sure is compiler switch triggers complete re-certification. And without certification your product will not be compatible with anything on the market.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My build also takes about 10minutes in AS

 

I'm also trying to use ZLL on this ATmega256RFR2 XPRO board, not having much luck.  If you're able to get it to work I'd like some pointers :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bVector,

 

If you provide a better problem description someone might be able to help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've now got a problem when compiling ZLLdemo in bitcloud V3.1.0 using IAR.

 

When using Atmel studio everything works OK, it also did when using V3.0.0 and IAR.
Now when I compile V3.1.0 using IAR (v6.40.3) the APL_taskHandler is never reached.

The SYS_taskflag is always 0x12.

 

Anyone an idea of what might be the problem or how I can debug this problem further?

 

Thanks.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you configure CS_UID to be non-zero?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex,

 

CS_UID is zero. but I believe it is then read from the signature memory, in:APL_Taskhandler->init().

But when compiling with IAR this task is never reached (SYS_taskflag is always 0x12).

 

If it is any help I run the code on a ATmega256RFR2 Xplained Pro board, with the ZLLdemo build as color light.

I also build exactly the same project for a IAR and AS, so the code is the same in both cases.

I can confirm the UID is non-zero for the AS build because I can see its address, and control the light using deCONZ (from dresden elektronik). 

 

Hopefully you've got any idea as to what goes wrong.

 

Thanks.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before APL_Taskhandler() is called, stack tries to read the ID from the external chip. So try setting CS_UID to a non-zero value first.

 

I don't know why it would work in AS though.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex,

 

I did set CS_UID to be non-zero, the same problem persists unfortunately.

 

Do you have any other ideas as to why only the HAL_TASK_ID and ZDO_TASK_ID gets set?

Or maybe you've got a suggestion how to debug this since both tasks are library calls.

 

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
Makefiles don't keep track of updated files

I thought that was the whole point of make?!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It might be a problem with IAR version. I can't say for sure. I use IAR 7.20.1 and it works fine with this release.

 

I really don't see why it would be stuck at ZDO task, all it does is resets the stack and posts APL task.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
I thought that was the whole point of make?!
Not really. Makefiles are just a list of instructions. Some instructions might include calls to the compiler to generate dependency information and include this information later. In case of BitCloud build system is so complicated (for various historical reasons), that compilers can't track all the dependencies properly.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

Because I didn't seem to get IAR working and AS is to slow I now use the atmel toolchain and Eclipse in a Kubuntu virtual machine.

Everything works fine now and the ZLLdemo project compiles in several second using only 1 core.

 

At first the project wouldn't compile as it was complaining about *.o no such file or directory.

There appear to be some problems in the makefile and in the #include "'*.h" statements.

To fix this make sure that all paths in the makefile and all #include paths in the source code are correct: LINUX IS CASE SENSITIVE!

 

 

The following message appears when trying to build using more than 1 core:

warning: jobserver unavailable: using -j1.  Add `+' to parent make rule

Since I know nothing of makefiles maybe someone knows why only one core can be used?

 

 

Hopefully this is of some help to others.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update:

 

Simply add a + in the makefile for parallel build:

+make -C makefiles/$(PROJECT_NAME) -f Makefile_$(CONFIG_NAME) all APP_NAME=$(APP_NAME)

 

Now compiling takes only 3s in the virtual machine using 4 cores.