RAK online compiler for you to compile your customized firmware based on RUI

RUI
143

According to the instructions, the bin file you wrote should use RAL LoRaButton Upgrade Tool v1.0.exe Tool to burn, stm32 is used to burn BootLoader.
Get_Start_with_RAK5205_WisTrio

144

Hi, yes thank you. That was the issue.
I reloaded the boot loader and then used the upgrade tool to upload the bin file and that has worked.

145

Hi,
I am adding some code to read the ds18b20 temperature sensors via one wire and I have a few questions about the RUI API.

  1. What is the pin number that is referred to in the RUI_GPIO_ST structure? If I want to use PA8 for example, what would be the pin number I use?

  2. The 1-Wire protocol requires the direction of the pin to be changed. Do I need to call rui_gpio_uninit() before calling init again?
    For example, is the following code ok?
    RUI_GPIO_ST port;
    port.pin = 9; // Not sure on this number, see above
    port.dir = RUI_GPIO_PIN_DIR_OUTPUT;
    port.pull = RUI_GPIO_PIN_NOPULL;
    // Do I need to uninit before another call to init?
    rui_gpio_init(&port);
    // Set the output high
    uint8_t status = 1;
    rui_gpio_rw(RUI_IF_WRITE, &port, &status);
    // Set the port to input and read the status
    port.dir = RUI_GPIO_DIR_INPUT;
    rui_gpio_init(&port);
    rui_gpio_rw(RUI_IF_READ, &port, &status);
    // status will now be input status of port?

Is the above correct?

Thanks in advance

146

Hi,@John_NZ
1.About RUI_GPIO_ST structure,its member pin_num means RAK811 module pin number.PLS refer to RAK811 module schematic diagram.
FYI:https://downloads.rakwireless.com/en/LoRa/RAK811/Hardware_Specification/
2.

It can be directly initialized before use without the need for uninit .
In fact, before you use GPIO, you can configure the structure to read or write directly, without even initializing it.

typedef struct {
uint32_t pin_num;
RUI_GPIO_PIN_DIR_ST dir;
RUI_GPIO_PIN_PULL_ST pull;
} RUI_GPIO_ST;
port.pin_num not port.pin

147

Hi,

Thank you for the previous answers.
I am compiling for the 811_H and I am now getting a link error, that rui_delay_us is undefined.
The documentation says that rui_delay_us is supported for the 811, any ideas on why it is not linking?

CC	gpio.c
CC	delay.c
CC	timer.c
CC	fifo.c
CC	i2c.c
CC	adc.c
AS	startup_stm32l151xba.s
AS	cmb_fault.s

_build/onewire.o: In function onewireInit': /root/tmp_vdb/rak10057/RUI_V2.0-master/RUI/build/..//Source/stm/STML151/application/onewire.c:35: undefined reference to rui_delay_us’
etc

Thanks in advance.
John

148

Hi @John_NZ,

I’m sorry for that, and it seems that there is an issue in RUI API reference.
Actually, RAK811 can only support ms delay, so you can’t use “rui_delay_us” on RAK811 because it is used for us delay. Just use the following API on RAK811 for ms delay:
https://doc.rakwireless.com/developer-tools/developer-tools/rui-delay-milliseconds

149

Hi Fomi,

Thanks for the information. The ms delay is not useful in this situation as I need microsecond level delays. I will add a routine to approximate the delay to suit my needs.

Cheers,
John

150

Hi,

In the RAK811 and RAK5205 applications, I am receiving the message ‘[LoRa]: Unknown network error’ about every 20 seconds.
It could be something to do with my other units transmitting nearby, I don’t really know. But I am curious why the lora stack would be reporting the error.
The only place I can see this particular error message is in the McpsIndication_callback function in rw_lora.c (assuming I am looking at the correct module).
Any idea on what this message means?
If not, could the RUI API be changed to report the actual error number in the message?

Thanks
John

151

Hi,
It turns out the rui_gpio_xx functions have too much overhead and make them too slow to work with the 1-Wire protocol.
I changed to using the lower level gpio functions directly and have managed to get the 1-Wire protocol working with the DS18B20 temperature sensors.
Just mentioning this in case anyone else is trying to do something similar.

Cheers
John

