Fortunately #FreeRTOS has a function to check whether we're in a #RISCV Interrupt Handler ... "xPortIsInsideInterrupt"

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/npl_os_freertos.c#L26-L34

NimBLE Porting Layer builds OK on #RISCV #BL602 #FreeRTOS yay! ... Let's call these Event Queue functions to process our received #LoRa Packets

https://lupyuen.github.io/pinetime-rust-mynewt/articles/dfu#nimble-event-queue-functions

#BL602 #FreeRTOS Multitasking made easier with NimBLE Porting Library ... Here's how we create an Event Queue ... And add an Event to the queue

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c#L238-L296

Now we handle Events from the Event Queue ... #BL602 #FreeRTOS Multitasking made easier with NimBLE Porting Library

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c#L238-L296

NimBLE Porting Library works great on #BL602 #FreeRTOS ... Multitasking made easier!

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c#L238-L296

Shall we teach #BL602 Multitasking with NimBLE Porting Layer? 1️⃣ Looks easier than FreeRTOS 2️⃣ It's portable to FreeRTOS, Mynewt, NuttX and RIOT OS 🤔

https://lupyuen.github.io/pinetime-rust-mynewt/articles/dfu#nimble-stack-for-bluetooth-le-on-pinetime

Let's use the Event Queue to forward the #LoRa Packet Received Interrupt ... From #BL602 Interrupt Handler ... To the #FreeRTOS Application Task

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276-board.c#L408-L441

#LoRa Packet goes from #WisBlock Transmitter ... To #BL602 SX1276 Interrupt Handler ... To #FreeRTOS Task yay! Now we read the received LoRa Packet from SX1276 over SPI

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c

Aha! #BL602 hits a #RISCV Exception ... When processing the received #LoRa Packet! Let's follow these steps to troubleshoot...

https://lupyuen.github.io/articles/i2c#appendix-how-to-troubleshoot-risc-v-exceptions

Our #BL602 Build, Flash and Run Firmware script generates the #RISCV Disassembly ... Let's track down the address of the RISC-V Exception

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/run.sh

Oops the Program Counter for our #RISCV Exception is null ... So there must be a missing Callback Function somewhere in our #LoRa #BL602 Firmware 🤔

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c

#BL602 #LoRa Exception happened because we passed a pointer to a stack object ... Which gets used by the Interrupt Handler 😲 ... This works OK in the original Mynewt code, but not for BL602

https://gist.github.com/lupyuen/1539f9dd52e9a83d4fbe7724481112bf

For #BL602 we fix this exception by copying the object ... Instead of storing a pointer to the object

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276.c#L357-L397

#BL602 now displays the #LoRa Packet received from #WisBlock yay!

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c

Mystery #BL602 GPIO Function ... What does it do? Will it fix our problem with triggering multiple GPIO Interrupts? 🤔

https://github.com/bouffalolab/bl_iot_sdk/blob/master/components/bl602/bl602_std/bl602_std/StdDriver/Src/bl602_glb.c#L2244-L2264

#BL602 Reference Manual mentions "GPIO_INT_CLR" but the address is undefined in the doc ... Methinks a chunk of addresses are missing from the doc 🤔

https://github.com/bouffalolab/bl_docs/tree/main/BL602_RM/en

Searching GitHub for "GPIO_INT_CLR" shows ultraembedded RISC-V SoC ... Coincidence? 🤔

https://github.com/search?l=Markdown&q=GPIO_INT_CLR&type=Code

Ah my folly ways ... Multiple #BL602 GPIO Interrupts can't be registered like this ... Lemme fix this 🪠

https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276-board.c#L336-L396

@lupyuen
Cc @mkljczk kopnal bys to do opensourceowych geekowych linkow etc?

@lupyuen
Interested in riscv. Please tell me more. Are You Chinese? Based in cm or us?

I need nickname for ya. Im bad bad with little worms for characters. No offence meant. Honestly.

