Blog - All Comments

RE: MSPM0 project with VS Code, CMake and GCC - part 1: infrastructure

Jan Cumps — Mon, 31 Aug 2026 20:55:12 GMT

All works. It can build firmware (also .hex file compatible with [mention:b0bc65b9ecdc4307bd967592f00e340a:e9ed411860ed4f2ba0265705b8793d05] ' bootloader).

And the debugger works from within VS Code [emoticon:ffdd7b0ed07d454ba259894f328bbdc6] :

RE: Modder Upgrades PlayStation One Console by Expanding Its Memory Capacity

Shishir — Thu, 27 Aug 2026 06:26:13 GMT

Really interesting project. I had some modding experience with PS2. Seeing the devs still doing wonders with PS1 and PS2 really makes me feel happy and nostalgic. Most recent achievement I would like to mention is that OpenGoal team successfully reverse engineered the Jak and Daxter Trilogy games, which used a custom dialect of Lisp called Game Oriented Assembly Lisp. Originally made PS2 exclusive, now it can run on pc natively. It almost feels like dream coming true. All thanks to the amazing modders and open source devs who contribute their free time in these projects.

RE: Creating a Mobile App with Flutter: Interfacing Microcontrollers with AnyOperate!

shabaz — Wed, 26 Aug 2026 00:34:18 GMT

Made some improvements in v0.3.0 of AnyOperate.

Now it works properly with CH340 series USB UART ICs. Previously, there was a bug in a serial port library and would pick the incorrect baud rate (19200 instead of 115200). That is corrected now. Also, now *DTR is deasserted if using CH340 (this is useful if the *DTR line is used for other purposes). Finally, the config screen had a minor cosmetic bug fixed.

The screenshot below shows lots of config params for an MSPM0 target. I'm finding the app quite useful, I'm considering buying a small cheap Android phone to use exclusively for running it.

RE: Creating a Mobile App with Flutter: Interfacing Microcontrollers with AnyOperate!

shabaz — Wed, 19 Aug 2026 13:40:30 GMT

I've published AnyOperate release v0.2.0, which allows for WiFi setup from AnyOperate.

Also, there is a fuller Pi Pico W demo, which should be usable for custom projects. This also contains the ability to store parameters (or any variables) to Flash, using a 16-bit identifier. For example:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:df125581-ccbc-4e63-ab80-cc759d3f424c:type=c_cpp&text=%20%20%20%20PersistentStatus%20result%3B%0D%0A%20%20%20%20%0D%0A%20%20%20%20uint16_t%20dutyCycleStorageIdentifier%20%3D%200x1001%3B%0D%0A%20%20%20%20int16_t%20dutyCycle%20%3D%2050%3B%0D%0A%20%20%20%20%0D%0A%20%20%20%20PersistentStore%3A%3AwriteInt16%28%0D%0A%20%20%20%20%20%20%20%20dutyCycleStorageIdentifier%2C%0D%0A%20%20%20%20%20%20%20%20dutyCycle%0D%0A%20%20%20%20%29%3B%0D%0A%20%20%20%20]

And then it can be retrieved using that identifier.

I'm not going to make any more changes to these apps for a while, since I think they are at a reasonably usable state. Next step is to work on an actual end project, which can hopefully use the Pico W demo code, and the AnyOperate app.

The screenshot below shows the demo app CLI, which is accessible on a PC via USB Serial console or Telnet (using WiFi), but having to interact with the CLI is not necessary of course, since AnyOperate can be used via USB or BLE. The CLI does have some functionality not currently accessible via AnyOperate (such as reboot and factory settings).

RE: Creating a Mobile App with Flutter: Interfacing Microcontrollers with AnyOperate!

shabaz — Tue, 18 Aug 2026 19:25:56 GMT

I'm not too happy that I'm using insecure Telnet, but I'll run with it for now, and maybe remove that transport later. Anyway, as mentioned it is very convenient for debugging right now.

I was more interested in how to set up the WiFi configuration. Now it's easy, from AnyOperate (I still need to tidy this up before I commit these new changes to GitHub - I also need to think about an AP mode, in case there is no WiFi access point for the Pico to connect to).

For now, when using USB or BLE, a WiFi Settings box appears; this was added to the DeviceMenuScreen which was a class discussed in the blog, which previously only gave Config and Status options.

