#21

We’ve all been there…

Surely a uc3b0256? 256k flash / 32k ram

Cool, I’m up for doing this. I’ll see what happens regarding using bees in the module code or not before I start though. It’s possible if we do go down that route then we’ll actually need all new code bases anyway.

#22

ok, 16k / 32k is more than i thought.

also i was being totally nuts when i thought .bss was in flash. (misread linker script.) it is in INTRAM, of course. sorry.

INTRAM is defined to be 96k in the script for uc3b0512 and 32k for the uc3b0256
(e.g. [ https://github.com/tehn/mod/blob/master/system/link_uc3b0512.lds#L61 ] )

both of them have stack sized defined at 4k (unless i’m misisng a definition somewhere else.) wonder if that’s ideal.

#23

A few more thoughts…

Library merging

I’ve had a quick play at using avr32_lib in place of skeleton, by and large it seems very doable, while there are a few files that are different, it seems to be mainly additions rather than modifications. So on a technical level it’s fine. Philosophically, I’m not so sure, avr32_lib has a lot of very aleph specific stuff in it. It might be better to keep them separate, but try to make the changes more explicit (e.g. put the additions in different files).

Whatever we decide on this, I’m happy to put the grunt work in on it (as well as merging skeleton and system).

Bees ops on modules

I also had a go at trying to get a bees op to run on a module, but the dependency graph pretty quickly gets to all of bees. For example:

op_add -> net_protected -> net -> everything

So unless @zebra fancies re-architecting the way the ops work, it’s a bit of a no-go. Maybe a better idea might be to try and abstract the module firmwares away from hardware and then wrap those in multiple ways (i.e. module, aleph bees op, aleph app, simulator). Basically what @zebra suggests in the first post.

It should be possible to construct a scheme such that we’d be able to run multiple of these apps on a module, or even create a hybrid app that is a composite of 2 (as @scanner_darkly mentioned).

This is the kind of thing that I’d do with an interface or a typeclass, or even a C++ template, but I just don’t know the idiomatic way to solve such problems in C. I’ve just gone full time stay at home dad, which is totally awesome, but unfortunately means I don’t have the continuous free head space to really get to grips with this kind of a programming problem. All the same I’d love to be able to write something like the following:

int main() {
    app_t app;
    app_init(&app);

    app_kria_t kria;
    init_kria(&kria);

    app_connect_clock(&app, &kria.clock);
    app_connect_dac(&app, 0, &kria.output_0);
    app_connect_dac(&app, 1, &kria.output_1);
    app_connect_trigger(&app, 0, &kria.trigger_0);
    app_connect_trigger(&app, 1, &kria.trigger_1);
    app_connect_trigger(&app, 2, &kria.trigger_2);
    app_connect_trigger(&app, 3, &kria.trigger_3);
    app_connect_monome(&app, &kria.monome);
    app_connect_load_preset(&app, &kria.load_preset);
    app_connect_save_preset(&app, &kria.save_preset);

    app_run(&app);
}

or maybe app_run takes an array of app_t so we can run multiple apps.

#24

correct! edited my post.

this seems to be a good first step before considering merging avr32-lib

i’m intrigued by the app_connect interfacing method.

#25

libs

avr32_lib has a lot of very aleph specific stuff in it.

for sure, lots of stuff for hardware that modules don’t have:

  • encoders
  • screen
  • filesystem (sdcard and FAT)
  • blackfin
  • heap management

the stuff that is common has already been factored out by @tehn when he made skeleton in the first place:

  • timers (hardware-agnostic)
  • event queue (hardware-agnostic)
  • interrupt setup (requires some tweaking for hardware)
  • i2c setup
  • ADC driver (AD7923)
  • USB host drivers

(init.c could stand some refactoring IMO.)

teletype has a screen, so screen, region, and font got re-added to system.

TT also adds a filesystem stuff, but pulls the FAT library from the ASF and also the USB MSC host driver, doesn’t need an sdcard driver.

i also see memory module in TT but it doesn’t seem to do anything because it doesn’t have a heap.

so… i definitely see the reworked structure as having, by necessity, a couple layers:

  • stuff that is literally the same for every device (e.g. soft timer and event queue, some peripheral drivers)
  • code modules that are completley hardware dependent (e.g. blackfin communication)
  • stuff that can be slightly tweaked in headers or preprocesser (e.g. board conf, maybe event types)
  • differences best addressed at the makefile (e.g. which MCU-specific ASF components to pull in)

my main goal for wanting to do this in the first place (besides just tidiness) is so that improvements and additions can be more easily propogated between codebases. for example, the TT/system codebase takes the aleph lib and adds keyboard parsing, i2c communication with monome modules, mass storage USB driver, and maybe a better FAT library. aleph would benefit just as well from all these things and become a more useful tool for interacting with monome modular systems, etc.

finally i’ll point out that just because a code module is in the library folder doesn’t mean that it has to be included all the time. an example: screen handling stuff is not board-specific, it can stay in the lib, and of course builds targeting a screen-less device won’t use it. if we come up with a way to make a buffer refresh take half the time (by optimizing the copy/invert/pack buffer step) then TT and aleph should benefit equally without copy-pasting.

ops

op_add -> net_protected -> net -> everything

for sure, whatever non-bees framework uses the operators will need to supply some things. the operator code itself really just needs net_activate() i think, which is the routine that updates an op output. and there are some operator types that communicate with peripherals (grid/arc, midi, HID, serial, screen drawing.) the app needs to know what ops of those types exist and arbitrate between those ops and the drivers.

but statically instantiating operators and hardcoding their connections will be much, much simpler than what bees does. much of the complexity in net, net_protected etc becomes irrelevant without the need to dynamically edit the graph, save/restore the graph, manage presets, and deal with the DSP. (it’s a pretty huge mess that could use a makeover anyways.)

i’ll try and quickly put together something showing what a really bare-bones version might look like.

1 Like
#26

sounds like library consolidation will be a good first step then? the file system and USB MSC stuff from system is already in skeleton btw, added it when working on USB storage functionality in orca.

might be helpful to agree on a specific term for the main platform agnostic code - app? should be easy to understand from the context when it’s referring to a standalone app.

apps would still be aware of what peripherals they can work with but it would be nice to separate them from the inputs/outputs with some mapping layer that could also do some transformation on coordinates, for instance - i’m thinking here of being able to split a 256 grid / aleph or tt screen between 2 or more apps/ops.

#27

I’ve started merging system and skeleton, the branch is here, and here is a diff to master. Just a reminder only teletype uses system.

So far it’s just the low hanging fruit, lots of commits each with a small and hopefully atomic change. If anyone fancies reviewing the commits and making sure the changes are sane, I’d appreciate it.

I’ve been removing files from system as they’ve been replaced with versions from skeleton, so the remaining files in system are the ones left to merge, they are:

  • adc (this is hopefully trivial too)
  • i2c
  • init
  • interrupts
  • timers

IMO these require a bit more insight as to why the changes were made, help with these would be gladly accepted. Otherwise I’ll ask @tehn to help with them once he’s back from his travels.

Finally, would it better to open up a tracking PR on GitHub to discuss the library merge?

1 Like
#28

Just popping in to offer encouragement and say I’m really excited about this work you all are doing! Keep it up!

I’d love to help but I’m still very much a code beginner, and most of what you’re discussing is over my head.

#29

sorry for the lag…

these diffs look fine to me, good idea to prune the distracting unused stuff from system as first step

(i’m glad you’re here to answer some of my github confusions!) does a tracking PR mean that you open a PR on dev or whatever, and then we can track it from the upstream repo, and it will continue to show updates that you push to your dev fork? in which case, yes, that sounds good. would like move the nitty-gritty conversation to github anyways

i have more questions (about submodules) but maybe for another thread / another day. now that the aleph repo is starting to have collaboration, would love to learn and implement more best practices for PRs and stuff.

now i have 2 things on my TODO for you: 1) minimal ctlnet demo 2) look at those remaining common sources

