¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. QRPLabs
  2. Topics

A ¡°pluggable¡± firmware architecture?

 

I understand why and fully support the fact that QRP-Labs firmware is not open source.
?
This idea is for a capability to pick from a ¡°menu¡± of options enabling the user to tailor the firmware on their device.
?
For example; on every radio I own, I¡¯ve disabled the CW decode capability. It would be cool to be able to free the code space occupied by the decoder function to make room for some other, more compelling feature.
?
Maybe SSB pushes the firmware to the limit and you want remove FSK capability to make room.
?
et cetera.
?
This is NOT a feature request. I can think of a lot of reasons why this could be a bad idea.
?
  • Firmware ¡°versions¡± don¡¯t have a clear meaning anymore.
  • It could become a support nightmare. User: ?¡°Hey, my thing doesn¡¯t work!¡± Support: ¡°What combination of modules do you have in your firmware?¡±
  • Module X doesn¡¯t play nice with module Y.
  • Cost of re-architecting the firmware code base.
  • Cost of UI/infrastructure to put this into the hands of customers.
  • Opportunity cost.
Why even mention this if it¡¯s not a feature request and is such a bad idea? Even ¡°bad¡± ideas should be heard, maybe it helps ¡°good¡± ideas to be uncovered.
 

Hello Matthew

All ideas are indeed welcome, even bad ones ;-)?

I think your ideas are interesting?but, I think it is likely to be impractical?on a small scale system like QMX. The architecture?to be able to include or exclude or include functionality?modules is probably itself?too large an overhead to contemplate on such a small system, both in hardware, software and human terms (development and support).?

I think and hope?that a better way to proceed has been and will be, to keep the code efficient?and the processor future-proofed enough. Right now only about 1/3 to 1/2 the CPU and Flash memory is utilized; I hope and suspect that the resources of the processor will suffice to allow all planned future development in a single firmware version.?

73 Hans G0UPL

?

I understand why and fully support the fact that QRP-Labs firmware is not open source.
?
This idea is for a capability to pick from a ¡°menu¡± of options enabling the user to tailor the firmware on their device.
?
For example; on every radio I own, I¡¯ve disabled the CW decode capability. It would be cool to be able to free the code space occupied by the decoder function to make room for some other, more compelling feature.
?
Maybe SSB pushes the firmware to the limit and you want remove FSK capability to make room.
?
et cetera.
?
This is NOT a feature request. I can think of a lot of reasons why this could be a bad idea.
?
  • Firmware ¡°versions¡± don¡¯t have a clear meaning anymore.
  • It could become a support nightmare. User: ?¡°Hey, my thing doesn¡¯t work!¡± Support: ¡°What combination of modules do you have in your firmware?¡±
  • Module X doesn¡¯t play nice with module Y.
  • Cost of re-architecting the firmware code base.
  • Cost of UI/infrastructure to put this into the hands of customers.
  • Opportunity cost.
Why even mention this if it¡¯s not a feature request and is such a bad idea? Even ¡°bad¡± ideas should be heard, maybe it helps ¡°good¡± ideas to be uncovered.
 

Here's a related (potentially "bad", I don't think so) idea.
Will there be a way to build our own "native" functions that can be called from QPRLabs BASIC?
Specifically, could it be possible to write our own optimized functions in C or assembly for STM32 and "link" them with a BASIC program or register them from BASIC?
That would potentially enable us to add our custom signal processing blocks to your pipeline.
For example, if we have a noise suppression algorithm that we particularly like it might let us (with proper hooks provided by you) insert it into the audio pipeline.
If we screwed something up then, say, a firmware reset could remove the registered custom components, and restore to the default pipeline.
What do you think?
?
73, Mike KK7ER
?
 

Hello Mike

I think it's a nice idea but I don't know how to accomplish that in practice. What you're talking about is kind of the old PC "DLL" concept. Native code that has to be in a relocatable library. Not just that but there then has to be some way to load it onto the Flash - which can't be done in any way I know of, certainly not with the current bootloader. There are a lot of obstacles to that and again, I think the idea might not be easily transferable?to a small microcontroller system. The BASIC runs in a Virtual Machine not natively on the CPU. So how you bridge that gap, and how you construct microcontroller DLL's and how you get those into the Flash, those would be a lot of complex problems to solve.?

73 Hans G0UPL



