#11

@zebra Thank you for providing more insights into how the system works, and on some of the design decisions. The backend looks quite clean and readable. I look forward to diving in more.

Just to clarify, does this mean that the lib abstracts away the thread handling from the user? I personally would want an API that gives me the option to implement my own thread if I wanted to, like how liblo does it with their high level and low level APIs. This is what I do with libmonome right now, and having that kind of control has been super helpful for me.

#12

that’s kinda what i’m asking. lib doesnt exist so let’s decide. sounds like you would want a callback whenever an event is posted, regardless of what thread it originates from. so the onus of implementing thread-safe handlers, or a queue or whatever, is on the library user.

#13

Would it be possible to design things in such a way to that you could have both, or is it an either/or sort of thing? Could there be a way for the thread-safe interfaces to be built on top of the callback driven interface? I don’t have much experience building things with thread-safe considerations, so I’d be interested to know what kind of considerations go into that.

#14

yes, definitely possible. gotta think about the details though. (and hopefully get input from other people - realistically, i can’t see myself working on this particular refactor anytime very soon.)

here’s another wacky idea: flip it around; instead of libnorns being embedded in some program, matron could have a plugin interface for different interpreter VMs? (???)

2 Likes
#15

Just pulled the trigger on the Norns, and it should show up on my doorstep by the end of the week. Hoping to spend the following weekends working on some small “low level” peripheral experiments. If anything useful comes from it, I’ll be sure to post on it HitGub or something like that.

Right now, my priorities are writing small self contained C programs that poll GPIO for encoders/buttons, and things that can write to the framebuffer. The sorts of things you can run on the commandline using a shell or serial TTY connection.

Don’t see much point in writing any audio IO code, since there is enough JACK client boilerplate code, and I am assuming those bits are pretty straight-ahead.

Tips/wisdom/warnings/poems appreciated :slight_smile:

Oh! I’ll be in the Boston area around this time, if anyone is around and wants to do norns stuff.

4 Likes
#16

Derek Molloy has a nice book on the raspberry pi, that discusses (among many other things), how to poll GPIO pins using C: http://exploringrpi.com/. I’ve only skimmed it, but I do have his book on the beagle bone, which repeats a lot of the same material. Anyway, maybe it will be of help…

1 Like
#17

Not sure where to post this other than here, but is serial access known to be finnicky?

This is the tidbit from the norns documentation:

screen /dev/tty.usb(tab) 115200

Now, I can never seem to get that baud rate to work. It will just hang, even if I hit keys. Tried on MacOS Mojave, as well as my Alpine Linux laptop, and got identical results.

Running screen on without specifying the baud rate works, but not consistently. Sometimes, I’ll get garbage characters on the screen. My approach is to just C-a k and restart until I see a login prompt. It seems like once it works once, it continues to work.

Is this a familiar problem for anyone? Is this just a silly thing with norns, or is it a silly thing with serial and screen?

1 Like
#18

that’s perplexing.

FYI the serial is handled by the old standard FT232 FTDI chip. the fact that it works sometimes is suspicious, maybe ruling out a soldering issue.

have you tried any of the heavier com applications ie minicom?

linux has a good driver for FTDI, and macos recently got good at 10.14, but may be problems if you have an old OEM FTDI driver installed with/over the AppleFTDI stock driver.

#19

Well, I have now. Things seem to behave themselves now. Higher baud rate seems to be in place too, as the terminal is much snappier now. Definitely will be using minicom over screen from now on.

One thing I had to do was disable hardware flow control in the serial port settings, otherwise keyboard input didn’t work. (solved via this SO post https://superuser.com/questions/229265/how-can-i-login-send-text-with-minicom).

1 Like
#20

Some smiles for you all today:

smiles

Started this low-level project of mine with a simple framebuffer test. Already had some framebuffer code lying around, so it was low hanging fruit.

Code can be found here. More to come (hopefully) soon:

Next thing to do will be looking at the existing GPIO and building a small event listener. Beyond that, there are plenty of interesting paths to take. Not sure which one I want to take yet at the moment…

3 Likes
#21

super cool!

there’s been talk of this before, but seeing as how matron does all of the framebuffer/gpio/etc also in c, perhaps it’s a worthy endeavor to extract this functionality into a library?

1 Like
#22

it may be worth mentioning here… I re-worked the ssd1322 display driver to accept a 180 degree rotation command from an overlay. (my pi-norns has the display hardware flipped now)

Perhaps I should push that to the monome/linux source tree?

1 Like
#23

Maybe? I don’t really know. At the moment, I am very much enjoying my simple and stupid standalone programs. A matron library would allow people to give people a more robust starting point for larger more complicated (and perhaps more interesting) programs, but this to me steals some of the fun that comes from hacking on something like the norns.

I had a thought about building some really lightweight wrappers around some of the raw GPIO/framebuffer stuff. One of those things you could just drop into a codebase like those STB single-header libraries.

#24

my 2c: most components of matron are pretty tightly coupled around architectural assumptions like the event queue. abstracting away those couplings would be a pain (e.g. even the gpio module requires events.h) ; what’s left is light wrappers around libraries and other basically trivial stuff, but it does include e.g. some hardcoded paths to filesystem locations used by ioctl and so on.

IOW i agree that both approaches are useful. again, @ngwese already made a libmatron branch, probably worth upstreaming in case people are interested in replacing core “business logic” of matron without starting from scratch.

and lower-level bits, though simple, are probably worth putting together so all the hardcoded magic words are available if you want to make something totally different - like blasting the framebuffer yourself instead of using cairo, using a single-thread event model, doing audio stuff in the same process, i dunno.

at some level it does seem like duplication of effort and the really awsome thing to do would be refactoring matron itself to use a library for the really low-level things.

1 Like
#25

It is very much my intension to pull that branch in line with the current version of matron, do a bit of cleanup and open a PR for review. Doing all this is 2-3 deep on my TODO list at the moment (mostly behind finishing the maiden improvements currently in flight).

#26

Hey @PaulBatchelor, do I need a norns to try the button.c example, or will it work with just a breadboard, a Pi + a push button? If so, how would I set it up?

#27

You probably will need a norns or a norns configured device. I say this because the example is configured to read button events (button number + state) from “/dev/input/by-path/platform-keys-event”, rather than the GPIO pins. My guess is that there is some process that is polling the raw GPIO values, and converting them to linux input events. @zebra I think would know.

#28

we are the gpio-key dtoverlay which is a standard in the raspberry pi linux bundle

we also use the encoders overlay, though slightly modified if I recall.

(i can point at some resources in the norns-image repo later when I am not on my phone)

1 Like
#29

Thanks, I thought it would be something like that.

#30

Got some time this weekend to build something a little more functional. This little demo program uses the knobs to control the frequency and amplitude of a sine tone. Slider position is also being visualized as well. There’s a waveform display (oscilloscope?) to visualize the audio, just to try and push the limits of the screen.

Mind your ears. SHRILL sine waves. Sorry.

Up to this point, I was able to get away with using a generic arm cross compiler to build static binaries. With this program, I needed to link with the JACK libraries, and was only able to do it if I built the program on the device itself. Hoping to figure out how to go back to using a cross compiler, because compiling on the device is a bit of a drag. Has anyone managed to use buildroot to build software for the norns?

6 Likes