Module / aleph code sharing

Monome
1

Continuing the discussion from Github reorganization:

hm, it seems like actually kind of flatter? aleph will be its own repo alongside the modulars. aleph hardware is in some ways closer to TT than TT to trilogy.

this is what i’m wondering about: aleph platform has more “driver” code that is shared by applications. e.g., the blackfin interface. i wonder how much of this kind of thing to put back in libavr32. the blackfin stuff is not categorically different from the screen stuff - only some hardware uses it right now, but there’s nothing to say there won’t be another device in the future that combines avr32 and blackfin (maybe without a screen, who knows). we would want to share the blackfin SPI code with that device.

if libavr32 should be kept clean of aleph-specific code for now then i need to add an additional layer of shared code for aleph apps.

anyways, i’ll start by adding conf and init files and see how far it gets.

2

ok, made a new aleph repo with a blank app building against libavr32

so far so good! will continue adding and testing.

encountered a couple of minor wrinkles requiring code changes in the lib.

one is the fact that aleph has more event types, and these aren’t in a separate header anymore, so the quick dirty fix is this:
( https://github.com/catfact/libavr32/commit/2e1e966feb738b6a3d1eb0abf2a53195afe5cdbf#diff-72b4c976dce4c47a0610a7f8558cb6edR6 )

the other wrinkle is a little more involved because it is about some sneaky changes to naming conventions in all the conf_board.hfiles; i made a GH issue:
( https://github.com/monome/libavr32/issues/1 )

3

I can’t see the event_types.h file. I assume it’s the same as the one from aleph-old? Anyway, why not reintroduce event_types.h for all targets? You can put the #ifdef MOD_ALPEH in there. Or we could have several versions of event_types.h, one for each target.

If I’m right in my understanding, if it’s a separate file, it’s easy to override the include with an alternate one with more event types if you place the include directory first (in config.mk). Right?

The other options are C++ templates or tricks with void, neither of which sound that appealing.

So a Teletype is kinda like the control half of an Aleph, right?

I’m not sure what the best plan with the blackfin and other Aleph only code is. My gut feeling says that you should get into a state where it’s ready to be moved into the libavr32, but then hold of until it’s had time to settle down a bit.

Alternatively, is your plan to break up the Aleph repo into smaller bits too? In that case, maybe a libblackfin? Which could also include the bits of AVR32 code that talk to it over SPI, plus the common directory and so on.

Just out of interest, what’s the longer term goal for the Aleph’s point of view. Better low level code sharing? Or being able to run the apps (ww, kria, etc) on the Aleph? If it’s the later, it might be better to have a think about how that should work before making too many other changes.

4

I can’t see the event_types.h file. I assume it’s the same as the one from aleph-old?

yeah it’s in the new aleph repo, but i suppose it should go in the lib.
i’ll break that declaration out into a header.

Alternatively, is your plan to break up the Aleph repo into smaller bits too? In that case, maybe a libblackfin? Which could also include the bits of AVR32 code that talk to it over SPI, plus the common directory and so on.

i’m not sure. to be honest i’m not really loving the feeling of many small repos, and seems kind of insane to have a separate one for each aleph app and DSP module.

Just out of interest, what’s the longer term goal for the Aleph’s point
of view. Better low level code sharing? Or being able to run the apps
(ww, kria, etc) on the Aleph? If it’s the later, it might be better to
have a think about how that should work before making too many other
changes.

both; first goal is simply be using the same avr32 library so that there isn’t massive code duplication and changes/improvements can be shared more easily, in both directions

2nd step, actuallly porting app code back and forth, does indeed require some more effort. i thought first i should identify whatever little points of friction there are on the library level, also get more familiar with module code. then think about best way to wrap module code on aleph. this would involve some rewrites of module code, which i’m trying not to touch right now except as necessary.

So a Teletype is kinda like the control half of an Aleph, right?

yeah, very similar. it does run on UC3B instead of UC3A, like the other euro modules, so it lacks the second SPI port needed to talk to the blackfin efficiently.

I’m not sure what the best plan with the blackfin and other Aleph only
code is. My gut feeling says that you should get into a state where it’s
ready to be moved into the libavr32, but then hold of until it’s had time to settle down a bit.

yeah, that’s pretty much my thought. for now i’m putting aleph additions to libavr32 here, alongside the submodule:
( https://github.com/catfact/aleph/tree/master/avr32 )

and this is easily changed in the relevant makefile:
( https://github.com/catfact/aleph/blob/master/avr32/avr32_config.mk#L10 )