#63

I think this is done now, it needs testing and reviewing. If you do want to review the changes you might find it easier to review each commit. I’ve had a quick play on my teletype and earthsea, no problems so far. I’ll load it up on meadowphysics later, but I don’t have a whitewale, so can’t test that (or kria).

#64

The best would be if you can test against the entire branch I’m pull-requesting, rather than just those 3 files. helps to nail down what’s going on if there is a bug. Feel free to PM me if you need a hand with the requisite git spells or any other basic questions…

#65

posted a comment on the PR. i can help with testing white whale (and will test orca once i get around to moving my repo).

#68

Yes. First test and there is a bug for sure. Deleting the operators works fine, but for instance with this simple task:

ENC/VAL -> ADD/A
ADD/SUM -> SCREEN/FILL

With ENC/MAX=10 and ADD/B=5, I can modify the screen shade from 5 to 15.
Now if I remove the operator ADD, in between PRESET and SCREEN, everything seems to work fine until I press the Mode Switch to go into performance mode. Then and only then my Aleph freezes and I have to remove the power plug. I tried some other configurations, same issue each time so far.

Aleph Testers Corner
#69

let me just say that while much of this thread is over my head, following along and seeing the effort put forth by this community is very inspiring.

2 Likes
#70

The system and skeleton merge PR has been merged. If anyone needs any help porting or rebasing code, let me know.

1 Like
#71

will try to update orca accordingly and move it to the main repo within the next couple of weeks.

1 Like
#72

did have a quick try compiling stuff from mod against avr32_lib couple of weeks ago but somehow couldn’t get a grip on it.

Attempting to add a couple of bees features I wanted unexpectedly turned into an enormous refactor so now I’m too far into that to turn back. Hopefully it actually bears some fruit in the next week or two then I can think about whether to look at this merge again or more blackfin dev…

#73

Is that definitely the plan? Or are we going to split the mod repo into separate pieces, each with a submodule for the skeleton folder?

#74

i’d prefer to split the repos with a skeleton submodule. i’ll need to read up (or some assistance) on the submodule setup.

#75

I’m happy to help get it up and running.

It would be best to get URLs and names of repos sorted out first though, trivial as that may seem. I think a new GitHub org might be best, the current monome one has too many potential name clashes. We could bring the aleph repo over to it too.

Now’s also the opportunity to rename skeleton if you want to. Hilariously (well I think so anyway), system is probably a much better name. The asf stuff should also go in this repo, I’d like to have a go at getting the asf as small as possible as we’re all going to end up with several copies of it on our computer now.

#76

i’m good with “system” but we could also make it even more descriptive?

i can move the existing meadowphysics repo. moving aleph would be great.

asf should only have two copies in the end-- one for modular, one for aleph, correct?

#77

The aleph repo will have one, and the skeleton repo will have one, but because the skeleton repo will be included in each of the firmware repos via a submodule (es, mp, tt, ww, kria & orca), you end up with a lot of copies of the same code on disk. It’s worth spending a bit of time shrinking it down as it’s enormous (unit tests, dsp libs, etc)

#78

definitely need to shrink down that asf lib it’s a beast! I noticed aleph actually uses a different asf version to modular - also the docs for aleph (maybe post on old forum) said somewhere that the asf library had been modified from stock.

Skimming through the git log for that dir I concluded that any modifications probably didn’t matter (only stuff I saw was to do with serial debug). Wasn’t able to download a ‘vanilla’ asf with same version number as the one in aleph to diff changes conclusively and kind of worried in case the asf initially checked in to git is non-stock.

@zebra, @tehn any important useful stuff hidden in the aleph asf directory that you can remember?

#79

i did not modify the ASF for the modules.

i also did attempt to cut the ASF down substantially, but if there is further pruning that could be done, that’d be excellent.

would it be possible (better?) if system wasn’t a submodule? but just a dependency that needed to exist at the same folder level (as is now?)

#80

hello, sorry for my silence on this topic, been a very busy few weeks.

@rick_monster for the ASF in the aleph repo, i spent quite some time stripping out a huge amount of unused stuff. (though there is still some left, for sure.) that’s the main modification besides the serial debug tweaks.

i’m not sure what if any APIs have been changed in subsequent ASF versions. i actually doubt there are any changes that would affect us since IIRC atmel’s changes are almost entirely additional functions for SAM series and they haven’t updated avr32 stuff in quite some time.

#81

i’m good with whatever we agree on in terms of the repo(s) set up - my knowledge of git is very basic so i will trust you guys to come up with whatever makes most sense. sounds like i should wait with moving orca until it’s set up then?

#82

Okay, I’m having a go at trimming the asf down…

So far, 1.6G -> 32M

Next step is to get it shimmed into the existing aleph and mod repos to make sure that I haven’t deleted anything I shouldn’t have!

1 Like
Github reorganization
#83

EDIT: reposted this in the other thread

Another update…

Have got the updated and pruned version of the ASF to build against all the modules and bees.

I had to patch usbb_host.c as Atmel missed out an include, looks like @tehn had to do the same patch, @zebra dealt with the bug in a different way (see the gist for the patch) . That was enough to get all the modules working.

To get bees to build I had to copy over the altered version of print_funcs.[hc] as well as add #include "aleph_board.h" back into board.h. So if you do ever want aleph/bees to build against the modules version of system (a.k.a avr32_lib) then the ASF stuff should be relatively trivial.

Now that I can check that everything compiles, I’m going to try and shrink the ASF down as much as possible, I’ll probably make a repo with the scripts and the ASF zip file, so that it’s easy to recreate the work (e.g. if we decide that some files that were removed are wanted again.)

After that it’s time to think about…

  • Directory layouts for each of the module repos.
  • Directory layout for system repo.
  • What to name the repos and where to put them.
  • How to link system (e.g submodules or not…)
3 Likes
#84

Awesome stuff!

Meanwhile my bees overhaul branch is finally compiling - still a long way to go before all the features work again after a totally gratuitous shakeup of some core data structures. Hopefully the new ‘cleaner’ representation of a bees net is actually workable! (bit scary maybe I bit off more than I can chew here)

I will try to make the main branch of bees compile correctly against the new low-fat asf in parallel to that effort. As for the board.h I guess the best way is just wrap that one line in #ifdef aleph or something?

However building bees against system might have to wait till I either finish the overhaul or give up on it…

3 Likes