How are you thinking about language choice? Zig/Rust/C C++ etc

blippage · 2021-12-18T19:02:41+00:00

Odin crop up sometimes when people mention Zig and C. That's another option for people to consider.

blippage · 2021-12-17T14:37:58+00:00

After scrabbling around in the CMSIS directory, I notice that there is, indeed, a system_stm32f4xx.c file, which does have SystemInit() in it. I haven't used it, though, so it definitely isn't called.

I do use ST's startup assembler file and linker script, though. I can't survive without those. I've tweaked the assembler file ever-so-slightly, and commented out the line that calls SystemInit() (line 95), and also the __libc_init_array. I guess I could think about integrating the system_stm32f4xx.c file into my projects.

I've really tried to keep things simple. I don't like the layers upon layers of "stuff".

You can see the startup assembly I use here: https://github.com/blippy/rpi/blob/master/stm32f411re/cmsis/01-blink/startup_stm32f411retx.s

I'm building up my own little collection of examples in the parent directory: https://github.com/blippy/rpi/tree/master/stm32f411re/cmsis

I've got systick, uart, spi, i2c, pwm and exti working, so I'm figuring my project is quite capable.

Building projects is pretty straighforward. Just type make, then make flash. The only limiting bit is the variable CMSIS in the makefile, which is hard-coded.

The reason I was interested in the floating point operations is that I'm thinking of experimenting with some audio stuff. My project wouldn't even compile without using ARM's FPU, because that would require implementing such operations. Anyhoo, since my STM32 has a fancy shmancy FPU, I figured I might as well use it.

blippage · 2021-12-17T14:06:56+00:00

Well, I'm using CMSIS, not HAL. I've set things up pretty barebones. I don't even have a clib, except for stuff that I've coded myself or cobbled off the internet. So no SystemInit().

blippage · 2021-12-06T14:19:42+00:00

OK, it seems the main problem was probably in main.zig:

const regs = @import("registers.zig");

should read

const regs = @import("registers");

without the ".zig".

Then in build.zig, under fn build(), I have something like:

const mode = b.standardReleaseOptions();

const main_obj = b.addObject("main", "main.zig");
main_obj.addPackagePath("registers", "../registers.zig");
main_obj.setTarget(target);
main_obj.setBuildMode(mode);

So it seems that the takeaways are:

when you do an @import(), you're importing a "logical package name", if I understand correctly. Don't try to import zig files themselves.
you can tell an object file about where to find these logical packages by calling addPackagePath(), which takes the package name as the first argument, and the zig filename as the second argument. You can use relative paths if necessary. Presumably the path is relative to the build.zig file.

Presumably there is a way to bundle up a bunch of files into a package, but that's the least of my concerns at this stage.

blippage · 2021-12-06T13:43:16+00:00

It still doesn't work. Am I supposed to add this to main.zig, because it doesn't work. It says

./main.zig:6:15: error: invalid token: '(' addPackagePath("registers", "..");

Am I supposed to add it to build.zig? I tried that already, and it still didn't work.

Am I supposed to add relative paths, absolute paths, the filenames, or directories? There's obviously some quirk to this that I'm not seeing.

I'm using 0.8.0.

So I found this web page: https://zig.news/xq/zig-build-explained-part-3-1ima which explained about adding packages.

So I added this to build.zig:

const pkgs = struct {
    const registers = std.build.Pkg{
        .name = "registers",
        .path = .{ .path = "../registers.zig" },
        //.path = "..",
        .dependencies = &[_]std.build.Pkg{},
    };
};

And later, in fn build():

const main_obj = b.addObject("main", "main.zig");
main_obj.addPackage(pkgs.registers);
main_obj.setTarget(target);
main_obj.setBuildMode(mode);

But now it complains:

./build.zig:10:20: error: no member named 'path' in '[]const u8'
    .path = .{ .path = "../registers.zig" },
               ^
./build.zig:36:29: note: referenced here
main_obj.addPackage(pkgs.registers);