On Mon, Sep 16, 2024 at 11:58?PM Mike KK7ER via <groupio=[email protected]> wrote:
Here's a related (potentially "bad", I don't think so) idea.
Will there be a way to build our own "native" functions that can be called from QPRLabs BASIC?
Specifically, could it be possible to write our own optimized functions in C or assembly for STM32 and "link" them with a BASIC program or register them from BASIC?
That would potentially enable us to add our custom signal processing blocks to your pipeline.
For example, if we have a noise suppression algorithm that we particularly like it might let us (with proper hooks provided by you) insert it into the audio pipeline.
If we screwed something up then, say, a firmware reset could remove the registered custom components, and restore to the default pipeline.
What do you think?
?
73, Mike KK7ER
?
 

DLL?? Perhaps. I was thinking more like JNI (Java Native Interface) in a Java VM.
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/intro.html
?
In my teens, I spent quite a few hours with the latest Commodore 64 magazine entering (literal) pages of assembly code one byte at a time (remember PEEK and POKE?? :)).
Checksums prevented most typos.
At the end, the payoff was getting to play some new game described in the magazine.
?
If we will be able to enter a BASIC program into the QMX over the serial terminal, it should be possible to store literal machine code along with the BASIC source code.
Just a thought, although I can appreciate how it might be beyond the scope of what you had planned.
?
73, Mike KK7ER
?
 

On Tue, Sep 17, 2024, at 16:46, Mike KK7ER wrote:
In my teens, I spent quite a few hours with the latest Commodore 64 magazine entering (literal) pages of assembly code one byte at a time (remember PEEK and POKE?? :)).
Checksums prevented most typos.
At the end, the payoff was getting to play some new game described in the magazine.

My first word processor came out of _Compute!_ magazine!
 

On Tue, Sep 17, 2024 at 09:54 AM, Michael - WD0OM wrote:
My first word processor came out of _Compute!_ magazine!
?
Ah, yes!? I may have gotten the name wrong.? It may actually have been Compute!'s Gazette.
?
73, Mike KK7ER
?
 

It was one of those, for me, yes. _Compute!_ was general, _Compute Gazette_ was specific to Commodore, as I recall, but both tended to have some code for Commodore at various times.

Either way, that word processor probably saved my academic career. My handwriting is atrocious; my typing at the time was also atrocious unless I could treat "backspace" like just another key, and my typewriter was manual, so that wasn't an option.

Once I convinced Luddite teachers to accept 8-pin dot matrix print in lieu of typewritten papers, things got much, much better...

On Tue, Sep 17, 2024, at 19:40, Mike KK7ER wrote:
On Tue, Sep 17, 2024 at 09:54 AM, Michael - WD0OM wrote:
My first word processor came out of _Compute!_ magazine!
?
Ah, yes!? I may have gotten the name wrong.? It may actually have been Compute!'s Gazette.
?
73, Mike KK7ER
?
 

Hi,

Just wanted to chime in. BASIC is how I learned programming too, but
there is another language which has become popular for both learners
and embedded systems.

If you're looking for a "glue" language, I'd recommend having a look
at Lua. Lua is lightweight, 150 Kbytes with all the standard
libraries, and is designed to be added easily to C applications. It's
a tiny language. A programmer can learn the language in a day. And
there are already resources for Lua on embedded devices. Also it's MIT
licensed, so it can be used freely.

Like BASIC it's an interpreted language, but it couples well with C.
I'm sure it would be possible to design an API which would allow rx/tx
of new digital modes with a small Lua program.

I learned Lua so I could teach my niece programming. She wanted to
learn Lua to make things in Roblox, but it's also used in many other
games and game engines, Wikipedia uses it for modules, and many
serious applications like Lightroom use it for scripting.

Just a thought.

Pengo VK3PGO


On Tue, Sep 17, 2024 at 6:58?AM Mike KK7ER via groups.io
<groupio@...> wrote:

Here's a related (potentially "bad", I don't think so) idea.
Will there be a way to build our own "native" functions that can be called from QPRLabs BASIC?
Specifically, could it be possible to write our own optimized functions in C or assembly for STM32 and "link" them with a BASIC program or register them from BASIC?
That would potentially enable us to add our custom signal processing blocks to your pipeline.
 

A very readable and thought provoking post, imo, Matthew.
?
It led me to wishful thinking re my QCXs - where I understand the firmware to have filled all bar a byte or two of the hardware.? It would be great (just a "dream" of course) to have some of what (for me) would be nice-to-haves instead of what (for me) are never used bells and whistles.? It also reminded me of those "will never be obsolete" PCs with enormous (hundreds of Megabytes!) memory and expansion slots "just in case".
?
I'm more than content of course with how things are.? And come SSB, (if indeed SSB do come), I do hope that Hans is able to continue innovating CW transceivers, in whatever form!
?
73 Rod G0VKX

1 - 10 of 10