152

Hi,@John_NZ
We are collating documents about “RUI” and “AT command” normalized return status and error encoding.It is expected to be finished this week,pls follow the official documentation soon.

153

We will add “us” delay API rui_delay_us on RAK811 as soon as possible.

154

HI,

It’s not the rui_delay_us function that is the issue, it is the rui_gpio_rw function that is slow.

I have been using the Gpio functions directly, for example, to set the pin to output and set it high, the following is fast enough for implementing the 1-Wire protocol, e.g.
GpioInit( &gpio_pin, RAK811_PIN5, PIN_OUTPUT, PIN_PUSH_PULL, PIN_NO_PULL, 1 );
GpioWrite( &gpio_pin, 0 );
GpioWrite( &gpio_pin, 1 );
GpioWrite( &gpio_pin, 0 );

But using the rui_gpio_rw(RUI_IF_WRITE, &port, &status); RUI equivalent function is too slow.

From what I can see of the RUI code, the issue is that the rui_gpio_rw function is initialising the port direction every time it is called. It would be better that this was only done by calling the rui_gpio_init(&port) function when it is required to actually change the port configuration.

For the uS timer, I am using the following software implementation on the RAK811, which is close enough.

static uint32_t loops_per_us = 39;
RUI_RETURN_STATUS rui_delay_us(uint32_t value)
{
uint32_t cnt = 0;
for(cnt = 0; cnt < (value * loops_per_us) >> 5; cnt++) {
asm(“NOP”);
asm(“NOP”);
asm(“NOP”);
}
}

Cheers,
John

155

yes,you are right. we have modify rui_gpio_rw(),and updated RUI code.you can try recompiling now.

156

Hi,

Are you presently working on the RUI code? I have started getting compiler errors in board.c

CC	board.c

…//Source/stm/STML151/board/board.c:45:1: error: unknown type name ‘RUI_UART_DEF’; did you mean ‘USART_DIV’?
RUI_UART_DEF uart_def;
^~~~~~~~~~~~
USART_DIV
…//Source/stm/STML151/board/board.c:514:29: error: unknown type name ‘RUI_UART_DEF’; did you mean ‘USART_DIV’?
void uart_data_recv_process(RUI_UART_DEF uart_def, uint8_t *pdata, uint16_t len)
^~~~~~~~~~~~
USART_DIV
…//Source/stm/STML151/board/board.c: In function ‘Parse_string_loop’:
…//Source/stm/STML151/board/board.c:554:35: error: ‘RUI_UART_NORAMAL’ undeclared (first use in this function); did you mean ‘PWR_MODE_NORMAL’?
if(g_lora_config.uart_mode == RUI_UART_NORAMAL) //Uart work at normal mode
^~~~~~~~~~~~~~~~
PWR_MODE_NORMAL
…//Source/stm/STML151/board/board.c:554:35: note: each undeclared identifier is reported only once for each function it appears in
…//Source/stm/STML151/board/board.c:592:33: error: ‘RUI_UART1’ undeclared (first use in this function); did you mean ‘GPS_UART’?
rui_uart_mode_config(RUI_UART1,RUI_UART_NORAMAL);
^~~~~~~~~
GPS_UART
stm/Makefile_stm32l151cb:246: recipe for target ‘_build/board.o’ failed
make: *** [_build/board.o] Error 1

Cheers
John

157

Hi,@John_NZ
RAK online compiler FYI:https://doc.rakwireless.com/rak811-wisnode-lora-module/firmware-customizing.
User compile online with customer APP ,need the header file rui.h to APP.

image
image894×63 4.96 KB

rui.h could download here:https://github.com/RAKWireless/Products_practice_based_on_RUI/blob/master/common%20header/rui.h

158

Thank you. The issue was that rui.h was in my folder, but had failed to copy any data and was 0 bytes.
I added it in again and that has resolved the issue.

159

great initiative RAK Wireless :+1::+1::+1:

160

Hi apply for online compiler please
oliver fang chen
[email protected]
RAK811 au915

161

Having a problem in the new sample code today RAK811, can’t link to loraWan anymore and no “at+set_config=device:boot” in the AT command?

162

Can you give me the screenshot of the problem you encountered? Is this command in normal use?