Ill try to promote you around polish opensource geeky part of fedi if you want.

@PawelK Hi call me Lup (rhymes with "Up"), I'm just a geek in Singapore. Here's the story of my life 😉 ...

https://lupyuen.github.io/

I'm tied up with #RISCV #BL602 #LoRa projects right now ... Sorry I won't be able to help you much

@lupyuen
No worries. Thanks for intro im polish retired young. Based c/cpp. 15 years of exp. Mostly embeds. Some 4g and 5g infrastructure devel experience. Selftaught. IT is my life. Nerd. Pro opensource.

Riscv is the postarm. We need it badly.

@lupyuen
Also what could interest You Sir is llvm+clang seem to support riscv. They seem nicer fuller and more maintainable than gcc if that was of any help. Methinks #clangisthenewgcc

@lupyuen
Hmm lora nice nice.

@lupyuen
Are those two platforms using two different operating systems? Generally depends whether irq handler lives in same adress space as setup code. General guideline for portable code should be using either static data accessible from irq code or dynamically allocated data passable between two adress spaces.

@lupyuen
In case both oses are same or with same model of memory segments divide/sharing, seems like a bug to me.

@PawelK Yeah the code looks a bit suspicious ... Generally I would never save a pointer to a stack object. But this code has been in Apache Mynewt OS for a long time 🤔

@lupyuen
Ah ok clear now. Generally struct copy. Dont pass pointers. Unsafe.

@lupyuen
This code has assumption os shares adress space between irq segment and irq setup code.

Sorry for side comment. Deleted. Mistake.

@lupyuen
What puzzles me is fact mynewt is os in itself. Hmm weird.

@lupyuen
My reasoning is mynewt on both platforms should have constraints on segment duvide/sharing independent of platform. Thats puzzling.

@lupyuen
Lovely. Wish You much success. Interesting project and great platform. Whats the planned use for these little animals?

@PawelK Thanks :-) I'm planning to use this for IoT Education ... Teaching folks how to create a RISC-V LoRa Sensor that's battery powered...

https://lupyuen.github.io/articles/lora

https://lupyuen.github.io/articles/wisblock

@lupyuen
Nice nice. We coud use this in poland such a course. 5g is planned/starting rollout.

@lupyuen
Nice project. A hobby or commercial?

@lupyuen
If platforms are ready i might try to promote your platform here. It sounds interesting.

@lupyuen
Need to learn more on lora though for final decision.

Also in your example each process has separate stack while globals are in shared adress space. Interesting os. Feels similar to what i was doing for ericsson.

@lupyuen
Ahhh now i see. Lemme browse through their source. Old code is borked. Youre assigning to struct type a pointer type instead of RadioEvents = *events.

How come compiler let it compile...

@PawelK I changed my version to use struct instead of pointer to struct:

https://github.com/lupyuen/bl_iot_sdk/commit/5ca7946da1f795fd53aa7937ae87f3fbea2bce2a#diff-96c07c83d9cb748e9326fc2de5671debed63687a1fc984ff73cada89001a96fa

@lupyuen
If we got code:
Struct RadioEvents_t a.
Fun(struct RadioEvents_t* b)
{
a=b;
}

Compiler should give error.

@PawelK The original code is this:

static RadioEvents_t *RadioEvents;

See https://gist.github.com/lupyuen/1539f9dd52e9a83d4fbe7724481112bf

@lupyuen
Ahh ah. Ok its porting between oses and separate adress spacrs problem it seems. Another concern may be if struct shoukdnt be volatile but i dont know enough sbout code to tell.

@lupyuen
Ahhhh ok.

Yea segment sharing/divide between irq and irq setup.

@lupyuen
Yes your compiler is broken. How come can you struct = pointer without dereference? Hehe.

@lupyuen
Cc @syuilo keep link to this guy. It will matter later. Embeds will with emphasis on arm and later riscv.