WSNDemo.c in Lightweight Mesh

Go To Last Post
143 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a few questions about the demonstration code for Lightweight Mesh.
Here are two functions:
HAL_UartBytesReceived and
HAL_UartWriteByte.

I not quite sure about the purpose of these two function. I don't know the UART communication is used for RS232 or for the transceiver itself.

Thanks if anyone can gives me some hints

Last Edited: Fri. Oct 16, 2015 - 01:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UART is not used for transceiver at all. Those functions are used to receive and send application data over the UART, as it follows from their name.

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

alexru wrote:
UART is not used for transceiver at all. Those functions are used to receive and send application data over the UART, as it follows from their name.

It seems like the UART function is used for control the FIFO. Am I right ?

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

FIFO buffers are used for UART communications, yes. But they still have nothing to do with the radio.

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

alexru wrote:
FIFO buffers are used for UART communications, yes. But they still have nothing to do with the radio.

Thanks Alexru. By the way, I saw your video about the introduction of Lightweight Mesh. Are you the one who created the WSNDemo code for Lightweight Mesh?

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

I've created everything in LwMesh.

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

alexru wrote:
I've created everything in LwMesh.

The PDF file of "getting started" says the LwMesh SDK contains precompiled binary.

I searched the file entirely but found nothing related with precompiled binary.

Do you know where can I get these precompiled binary?

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

They were not included in the package because it is very easy to create your own. In version v1.1.0 information about precompiled binaries was removed.

Just open a project for your platform from the application you like in Atmel Studio 6 and build your own binaries.

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

alexru wrote:
They were not included in the package because it is very easy to create your own. In version v1.1.0 information about precompiled binaries was removed.

Just open a project for your platform from the application you like in Atmel Studio 6 and build your own binaries.

I think the default configuration for WSNDemo is coordinator type because the APP_ADDR is set to 0.

But when I connect my PC to the board and use WSNMonitor, noting displayed on the main panel. Does it mean I need to make further modifications in order to get my devices displayed on the WSNMonitor?

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

What board are you using? Have you checked Fuse settings?

It should just work if the hardware is set up correctly.

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

alexru wrote:
What board are you using? Have you checked Fuse settings?

It should just work if the hardware is set up correctly.

I'm using STK-600 + ATMEGA128RFA1, I change the fuse bit based on the documentation provided by the SDK

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

STK600 requires to connect UART port pins to the on-board level shifter. Did you do that?

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

alexru wrote:
STK600 requires to connect UART port pins to the on-board level shifter. Did you do that?

Yeah, I'm using RS232. Sorry, I thought the fuse bit setting between BitCloud and Lightweight Mesh should be identical. But they are different. I change the fuse bit setting based on LwMesh SDK, it worked.

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

The only [important] difference is CKDIV8 bit and in the latest release of LwMesh it is no longer important, stack clears this bit. Download the latest version.

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, I'm trying to use WSNMonitor to learn about LW Mesh. I have programmed the coordinator with the correct fuses (provided by the SDK) and running the WSNDemo app. However, when I click on connect (on WSNMonitor), with the correct COM selected (and also correct speed 38400), I get the message Can't Connect, and sometimes, even this message doesn't appear. Please, do you have any other idea of what is happening? Thank You :D

Renan Margon

Computer Engineer

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

Operating system? Hardware platform?

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 Alex. I am using my own hardware, that has an Atmega1281 and a AT86RF231, and the communication with the computer is made using Atmega8u2 connected to the Atmega1281 by UART. The computer recognizes the board as an Arduino Uno because it was made using the arduino schematics. My friend who developed the board hardware could read data through UART, using this board, so I guess the hardware is ok. I know that using the own hardware is not the ideal scenario, but it's for a university project. Thank you

Renan Margon

Computer Engineer

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

So it looks like WSNMonitor can't connect to the Xmega CDC. I have no idea how to solve this. It might be drivers that OS picked up for this device, or how Java interacts with those drivers.

Try to open this port in a terminal and see if you get any output that way.

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

Yes, I tried to do this, but I got nothing. I don't know how WSNMonitor works, but I have to find a way to read the data using the UART. I will keep working on that, thanks Alex

