Simple fix for a PlatformIO build error in #WisBlock's LoRaP2P_TX sample ... My first Pull Request for WisBlock!
#BL602 GPIO Interrupt ... According to the BL602 Reference Manual 🤔
https://github.com/bouffalolab/bl_docs/tree/main/BL602_RM/en
Maybe #BL602 High Level Trigger Interrupt = High Priority Interrupt = Sync Interrupt? 🤔 ... Lemme check the original Chinese Reference Manual
https://github.com/bouffalolab/bl_docs/tree/main/BL602_RM/en
My bad ... #BL602 High Level Trigger Interrupt = 高电平触发中断 = Trigger Interrupt on Logic High ... Nothing to do with priority 🤔
https://github.com/bouffalolab/bl_docs/tree/main/BL602_RM/zh_CN
Flashed the #LoRa Transmitter to @RAKwireless #WisBlock ... This Arduino program transmits "Hello" in a LoRa Packet every 5 seconds
https://github.com/lupyuen/wisblock-lora-transmitter/blob/main/src/main.cpp#L94-L128
When #WisBlock transmits #LoRa Packets ... Our #BL602 LoRa Receiver hangs! ... Let's find out why 🤔
https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c
Something spooky about #BL602 GPIO Interrupts 🤔 ... Let's disconnect #LoRa SX1276 pins DIO1 to DIO3 ... And connect DIO0 to my fav Blue LED (GPIO 11)
https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora
#PineCone #BL602 Blue LED switches off ... When #WisBlock transmits a #LoRa Packet ... So DIO0 Packet Received works! Why does the GPIO Interrupt hang? 🤔
https://github.com/lupyuen/bl_iot_sdk/tree/lorarecv/customer_app/sdk_app_lora
#BL602 GPIO Interrupt triggered OK when #LoRa Packet received yay! ... But why does it work now? 🤔
https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/demo.c
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
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 🤔
#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
#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? 🤔
#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 🪠
Let's handle #BL602 GPIO Interrupts the smarter way ... By iterating thru the Interrupt Events created with the NimBLE Porting Layer
Reconnected #PineCone #BL602 @PINE64 ... To #LoRa SX1276 pins DIO0 to DIO3 ... For testing our GPIO interrupt handler
https://github.com/lupyuen/bl_iot_sdk/blob/lorarecv/customer_app/sdk_app_lora/sdk_app_lora/sx1276.h
@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.
@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...
@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:
@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
You know when volatie is useful for sure, right?
@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.
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