#30

[quote=“scanner_darkly, post:26, topic:2475”] specific term for the main platform agnostic code - app?
[/quote]
works for me!

[quote=“scanner_darkly, post:26, topic:2475”]
would be nice to separate them from the inputs/outputs with some mapping layer that could also do some transformation on coordinates [/quote]

good idea, i was trying to work out some plans for this, along the lines of what we were discussing in the other thread. LED output becomes 3 output points, and button input becmomes 3 input params…?

my goal is to perform this refactor on the grid ops in BEES, and build a minimal ctl network app (where you can statically create ops and hardwire them)… this would still be against the aleph avr32_lib.

the next goal would be to refactor aleph app code and/or module avr32_lib such that aleph can build with module lib, included as submodule.

putting this as issue on aleph GH…
( https://github.com/tehn/aleph/issues/257 )

#31

re: git - i’m okay with whatever you guys decide, we use git at work but i am still pretty much learning. but yeah, probably makes sense to move technical discussion there?

speaking of which - @sam, where is the best place to discuss your system/skeleton merge? i have some questions / comments, and i think i can probably help with timers, been spending a lot of time looking at that code.

once the libraries are consolidated could do a test app that would basically test all available inputs/outputs. thinking, it would also be good to have a way for apps to autodiscover what is connected at the moment, so that they can reconfigure dynamically if needed - this will also help with only having one hex that would work on any module and would just adjust automatically to available inputs/outputs. this should include running the same firmware on teletype.

#32

That’s the basic idea. I’d create a pull request from samdoshi/monome-mod/system-removal to tehn/mod/master, the PR shows up on the tehn/mod repo, but by convention we don’t merge it until we’re all happy with it. Any changes I make to samdoshi/monome-mod/system-removal show up on the PR as new commits (or any force pushes or squashes).

You can then make your own fork of samdoshi/monome-mod/system-removal, and create a PR against that on my repo with any changes you’d like to contribute (these will then show up in the main PR).

It’s also possible to make comments on the source code in the PR for everyone one to discuss.

PR created here…

#33

I think move the code specific stuff to GitHub, as it’s easier to comment on code there. But keep the bigger picture stuff here.

This is the tree diagram of things we have:

  • aleph
  • modules
    • trilogy
      • white whale
      • meadowphysics
      • earthsea
    • teletype

The trilogy modules seem to be really really similar, whereas teletype is wired up a bit differently.

We want to share as much code between them as possible, we’ve got the following tools at our disposable:

  • runtime (i.e. dynamic configuration)
  • #ifdef macros
  • alternatve includes and sources in config.mk
  • git submodules (or subtrees)
  • (anything else?)

I suspect we’ll end up using a combination of all of them to meet our ends, but ultimately @tehn and @zebra will have to decide as they’re the ones responsible for supporting it in the future.

I’m not 100% convinced about autodiscovery, I don’t know if the modules can figure out what DACs and ADCs are connected at runtime. Also the teletype has more RAM and flash than the others. I take it you’d like to be able to hand out a single hex file for Orca that could run on any module?

Anyway, back to system and skeleton, of the files we’ve got left, I think they fall into 2 categories:

  • library functions that have diverged a little (adc, i2c, timers) and
  • hardware setup (init, interrupts)

I propose merging the libraries and splitting the hardware setup between the teletype folder and a new common trilogy folder.

EDIT: actually maybe it would be better to factor the common code into init and then create an init_trilogy and init_teletype file for module specific init (and interrupts).

Also, I’ve just pushed the following commit to merge the i2c code.

#34

agreed on all points, will try to look at the PR later today.

you’re right, ADC/DAC stuff is likely not runtime detectable, but it doesn’t need to be, can be delegated to the init. inputs/outputs can be runtime detectable (actually already are).

the downside would be not being able to use the same hex file for all the trilogy modules (tt hex has to be separate anyway), not a big deal, just need to build it 4 times for each module, other than apps that require more CPU/RAM/flash than what trilogy provides which will have to be built for specific module but still using the same library, of course.

#35

this isn’t a big issue, but i’d like to move the aleph repo from http://github.com/tehn/aleph to http://github.com/monome/aleph

there will be a redirect in place. are there any objections or technical issues i’m not forseeing? github auto-redirects (i think, from memory)

#36

It definitely redirects https on the website, I’m not so sure about checked out repos. But it’s pretty easy to fix, if anyone needs any help just paste the output from git remote -v and I can let you know what incantation you need to perform the change the repo url.

#37

So I tried something kind of interesting today following @zebra’s suggestion to create a minimal glue operator for grid. As a little challenge I decided to get stuck in & refactor op_life to route all monome communication through the glue operator. code is here https://github.com/rick-monster/aleph/tree/grid-refactor

It works pretty good - also the discussion with @Yann_Coppier how best to manipulate grains’ patch matrix using grids is making me think about some trivial grid-oriented ops that could have a lot of uses when combined with the bare grid op, e.g:

  • x-y-addressed NxM memory matrix with inputs for momentary, latching mono-row, mono-col
  • row-reader op for memory matrix
  • column reader op for memory matrix

So the idea is these 3 can be patched together into a horizontal or vertical step-sequencer or put to another use for the patch matrix (can’t quite see how it all hangs together yet maybe something’s missing), but then because it’s all routed through bees with a standardised address-bus arrangement you could for example asynchronously run the column reader over a running instance of life.

Gonna keep hacking on this tomorrow because it’s fun! But totally new to grid (only playing around since yesterday) & no familiarity as yet with meadowphysics or white whale. Does the route I’m going down (with bees x-y address bus) seem like it will support the heavier apps?

I guess if not then we may be able to find a way to have some apps directly interface the grid, some apps use this bees routing. Would appreciate to hear everyone’s thoughts especially if I am totally reinventing the wheel or blundering toward a known minefield…

EDIT:

Got as far as writing the 2D memory described above, then realised there must be a better way. Just thought hard about this problem & I believe now the following new bees primitives are all that’s required to provide the desired patch-matrix functionality, also building blocks for more hackable bees-routed step-sequencer:

2D memory. inputs: x, y write, read, toggle. outputs: x, y, val

1D memory. inputs: n, write, read. outputs: n, val.

ITER (iterate) operator - 3 inputs: times, value, stop. 2 Outputs: idx, value_out. A single bang to value triggers the following sequence of bangs:

  • 0->idx, value->value_out
  • 1->idx, value->value_out
    …
  • times->idx, value->value_out .

If stop is banged during this sequence, we get an early-out from the iteration.

EDIT:

Above 3 ops available on the feature branch - also added the read input to new op_life but that’s untested & unpushed…

#38

Out of the ‘coders’ on this thread, who’s got both an aleph and one of the modules?

#39

i have aleph and teletype

#40

no aleph, i have teletype, meadowphysics, white whale.