Renan Margon

Computer Engineer

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

If you get nothing in the terminal, are you even sure that code in Xmega works correctly?

Before running WSNMonitor, make sure that you get something on a simple terminal.

A few things to check on the mega side:
1. HAL_UART_CHANNEL is set to a correct value.
2. Fuses are set correctly.
3. MCU and radio are connected correctly.

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

Yes, sorry for delat to answer, I was travelling. HAL_UART_CHANNEL was wrong but I fixed it before posting here. Fuses I have setted accordingly to the guide of LWMESH:
Extended: FE
High: 9D
Low: C2
And about the connection between the mcu and the radio, I found the code to read a register from the radio (PART_NUM) and I have done (if value==3) where value is the value read from the register, the led is on. So.. the led went on.. so I think the connection is okay.. but it's still not working with WSNMonitor..

Thanks

Renan Margon

Computer Engineer

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

Try to open corresponding COM port in the terminal first and see if you receive anything, then move on to WSNMonitor.

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

Yes.. I will do that.. if I have success I will let you know.. Thanks Alex

Renan Margon

Computer Engineer

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

Alex, should WSNDemo application output anything to the UART after the MCU is reset or does it wait for an initial request from WSNMonitor?

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

I could estabilish a connection with port COM3, but nothing appears on screen.. :(

Renan Margon

Computer Engineer

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

Alex, what should I get on the terminal when I connect to the COM port? what kind of information ? Thanks

Renan Margon

Computer Engineer

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

Usually it s a bunch of garbage characters, but if baudrate is set correctly, among those characters you will see a device name, for example "Coordinator" or "Router".

If you have only one device, then you will only see "Coordinator".

The good sign would be to see anything in a first place.

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

Yes, for the first test i'm trying to see anything.. but it's not working.. I will try to solve this problem. Anyway, let me ask you something. I'm trying to study the code, but I ha ve seen this part:

#if defined(PLATFORM_RCB231)
DDRC = (1 << 4) | (1 << 6) | (1 << 7);
PORTC = (0 << 4) | (1 << 6) | (1 << 7);
#endif

why you configure those bits on port C ? I'm asking because I think maybe it can be important since I'm using a different hardware.

Thank you :D

Renan Margon

Computer Engineer

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

This is for RCB board with RCB_BB extension boards. RCB_BB uses MAX232-like level shifter that has its pins connected to the MCU, so MCU needs to enable level shifter before use.

It is not likely that it affects you. RCB+RCB_BB is the only combination that I've seen that uses this method.

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

Humm.. So.. maybe I can comment this lines of code.
Thank you Alex, this LWMESH is a really good job, I'm impressed as long as I go studying the code haha I wish I could do something like that some day.

Renan Margon

Computer Engineer

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

Alex, I tried to find a code to test only the Uart communication of my board. It worked.. I could write something and then see the echo in the terminal.. but when I use the WSNdemo code I don`t get anything on the HyperTerminal.. maybe I have to change something in the UART configuration of this code.. I will try :D

Renan Margon

Computer Engineer

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

Are you sure it is an echo from the device and not a local echo from the terminal?

Can you post your test code?

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

No, I`m not sure, but I think it is right. I just used the source code from this article: http://www.appelsiini.net/2011/s...

Renan Margon

Computer Engineer

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

The only change that I have done is change F_CPU to 8 instead of 16

Renan Margon

Computer Engineer

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

You should start from setting HAL_UART_CHANNEL to 0 (default is 1).

Also note baudrate difference (38400 vs. 9600).

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

Yes, I did this change (HAL_UART_CHANNEL 0) in the config.h file .
About the baud rate, if I put 9600 on WSNDemo code it will generate a problem, no ? On hyper terminal, a connected using 38400 when running WSNDemo.. I will try one more time. Thanks a lot Alex

Renan Margon

Computer Engineer

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

Alex.. one little thing.. where is defined the value of F_CPU in the code? I searched the information but I couldn't find.. Thanks

Renan Margon

Computer Engineer

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

It is defined in the project settings or in the Makefile, depending on what system you are using to build the application.

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

I am using Atmel Studio 6.1 on windows 7. Do you think I have to use the option "Use external makefile" when compiling the code?

Renan Margon

Computer Engineer

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

No, just look in the existing project settings. There will be a section with compiler definitions.

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. About that problem on UART, I'm running the code with debbuger, step by step, and the code is getting stucked on this part:

void HAL_TimerDelay(uint16_t us)
{
PRAGMA(diag_suppress=Pa082);

OCR4B = TCNT4 + us;
if (OCR4B > OCR4A)
OCR4B -= OCR4A;

halTimerDelayInt = 0;
TIMSK4 |= (1 << OCIE4B);
while (0 == halTimerDelayInt);
TIMSK4 &= ~(1 << OCIE4B);

PRAGMA(diag_default=Pa082);
}
the application does not exit from that while condition.. it seems it stays forever in that condition. So I think that is the reason why WSNMonitor does not recognize the board.. because the code is not running to the end.. or, maybe I'm wrong.. I don't know very much about this

Renan Margon

Computer Engineer

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

Try a newer version of the stack. I don't know any specific reason why this code won't work for you, but the new one is different and it might just solve the problem.

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, I promise I will try to stop bothering here :) but I'm kind of running out of time. I'm using version LwMesh_1_1_1 . I will try to use a newer version though, if this one is not the newer. I'm trying to understand the code.. some parts I don't understand. For example, I'm reconfigured de LED0 Port.. to fit on my pins.. so LED0 is conected on Port A2 on my mcu, I did:

