https://www.fcc.gov/media/radio/low-power-radio-general-information

Unlicensed operation on the AM and FM radio broadcast bands is permitted for some extremely low powered devices covered under Part 15 of the FCC's rules. On FM frequencies, these devices are limited to an effective service range of approximately 200 feet (61 meters). See 47 CFR (Code of Federal Regulations) Section 15.239, and the July 24, 1991 Public Notice (still in effect). On the AM broadcast band, these devices are limited to an effective service range of approximately 200 feet (61 meters). See 47 CFR Sections 15.207, 15.209, 15.219, and 15.221. These devices must accept any interference caused by any other operation, which may further limit the effective service range.

Crazy but simple idea

Lua controlled am radio tracker

Track songs with lua. Something like moonforge.

Transmits ONLY via a AM radio.

No DAC.

@AnalogWeapon
Another kind of easy example might be to take a few different capacitive touch sensors and do the same thing.

IMO doing this for buttons doesnt seem super valuable to me since as far as I know almost all buttons have the exact same outputs. There really is nothing to abstract there is there?

I think pots are a really good example since they have different curves and ranges but in theory could be abstracted to always output a linear value between 0 and 1.

By always doing exactly that, we can write code that takes that and creates its own curves and other behaviours and never need to worry about the specifics of the pot it gets the data from. The same code could work the same way on two completely different pots.

Proof of concept would really just be taking two totally different pots, run them against the exact same "high level" code and see that the code results in the same exact outputs.

I started typing up a thing about modularizing our code with abstraction layers but realized it might derail this thread. So I made a new topic, Still relevant to this but it should be its own discussion.

https://forum.magpiestuff.com/topic/45/abstraction-layers

Note: This is not a project idea but I wasnt sure where else to put it and just wanted to get it down,

---

It seems to me that our conversations keep coming back to wanting / needing some kind of abstraction layer.

All of these libraries are kinda bad IMO. Even Adafruit ones are always make me say "WTF" at least once every time I use one,

Since we are wanting to support all different kinds of HW but we also want to keep our "business logic" as portable and modular as possible I think abstraction layers make sense.

So in practice, that means we would come up with our own HW agnostic display API. One that can theoretically do anything we need but doesnt directly talk to any HW,

Whenever we write display code we will write it to the spec of our own API instead of the specific HW.

Then we will make HW abstractions for each device we want to use. Which translates our custom API calls to the device specific code as needed,

It is obviously slightly more upfront work for each new display driver we want to support but I think its the only realistic way to actually reuse code across even slightly different driver,

Are we at the point yet where we could come up with a "Breadboard BOM"?

@AnalogWeapon said in Picolua MVP:

If we set up an ADC for audio and it doesn't sound good,

Yeah IDK what I'm talking about because I dont even understand the potential issue here. In my mind ADC is just ADC and it sounds like whatever bit depth the ADC has.

FWIW while I dont have the HW side down I should have enough DSP experience to pin down why it doesnt sound good just by looking at the incoming sample buffer, Could be full of shit here though idk.

Either way, I trust your judgement. So if you are saying that an ADC isnt MVP material then I can accept that.

BUT a lua powered FX pedal would be dope AF for sure.

@AnalogWeapon said in Picolua MVP:

Having audio input adds about the same amount of complexity as the M2M, I think

What makes you say this? In my mind its just:

ADC -> sample buffer in -> logic -> sample buffer out -> DAC

I'm probably overlooking something. But what lol?

A simple synth engine would be pretty easy. We could do that with a pico and a breadboard. No other hardware needed.

I think a somewhat critical aspect here is having some kind of physical input layer since we need to make sure we have a clear way to handle stuff like that. I think we did a simple synth it would at least need a knob or something.

I'm totally down with just making this a PWM / Breadboard thing though.

Overview

I think we need an MVP project for picolua. Totally possible to make it with with M2M and I think we should still do that but I just don't understand enough about that project yet and I don't have enough confidence in picolua yet either.

So what does that project look like? No matter what it is, it wont be super trivial. So it needs to be something actually worth doing. At the same time it needs to be as trivial as possible so we can just get it done and learn what we need to learn from it. Maybe it's a thing that gets released or maybe it just a cool thing we make for ourselves. But it does need to be a proper thing.

