#26

ha - yeah late last night ran into another load of stuff mysteriously breaking after reboot with linux/beaglebone controller-server - gift that keeps on giving… Possibly some of my debug/probing code was doing some essential setup to the hacked midi UART.

Goes to show even a ‘lightweight’ deployment of arch linux can be pretty complex and potentially fragile. I find alsa-midi in particular kind of frustrating, because of unpredictable device numbering and intermitency in oss-emulation mode. Think I’m still suffering some bugs in my workarounds, but probably some of the complexity there is inherent to any platform supporting USB hubs.

Still, I would argue that in 2016 embedded linux probably sucks the least for building DIY headless controller software (especially prototyping)! Might be kicking myself in 6 months time for not hacking more on minipicolisp (or forth as explored by @zebra). But yea clozure-common-lisp/linux-beaglebone is going to be a killer control stack once dust finally settles around all my gross plumbing.

2 Likes
#27

Found this set of slides online again, which is what initially got me interested in cortex M7 - also mentions the technologies underlying the other boards/devices discussed on this thread, special accelerator instructions etc:
http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf

So an update on my M7 adventure - turns out the cheap and awesome-sounding Nucleo-F746ZG is hobbled by ST’s horrible software ecosystem - many others complain about the ‘hal’ software layer:
http://www.eevblog.com/forum/microcontrollers/st’s-(stm32cube)-software-ecosystem-is-terrible-how-can-we-fix-it/
so far not having much luck getting this thing’s i2s pins to springing into life, but managed to enlist the help of a much more experienced embedded programmer - hoping I can access & hopefully share some simple C recipes with those who’re also curious about the m7. Also posted on ST forums, though not holding out much hope there.

Kind of curious as to your take on this, as someone who’s obviously done quite a bit with the M4…

1 Like
#28

the aleph uses the AD1939 codec in standalone mode. by default it runs at 48k, but it can be hacked to run at other sampling rates up to 192k. i believe this can be achieved just by setting the ADC control register (p.27 of linked datasheet.)

1 Like
#29

@rick , stm32Cube is awful, you probably want just their “standard peripheral library” if there is one for the part you’re using.

have also had some success with ChibiOS HAL layer.

#30

handed this off to the most hardcore embedded guru in our office - he couldn’t make it go! This guy was debugging on the level of checking registers / pins against microprocessor manual & board schematic, way deeper than I’d have been able to go.

Definitely wouldn’t reccomend the nucleo-STM32F746 board to any weekend warriors hoping to quickly get the i2s ports up & running. If anyone has a working recipe for that board’s i2s peripherals, don’t be shy about sharing! Kind of a shame since those nucleo boards are cheap as chips, but I guess maybe the atmel M7 offerings may be a better choice for now…

Oh and by the way I took the plunge and hacked on a linux kernel module to provide a ‘codec-less’ i2s driver for the raspberry pi 3. It works pretty good! Just trying to also get the RT-patched kernel cooking on that platform - should be able to distribute an image of my arch setup for anyone trying to get a quick 'n dirty i2s floating-point DSP host on the go with < $100 worth of bits…

1 Like
#31

i’d love to get an image or pkgbuild for that module… got a couple rpi3’s here that are earmarked for supercollider experiment, and running arch would be ideal.

2 Likes
#32

tomorrow night I will try and get the RT pi3/arch setup packed up to share, also some rough notes on how the system is set up before I forget everything. Had, wanted to fix the remaining bugs there before distributing an image, but maybe if I just upload it warts and all, others may also be able to help out with those. It’s only an annoying delay on ssh login, also the latency can probably be tuned down further using IRQ fettling - got things down around a couple of milliseconds, and not yet seeing quite the ultra-stable performance under heavy DSP load I anticipated.

Testbench for these initial results is a usbstreamer usb->i2s device and rpi3 running as i2s slave - maybe stability would be improved if the pi3 works as i2s master. On the slightly crazy side, should totally be possible to squeeze a multichannel setup in there using multiple DAC/ADCs with icestick fpga to interleave/deinterleave, but this would require going quite a bit deeper into the kernel module work or hacking on jack…