#if defined(PLATFORM_RCB231)
HAL_GPIO_PIN(LED0, A, 2);

but the led is not turning on (the led is working, I have tested with another simples code). So when I checked the LedOn method:

INLINE void HAL_LedOn(uint8_t i)
{
if (0 == i)
HAL_GPIO_LED0_clr();

.. and this method erases the bit, not activate. Maybe I'm understanding it wrong because I'm a begginer.. Thanks

Renan Margon

Computer Engineer

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

Ahh! now I see that version 1.2 has been launched.. I will take a look on it! Thanks

Renan Margon

Computer Engineer

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

renanmrg wrote:
I'm using version LwMesh_1_1_1.
The most recent one is v1.2.0.

renanmrg wrote:
.. and this method erases the bit, not activate. Maybe I'm understanding it wrong because I'm a begginer..
And that is why this code is located in a board-specific part. On RCB boards LED's anode is connected to +3.3v and cathode is connected to the MCU. So control is high for LED OFF and low for LED ON.

If your board uses different LED connection, then you will also have to change '_clr' to '_set' and vise versa.

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

Oh.. I didn't think about it.. you are totally right! I will do this.. Thanks, and sorry for bothering too much :D

Renan Margon

Computer Engineer

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

Omg!! The UART now is working!! I can see Coordinator written on hyper terminal, and also the led is working too with the change clr to set!! I can't believe it! haha Thanks Alex :D

Renan Margon

Computer Engineer

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

Now the coordinator appears on screen. I configured one board with Adress 0x0001, so is a router. It appears on screen too, and a gray line between the router and the coordinator is shown, it works fine. But I configured another board as router too, adress 0x0002, it appears on screen, but no gray line and after about 20 seconds it disappears, but the led indicating that the board is connected keeps on, without blinking... do you have any idea why this second router is disappearing ? Thanks

Renan Margon

Computer Engineer

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

renanmrg wrote:
do you have any idea why this second router is disappearing ?

Run that second router under the debugger. and see what it is doing.

The gray line will only appear on the second report, so it does not look like that second report is happening. Device sends one frame and then just hangs.

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

Humm ok.. I will try this. but I'm almost sure it's a hardware problem, soldering this small components at home is really dificult.. I will also try to check the solder.. Thanks :D

Renan Margon

Computer Engineer

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

On the previous version of the stack, I would have assumed hardware problem instantly. This behavior is indication of the interrupt malfunction. On the new stack interrupt line is not used, so it is harder to blame the hardware. But it still might be something like power supply problem.

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

Pages