Questions in need of an answer

It needs to answer these questions:

• What does a finished project using picolua look like?
• How do users actually load / debug their code?
  • We can really build out the whole load / debug system in a generic way here
• Are there obvious limitations to picolua we're not seeing yet?
• Do we really need to use LuaJIT here?
• How can picolua be improved to make this easier in the future?
• Whatever else we might learn

MVP

So I think maybe an MVP might look like this:

• Super basic synth
• Programmable with Lua by end users
• Some kind of input method (RR1 buttons, ribbon strip etc)
• Some kind of visual output (LEDs, screen etc)
• Audio output
• IDK about midi even

Another idea that is possibly cooler:

• Generic FX Pedal
• Programmable with Lua by end users
• Some kind of knob or something (maybe 2)
• Audio IO

@AnalogWeapon
Also plz feel free to make PRs to the picolua project if this is the kind of thing you want to try tackling. We can move it over to the magpie github at some point. I just wasnt sure if it was even going to work when I started it.

@AnalogWeapon
Yeah thats really good thinking.

I was aware of this problem but kinda just have been ignoring it. Technically only a problem if it actually happens lol. I mean if you think about it this is really also try for desktop Lua but there you usually have plenty of ram.

Anyway, I do think that handling the Lua memory allocation differently in this context makes a lot of sense.

As a rough proof on concept I think it should just kill the lua script without crashing the main program. If that's not what already happens.

I think ideally there would be some way or warning the user:

• Before the file is even sent to the device. (This isnt foolproof but we can at least make an attempt at this point)
• Before they actually run out of memory

This is getting very theoretical but we might even be able to do some static analysis on the Lua files. Kinda hard to say how much memory a given program might use when it is dynamically allocating. But in this case we actually have 100% control over all runtime "inputs". Meaning the user cant really do anything in the script that isnt evident just by reading the script. Whereas with a desktop Lua script the user could ask for input and get a number like 9 billion. In our case we can know and control the minimum and maximum ranges of all inputs. So we maybe can actually take a pretty good guess about how much memory a given script might use before it even runs.

Working exmaple:
https://github.com/matdombrock/pico-lua/blob/main/get_lua.sh

Compile Lua for pico

• Cross compile for pico
• Ensure that all unneeded libs are removed
  • I think all we really need is math

Example Lua code

#include <stdio.h>
#include "pico/stdlib.h"
#include "lua.h"
#include "lauxlib.h"
#include "lualib.h"

void run_lua_script() {
    lua_State *L = luaL_newstate();  // Create a new Lua state
    luaL_openlibs(L);               // Open Lua standard libraries

    // Lua script as a string
    const char *lua_script = "print('Hello from Lua on Pico!')";

    // Execute the Lua script
    if (luaL_dostring(L, lua_script)) {
        printf("Error: %s\n", lua_tostring(L, -1));
    }

    lua_close(L);  // Close the Lua state
}

int main() {
    stdio_init_all();
    printf("Starting Lua on Raspberry Pi Pico...\n");

    run_lua_script();

    while (true) {
        // Keep the program running
        sleep_ms(1000);
    }

    return 0;
}

Potential CMake example

cmake_minimum_required(VERSION 3.13)
include(pico_sdk_import.cmake)

project(lua_pico_project)

pico_sdk_init()

add_executable(lua_pico
    main.c
    lua.c       # Add all Lua source files here
    lapi.c
    lcode.c
    ldebug.c
    ldo.c
    ldump.c
    lfunc.c
    lgc.c
    llex.c
    lmem.c
    lobject.c
    lopcodes.c
    lparser.c
    lstate.c
    lstring.c
    ltable.c
    ltm.c
    lundump.c
    lvm.c
    lzio.c
    lauxlib.c
    lbaselib.c
    lbitlib.c
    lcorolib.c
    ldblib.c
    liolib.c
    lmathlib.c
    loslib.c
    lstrlib.c
    ltablib.c
    lutf8lib.c
    loadlib.c
    linit.c
)

target_link_libraries(lua_pico pico_stdlib)

pico_add_extra_outputs(lua_pico)

This is a pretty good teardown of the Roland Aerophone
https://www.barbaro.it/blog/the-digital-blower-5/post/aerophone-ae-30-pro-internals-330