#33

Wow, I did not know the Axoloti. It’s cheap and seems really cool, does someone here use it ? Been looking for that kind of stuff for months.

#34

Yup Im a big fan of it, use it daily … its a lot of fun, and really flexible.
theres a lines post here about it.

if you want to learn more go to the axoloti forum its a vibrant and friendly community… and if you have any questions (e.g. about suitability) you’ll get the answers there :slight_smile:

#35

Oh, I realize I just watched your videos this morning on their forum, couldn’t remember when I saw you, now I know :wink:

I’ll buy it this week. :smiley:

1 Like
#36

For the F7 they only released a HAL library. It seems they’ve made a lot of improvements since I last tried to use it and the code generator from CubeMX is not bad at getting stuff running quickly to test the board. Still will probably ultimately replace most of the generated code…

#37

afaik noone has demonstrated a working i2s echo program or similar using the marked i2s pins on nucleo F7 boards. Kind of a deal-breaker if you want to roll your own ‘reconfigurable sound synthesis HW’!

Actually someone from ST finally got back to me on the i2s question - apparently you have to buy two boards in order to satisfy their tech support that i2s master isn’t coming to life (90% sure the relevant pins are unresponsive when flashing i2s master program & in fact the ISR to send data is never called in their example code):
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3A%2F%2Fmy.st.com%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2Fnucleo-F746ZG%20I2S%20example&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=32
Would be so awesome to see this issue actually get solved - cortex M7 is quite the alluring beast but rapidly got out of my depth on this one…

#38

I’m working on getting I2S working right now… will let you know :wink:

2 Likes
#39

Might never get round to cleaning up the whole arch system & config for others to use, but here are the bare i2s kernel modules at least!

https://github.com/rick-monster/bare-i2s-pi3

think I tested this guy’s pre-compiled RT kernel on arch and it works:

http://www.frank-durr.de/?p=203

Also successfully compiled my own by following his instructions. Here’s the pi kernel with RT patch already applied:
https://github.com/rick-monster/linux

You’ll probably find systemd borks a bit with either frank-durr or custom-compiled kernel. In particular systemd-logind won’t run on startup so ssh logins hang for 20s after password before finally giving up and working. Haven’t found a fix for that, but I think it may help to recompile systemd from github HEAD…

#40

Hey - curious, did you have any success with the nucleo F7 i2s peripherals?

#41

Yes. It was actually not very hard to set up. It turned out the problem was another fault on the board and not a problem with my programming :slight_smile:

I’m actually using the SAI, which can also speak I2S, but the configuration is similar.

1 Like
#42

Anyway, the easiest way to get everything set up is to use their CubeMX software to generate the code. Most of the work is in setting up the clocking. You need to ensure the peripheral is sending the right master clock, frame clock, and serial clock to your I2S device. That all depends on settings the right PLL multipliers and dividers for the clock rate at which your processor is being run at. It can be a bit tricky to figure out manually, which is why the clock configuration screen in CubeMX is very handy.

1 Like
#43

Here’s another teensy based framework, called Prynth:

2 Likes
#44

its an interesting one, seems to be mainly a small hardware board that has multiplexed analog i/o, so you can have up to 80 analog inputs… quite nice, as Id assume this could be used with other platforms.
the rest seems fairly ‘standard’, RPi, supercollider, USB audio interface…
I might give this a go, since I’ve got a spare PI2 with a hifiberry fitted (rather than a usb audio interface).
the only ‘caveat’ I have is… latency, it doesn’t appear to be using realtime OS as far as i can tell… though of course they could switch this out.

will be a nice project though, if others start sharing project details they create.
(I was a little disappointed they didn’t have the schematic/code for the MITT :slight_smile: )

2 Likes
#45

hey
hope you don’t mind but i added norns and tried to make the chart a bit more legible

2 Likes