#21

i entered what i recall

but others can update with factual info that i missed

1 Like
#22

Cool spreadsheet. I would edit it myself, but I can barely use Excel


Anyway, the Axoloti is an Arm Cortex M4, not an A4, and it uses ChibiOS for it’s OS.

I’d be okay with the latency so long as it was predicable and constant. For things like delays and reverbs (with analog mix), or the beginning or end of the signal chain, the extra CPU grunt would be useful. And with a bigger buffer you can start to really take advantage of vector instruction sets.

The biggest problem I have with using Linux for embedded devices is getting reproducible firmware builds like I can get with bare-metal. Has anyone had any success with Buildroot? NixOS also looks like something to watch for in the future.

The AVR32 is particularly frustrating as Atmel have stopped developing the line (ARM won), so we’re stuck with GCC 4.4. Modern ARM dev boards seem to provide a much better debugging experience too.

2 Likes
#23

Updated. @sam: Just think of it like a monome grid of text boxes!

3 Likes
#24

Ive updated the sheet
 though there are a few things that don’t quite fit


axoloti has 19 gpio ports, which can be assigned, to various combinations of analog/digital.
see http://community.axoloti.com/t/official-pin-outs-revised-work-in-progress/1284

it would probably be useful to detail voltages on IO , some have 3.3v some 5v

should we include ethernet? its a useful connectivity option
 as is SPI/I2C

also the bela IO options, can be extended quite a bit with additional capes e.g. the audio expander adds 4 extra audio channels @ 44.1 kHz (or 8 at 22khz), and the multiplexer 64 analog ins @ 2.75khz (or you can half the channels for higher rates)

1 Like
#25

Excellent! Let’s just get the info in there - just add more rows or a cell with a block of text of needed. We can organize after it is there.

1 Like
#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?