My Site

ReMapper/devlog_03

ReMapper DevLog

September 1, 2025

Unfortunately, due to travel and schoolwork, I haven't had much time to work on ReMapper with the focus it deserves. I was able to get some work done, but not as much as I hoped.

The main thing accomplished this week was that ReMapper is now hosting a website and DNS server. The content of the site is embedded within the ELF and hosted. This was a real struggle to get working since the ESP-IDF EMBED_FILES directive didn't work as I expected for subdirectories. For anyone attempting to do this, it worked when I figured out that no matter the folder structure, the embedded symbols are inserted as _binary_filename_ext, as opposed to _binary_subdirname_filename_ext.

Kinks with the web hosting

There are still some kinks to sort out with the web hosting. The goal is to attempt to make a real "captive portal," though I might backtrack on this as I've never been a fan of the captive portal user experience myself. As far as I understand, this just means setting up proper endpoints for the variety of platforms out there, and they will do the heavy lifting.

There's also the issue with connecting on Android phones. I found that my phone just shows the network as "no internet connection" and then attempts to connect to another network altogether. I'm not sure how to tackle that just yet.

For the final iteration of the device, I'd like the access point and website to only come up in a "program" mode, and in general use, there should be no need to open up the site.

Big ticket items

The intention behind the hosted website is to create a frontend where the user can create/edit a few programs that would map a certain type of USB input to another. I wanted the user to be able to make a kind of nodal diagram with logical blocks such as "if key is x" and "produce joystick output," etc.

The big issue here is how to describe this diagram, and how to transform the description from a nodal diagram to something workable on the embedded side. I still need to think on this topic some more before going ahead and coding something out, but I'll make a first draft of an implementation the goal for this coming week.

My first thought is to store all the node info in a somewhat fluid JSON structure and ship it as-is via endpoint to the embedded side. The embedded device should hopefully be able to store the described tree within the extra QSPI memory added to the board.

During non-programming runtime, the ESP32 would parse a chosen tree from the QSPI, validate the JSON, build out the described nodal tree, and then run it. I think the details of the implementation would iron out over time.

The more I think about this, the less I like the access-point and web server idea. It feels like added complexity, and if programs are just JSON data, they could be created on a separate, more complete platform, downloaded, and loaded onto the QSPI either via a Chrome tab (like the Opulo feeders, for example), or by exposing a small filesystem in programmer mode, similar to what the RP2040 does.

Relevant links