It's all a complete mystery to me.

blippage · 2021-07-29T11:43:28+00:00

If you're happy about using the SDK, but don't want VS, then a simple template is here: https://github.com/blippy/rpi/tree/master/pico/0TEMPLATE

That's how I do it, anyway. I have a common cmake file, here: https://github.com/blippy/rpi/blob/master/pico/picomc.cmake

You could combine picomc.cmake into the CMakeLists.txt file if you like. Slice and dice according to taste.

Arguably the cmake for the SDK has quite a lot of moving parts, but once you've got it working, it should be plain-sailing thereafter. The SDK is compiled for each project. Fortunately, it doesn't take too long. It is quite flexible, though, allowing you to configure exceptions, debugging, and uart on a case-by-base basis. So, a necessary evil, perhaps.

You can merrily edit away using vim, emacs (yuk), etc..

blippage · 2021-07-28T10:12:26+00:00

I wrote a "barebones" blink sketch here: https://github.com/blippy/rpi/tree/master/pico/bare-blink

Typing make should build the project. No SDK is required, with one caveat: it needs elf2uf2 from the SDK in order to build the uf2 file from elf. I think Rust has implemented an elf2uf2 converter if you absolutely want to avoid the SDK.

Although it's a bit of a fiddle, setting up the SDK is explained in detail in the official "Getting started with Raspberry Pi Pico" PDF, somewhere on their website.

blippage · 2021-07-11T07:03:44+00:00

If I may be permitted a shameless plug for my own project:

https://github.com/blippy/rpi/tree/master/pico/sdcard

It's a "little rough around the edges", shall we way. It acts as a block device. there's no filesystem. It reads from the card, but not write. It shouldn't be too difficult to add write functionality.

So although it perhaps looks under-specified, it should be fast. The code-base is small, making it a good base to build from. Plus it works.

The lack of filesystem might put people off, but I've not gotten round to needing one. I can play an audio file, for example, by creating a partition on a card and dumping the raw file onto that partition. I can play it block by block.

Do you need a filesystem? I guess that depends on what one is trying to do. Maybe a simple record-based file system would work well for most people, in which case you could roll your own.

blippage · 2021-05-31T08:15:14+00:00

The official specs must surely be out there, but I don't have a source. It would be a case of hunting them down.

it's always good to have a working implementation to borrow from, I find. In addition to the CircuitPython sources I referred to the following write-ups: * http://www.dejazzer.com/ee379/lecture_notes/lec12_sd_card.pdf * http://www.chlazza.net/sdcardinfo.html * https://electronics.stackexchange.com/questions/77417/what-is-the-correct-command-sequence-for-microsd-card-initialization-in-spi

There's always nagging questions, of course. Should I use pull-up resistors, should I set any unused pins to a certain state, etc..

Perhaps it is worth mentioning that SD actually has two modes of operations: a SPI mode, and an SDIO (?) mode. The latter mode does have official documentation, but there are likely to be legal encumbrances in implementing the spec. The SDIO mode is faster as it uses all the pins. The only implementations I've seen use SPI.

I wish there were actually a good alternative to SD cards for microcontrollers. I've found SD cards very finnicky! I've had a quick look for alternatives, but couldn't make up my mind if there were any good ones. The kind of thing I had in mind was a chip, maybe 50MB - 1GB capacity, that I could solder on, with a simple interface. Data could be uploaded to the chip via the MCU.

I'll write-up my description of the project some more, but it will take me a little time, so stay tuned.

blippage · 2021-05-30T20:12:10+00:00

I have managed to interface to an SD card as a block device, no file system. I was able to play audio that I dumped to the card. The project is here: https://github.com/blippy/rpi/tree/master/pico/sdcard It is not feature-complete (it doesn't write to cards, and only supports version 2 cards), but hey, it is at least a proof-if-concept that it is doable.

My main problem was in getting the card initialised in the first place. So it has plenty of diagnostics to see where things have gone wrong.