If WiFi settings is clicked, a new WifiSettingsConfigScreen is inserted in the stack of screens:

RE: Creating a Mobile App with Flutter: Interfacing Microcontrollers with AnyOperate!

shabaz — Tue, 18 Aug 2026 06:29:42 GMT

A benefit of using the simple ASCII based protocol; it is very easy to debug.

I've been busy adding WiFi capability (still a work-in progress). Since I don't have the Flutter app ready for that yet, I can just use Telnet from a PC to the Pico W, and type the protocol request commands manually. The USB transport can be tested in a similar way of course. All three transports (USB, BLE, WiFi) carry the same ASCII based protocol. Once I'm reasonably confident that the microcontroller end is functioning, I can switch to coding and testing with the Flutter app.

RE: Creating a Mobile App with Flutter: First Steps!

shabaz — Sat, 15 Aug 2026 02:31:25 GMT

I let AI give BLE a shot, and it seems to work nicely (I used ChatGPT).

For this app, each "screen" has its own .dart file, so, for instance, the screen that allows selection of USB or Bluetooth, happens to be called transport_selection_screen.dart, and, in a similar vein as the default demo app code description in the blog, that dart file contains two classes, one which inherits (extends) StatefulWidget, and the other which inherits State.

There's also something called a Route, which takes a screen class as a parameter. It's explained further below.

