Wisblock-API app_event_handler in an ISR?

WisBlock
#1

Hi, with the wisbock-api code. When the system jumps into the app_event_handler is this inside an ISR or not? I am having some issues pushing data into a FreeRTOS queue and was wondering if I should be using the method xQueueSendToBackFromISR instead?
Inside this app_event_handler when the STATUS is triggered every 10 secs, I then read from a SoftwareSerial buffer from GPS serial data and then process this and stuff it into the queue.

void app_event_handler(void)
{
// Timer triggered event
if ((g_task_event_type & STATUS) == STATUS)

#2

Hi Richard,

app_event_handler() is not called from an ISR. It is called from loop() after an event happened.

From where do you access the FreeRTOS queue? Is it from an additional task you created, from an ISR or from a timer callback?

#3

Thanks Bernd,
I’m having some really frustrating issues. Its probably my lack of knowledge.
All I want to do is read from a GPS module, using Software serial and pus that data into a queue, then in another thread, that handles the BG77 module, if there are GPS coords int eh queue, send them via MQTT.
However, I am havign all sorts of issues.
You helped me setup another thread using hte RAK5860 BG77 module. I have this working now, connecting and sending via MQTT. However, the response form the Serial1 is strange, sometimes it works great other times, the message is garbled. For example, when I send a an AT cmd:
AT+QMTPUBEX=0,1,1,1,“rtk/AR00001/GPS”,"{‘id’:1, 'Device… JSON truncated}"
And then wait for the success, sometimes it comes back great with +QMTPUB: 0,1,1,1 so then I can move on, other times, its missing characters. I can’t figure out why not.

And then, suddenly the app_event_handler dosnt get called anymore.
I’m really thinking about just ditching wisblock-API.

Question, does the RAK1910 GNSS module use a different serial uart to the RAK5860?
I was hoping to save a UART for future sattelite comms, but I will have to figure something else out.

#4

I’m using a software serial library that uses an interrupt for receiving. I’m not sending anything as I just read from a 9600 GPS, that is set to send 1 RMC NMEA string every 10 seconds.
I had the GPS stuff in a second GPS thread, but then everything was just garbled, Serial1 and the Software serial.

#5

The RAK1910 uses the same Serial lines that the RAK5860 does use. You cannot use both together.

The RAK5860 has GNSS as well, why do you need the RAK1910 in addition?

#6

I need to read the GPS, around every 10 sec. With BG77, you have to switch between them, and then it is another 30s to get a fix, plus around a minute after sending the data via MQTT.
I have the softwareserial working now well, getting the characters from within the app_event-handler. However, the Serial1 still misses characters when reading the response from the BG77, I’m trying to work out why. I need the response to know whether the packet was sent correctly or not.
I’m using the bg77-at commands within the app_event_handler aswell, to rule out the extra task.

BTW. I could use the dual IO board, as it has separate HW serial to the sensors. But I don’t want to as it is too large.

#7

I can only guess that (independent of using Software Serial) the RX and TX pins of the RAK1910 and RAK5860 are still physically connected together.

Maybe the RAK12500 GNSS module is a better solution here. You can use the I2C communication with the GNSS chip on the RAK12500 and use a slot (B or C) that doesn’t have the RX/TX pins.

#8

Yes, maybe, I didn’t know that the RAK12500 had I2c. will look into this.

I’m currently using a separate GPS module (NEO-7M) in my prototype, (https://www.jaycar.com.au/duinotech-gps-receiver-module-with-on-board-antenna/p/XC3710)
with the TX pin connected to I2C2_SCL (24) on the dual base board. Using this Software serial library for NRF: GitHub - micooke/SoftwareSerial: Software Serial library for the nRF5 core

But for the final version I would prefer something on the single base board like the RAK12500.

I have got the BG77 to work reliably now. (I just need to pause the interrupts coming from the software serial and it works great.) Good enough for a proof of concept anyway. I just need to align the sending of the data via MQTT, and turn the SS interrupts back on before I miss an incoming GPS string.

I may go back to using the BG77 in a separate task now that I have worked out what it was. It still perplexes me that the hardware serial is being affected by the software serial interrupts when I read it from the buffer?? :smile:

But I’m happy and can work around now that I know what it was.

Question? Is the reason that you don’t use both hw serials because the other CPU’s don’t have 2 hw serials? Otherwise why wouldn’t you use both. One for sensors and one for IO?

BTW. I have been looking for a “system” like the wisblock for ages. Now that I am getting familiar with it and have worked through the “frustrations” of the unknown - my lack of knowledge. I really like it.

And using Freertos with wisblock-API was a genius idea, because it gives you everything you need to build robust things.

#9

Hi Rich,

Glad you like WisBlock and got your problems (more or less) solved.

For the two HW serials, the development of WisBlock started before I joined RAKwireless, so I am not sure why the same UART is used for the IO slots and the Sensor slots, but it would be definitely better that way.

One thing you could try is to redirect Serial2 to the pins you use with an external GNSS module.

You could redefine the

#define PIN_SERIAL2_RX (19)
#define PIN_SERIAL2_TX (20)

in the file variant.h to the pins you want to use for the GNSS and then just use Serial2.begin to use HW serial instead of SoftwareSerial.
But that change would be reversed when you update the BSP.

#10

Oh ok, I didn’t know you could do that? I will definitely try that.

#11

That works great now! Using the hardware serial.