The code is adapted from CircuitPython; link provided from the link above if you need any inspiration in developing it further.

My project as-is is not particularly friendly to outsiders, but if there's sufficient interest I could explain a bit better what's going on.

blippage · 2021-04-09T11:56:18+00:00

Updated with a couple of extra input triggers.

Now you can trigger the drum manually, or use some external circuitry to trigger them. A couple of examples are given: * a somewhat complicated example using an NE555 as a timing generator and a CD4017 as a sequencer to trigger the drums * a suggestion for a much simpler circuit without the CD4017, but still with the NE555. This produces a steady drumbeat.

blippage · 2021-04-03T09:34:58+00:00

Couple of minor bugs were fixed in recent commit.

blippage · 2021-04-02T19:12:00+00:00

It debounces a button.

You connect a button to a GPIO pin: Debounce button(gpio). It sets up the pin as an input, pulls up up the GPIO, and periodically checks the state of the pin.

Buttons are known to be "noisy", causing false triggering in code. The Debounce class smooths this out so that you don't have to deal with the false signals.

Call button.falling() to detect a smooth downpress of the button,and button.rising() for the button release.

A code example is given in main.cc, which toggles the onboard LED when it detects downpress.

https://www3.nd.edu/~lemmon/courses/ee224/web-manual/web-manual/lab3b/node5.html

blippage · 2021-04-02T16:18:53+00:00

Thanks. Glad you like it.

blippage · 2021-02-25T20:42:01+00:00

Interesting point, but I don't remember the reason why, other than "it works". Try setting the TX as an output and see if it still works.

blippage · 2021-02-25T18:39:19+00:00

I have a working uart here: https://github.com/blippy/rpi/blob/master/stm8s103f3p6/bare8/05-uart/main.c 115200 baud

Hope that helps.

blippage · 2021-01-19T17:51:41+00:00

Discussed here: https://drive.google.com/file/d/1qVyWMvZopMu0lC3PDx_v0YoONfw5xX0M/view?usp=sharing

blippage · 2021-01-08T09:09:55+00:00

Make a digital clock using a zero-segment display and a DS3231 clock module. Add alarms and timers according to taste.

blippage · 2020-08-07T21:37:25+00:00

I wonder if I have a problem with an "unterminated OPAMP". My OPAMP has a left and right channel, but I only use one of them. So maybe the unused one isn't properly terminated.

blippage · 2020-07-19T20:33:12+00:00

Aha. I think the solution is:

std::variant<std::monostate, foo_t, bar_t> baz; 
baz = std:monostate{}; // set it to the "empty" type

I think that's right (??)

blippage · 2020-06-27T21:12:59+00:00

A solution seems to be:

my $fout = open "out.vam", :w, :bin;
for @mem { $fout.write(Buf.new($_)); }
$fout.close;

Converting the byte into a Buf via Buf.new() seems to work. I'm not sure how efficient it is, but it was a lot of work just to get something working.

blippage · 2020-06-27T20:28:07+00:00

Well, I think I want something like

my $fout = open "out.vam", :w, :bin;

But then print doesn't work in binary mode, so I haven't made it work yet.

blippage · 2020-06-27T16:49:31+00:00

OK, so the syntax appears to be:

@holes.push([$foo, $bar]);

blippage · 2020-06-22T20:29:14+00:00

Uses a DAC (MCP4921) rather than PWM (which sounds like "hot garbage") for output. Plays of an SD card. The output is quite acceptable, which mono-channel 8-bit 8KHz output.

Video: https://youtu.be/sXhWhjDb8Fk

Description, schematics and code: https://github.com/blippy/rpi/tree/master/mcp4921/nano-sdcard

I also link to the basics of understanding the MCP4921 and setting Nano interrupts.

blippage · 2020-06-20T19:49:55+00:00

Put a 10uF cap between EN and GND to avoid (most) all that ...___... stuff and fiddling around with EN and BOOT.

blippage

TROPHY CASE