When (say) a user taps on the Bluetooth button on that first screen, a registered callback function executes (this is again just like in the blog as part of the demo app explanation), and that function contains Navigator.of(context).push( which searches upward in the Widget tree for the nearest Navigator object. That Navigator object maintains a "stack" of screens (actually a stack of Routes), and inserts (pushes) the next Route to display, which happens to be in a file called ble_device_list_screen.dart in my case. The reason that Routes are pushed and not just the StatefulWidget (or StatelessWidget) inheriting class, is because the Route can allow things like transitions, transparency, and so on to occur as part of the app.

I decided to use a custom underlying protocol (probably not a great idea! but I'm running with it for now until it inevitably comes back to bite me) for the data transfer between the app and the microcontroller. I'm using a Pi Pico W for now, but it shouldn't be hard to replicate to ESP32 for instance, and use the same app.

The custom protocol sends a stream of ASCII, with each command beginning with "$" and ending with '\n'. In BLE terms, the app writes to a particular characteristic, and expect a response to arrive as notifications for another characteristic. The reason for this, is that it is easy to swap out BLE for USB, and instead of using a command characteristic and a response characteristic, that gets replaced with serial writes and received bytes from incoming events. The reason for sticking with ASCII and '$' and '\n' was so that if the app isn't usable, one can always just use a serial console, and type the commands and hit return for them to execute. If the '$' is not typed first, then the microcontroller can echo back characters on the USB serial.

It can take a very long time for a clean build to execute. I'm using a fairly recent but typical consumer-grade laptop, with a reasonable amount of RAM. I think for developing such apps regularly, one would benefit a lot from a more powerful PC, perhaps a desktop one with a really good processor.

RE: EasyL1105: A Dev Board for the TI ARM Cortex-M0+ L-Series

shabaz — Fri, 14 Aug 2026 19:31:27 GMT

A friend requires a radio transmitter that triggers when a speaker sounds, so he can be alerted from a few hundred meters away, beyond audible range of the speaker. I do not have access to the speaker to measure it, and he doesn't have access to a multimeter or oscilloscope, and we are a hundred miles apart.

I decided to implement a possible solution in a way that can be configured to an extent by himself (he is only semi-technical), hence this would be a good job for a small microcontroller.

A self-imposed requirement for me was to make it easy to update the firmware and configure the setup, so he doesn't get stuck.
I'm using the MSPM0L1106 I still need to wait for some components, and I still need to begin the software.

For the microcontroller portion, I'm using the following schematic, which uses the "auto-bootloader" idea mentioned earlier. If it works (it may not, this has still not been tested), then the user doesn't need to press any buttons or insert any jumpers, to either upgrade the firmware, or to access the built-in menu (either directly or via an app that does not exist yet either).

This is the high-level block diagram, I'm using CC1101 (EByte E07 module as discussed in the comments here) for the radio since I'm using that for another project anyway. The drivers block just contains a MOSFET output for future use.

The Sensing block has two inputs, so the user has some flexibility in case the speaker isn't detected well.

This is the sensing block; the DC level PEAK_OUT signal goes to an ADC input on the microcontroller. Whenever an AC signal is present on TONE_IN, I'm hoping the change in output DC voltage can be easily measured by the MSPM0. If that doesn't work, then there is a digital input too, which can cope with some overvoltage, because I don't know what voltage his system operates at.

The choice of input, and the threshold for triggering based off the ADC input, can be configurable in software.

Low power is a requirement, but I don't think it needs to be ultra-low power. If it becomes a concern, at least the board can monitor the input voltage (I wired the microcontroller ADC A3 input to a potential divider connected to the source supply) and transmit it.

For the receiving end, I'll either use an identical board (minus the sensing circuitry), or a Pi Pico, since I already have a board with the CC1101 module for that.

RE: Creating a Mobile App with Flutter: First Steps!

BigG — Fri, 14 Aug 2026 12:53:16 GMT

I haven't done mobile/cellular app development in years, so this is nice reminder. We forget that our phones are jam packed full of sensors, e.g. accelerometers, proximity, light sensors etc. This, in my opinion, is where Flutter hits the sweet spot compared to the simpler but harder to scale low-code MIT App Inventor.

But both MIT App Inventor and Flutter have been around for a good few years now. I just did a quick search online and surprise surprise... There is a new kid on the block. May be worth a look at this too: https://capacitorjs.com/

Then there is also Kotlin. I think this is an alternative to Android, but I may be mistaken.

kotlinlang.org/.../

RE: Creating a Mobile App with Flutter: First Steps!

embeddedguy — Fri, 14 Aug 2026 03:48:35 GMT

I would just say All the best.

I have worked with Android Studio and Flutter as well for creating simple BLE application. But coming from embedded C/C++ background it is hard for me to understand other programming language and the environments. Moreover, Android studio is very large and makes the PC slow.

The BLE API was also hard to work with. Finally, I have gave up.!

RE: Creating a Mobile App with Flutter: First Steps!

DAB — Thu, 13 Aug 2026 20:05:12 GMT

Very interesting tool.

RE: Modder Upgrades PlayStation One Console by Expanding Its Memory Capacity

cstanton — Fri, 07 Aug 2026 11:10:22 GMT

Is this the one type of RAM that hasn't exploded in price?

RE: Modder Upgrades PlayStation One Console by Expanding Its Memory Capacity

Andrew J — Fri, 07 Aug 2026 08:45:00 GMT

PS One was a game changer, excusing the pun. They were like hen’s teeth as well, even months after their launch. I remember going around every shop in town looking for one and at 5 mins before closing, I found one in HMV: the chap said he found it in a window display box that he thought was empty and he’d been turning people away all day. Tomb Raider was the first game I played and it was amazing after the Mega Drive. I’ve just been replaying the first three games on a PS 5 port and to be fair, they haven’t really stood the test of time, unsurprisingly.

I’m not convinced about increasing the memory. However, as they say, “because it’s there” is a good enough reason.

RE: How to Work with MSPM0 Microcontrollers... and Build a Peripheral Expander / Processor Companion!

shabaz — Sun, 05 Jul 2026 15:29:22 GMT

I've been slowly (it's hot, hard to work!) improving this, there's now a small feature enhancement; for the ADC function, there is now an output pin called SAMP_TRIG_OUT which goes high whenever any of the three ADC inputs are being sampled.

It's useful for NTC thermistor measurements (either used directly as shown here, or via a buffer/MOSFET):

This saves energy, and also reduces thermistor self-heating. Temperature measurements are more accurate as a result. (Github repo updated).

RE: GPS Tracker using Heltec WiFi LoRa 32 V4 and REYAX RYS352A GNSS Module

Qbit — Fri, 03 Jul 2026 09:54:28 GMT

Nice build! Combining the Heltec WiFi LoRa 32 V4 with the Reyax RYS352A multi-GNSS module makes for a solid GPS tracker. The RYS352A supports GPS, GLONASS, Galileo, BeiDou, and QZSS—giving faster fixes and better coverage than GPS-only modules.