Aleph built with an AVR + blackfin dev kits

Monome
#1

Hi, sorry for the total n00b question here.
I have a Blackfin BF-537 Eveluation Kit, and I was looking for an example of a synthesizer built around it. The aleph is great, and it uses the BF-533 and I was wondering if you see the following as doable: If I buy a dev kit for the AVR32 A0512, do you think it’s going to be possible for me to create the serial communication and, basically, recreate the aleph using the two development boards? I have little experience in hardware units, and it seems that this could be a terrific learning experience

EDIT: I was thinking of something like this
http://www.alvidi.de/shop/product_info.php?language=en&info=p35_AVR32-Entwicklungsmodul.html

#2

It could be a ‘terrific learning experience’ but it could also be incredibly frustrating and unsatisfying situation. The serial communication between the two processors is not trivial to implement and while you could likely just load the bees (or similar aleph AVR program) on the AVR it likely won’t make a lot of sense without the hardware.

It probably makes more sense to use something like an STM32 discovery board and roll your own communication protocol that makes sense for whatever interface you plan on building. Then you can just strip out the main process loop from something like the ‘waves’ DSP program for a start at the synth programming.

I don’t mean to be discouraging, but it’s likely not the easiest beginners project if you don’t have much experience with embedded processors. The abovementioned Discovery Board is a good start to get into embedded programming, then after familiarizing yourself, you should be able to expand and connect it to your BF dev board.

#3

Thanks for you reply. I don’t wanna end up frustrated and unsatisfied, so makes perfect sense! Last thing: do you have any pointers to resources on how such a communication protocol is normally established? thank you!

#4

The best resource I can point you to is the aleph codebase. It provides an example of how Ezra hooked it up, but I don’t know personally much about it. It’s an SPI connection between the two chips.

#5

its doable but you would have to learn a bit more about the hardware on your own. the combination you describe is very similar to what we used to prototype.

there are different devkits. if you mean this one
http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/bf537-ezlite.html#eb-overview

then that is pretty close, it has the same amount of SDRAM, but you will have to write your own code for audio I/O using AD1871 (ADC) and AD1854 (DAC) instead of AD1939 (codec.) SPI init code and slave boot should be pretty easy/similar. not sure about SDRAM and clock init code, but there are plenty of bf537 sample applications if you search for them. most are written for the VisualDSP compiler suite but blackfin.uclinux.org has tips for porting to the bfin-gcc toolchain. (in fact IIRC there is generally more sample code for bf537 than for bf533.)

hm, you would also be missing half the audio I/O channels and all the CV output. getting the audio daughterboard would solve that.

the avr32 side might actually be more difficult as there is more hardware-specific stuff for all the peripherals. you would have to build out the screen, encoders, CV input, serial I/O and probably other stuff - for example, i can’t remember if any of atmel’s devkits have that much SRAM, or if any have both a USB device and a host port.

application code (e.g. bees, prgrm) is actually quite portable, just doesn’t do much without the low-level stuff provided by aleph avr32_lib (timers, CV in, screen, usb drivers, filesystem, SPI drivers, etc)

so i dunno, maybe that sounds like a good time to you, maybe not! or maybe just focus on the DSP part and follow the (very simple) param change / boot sequence serial protocol, for aleph compatiblity. (this is another way of phrasing trent’s suggestion. i too like the STMF32 discovery board, although i’ve run into a surprising number of bugs in the the STM peripheral libraries. if you’re developing your own control application you could use any microcontroller powerful enough for your needs.)

EDIT oh, just clicked the link. that looks nice! cheap and minimal with easy access to pins. but the same caveat applies as far has having to source quite a few other parts to get a working controller section together. and you would definitely need to add SRAM and configure the driver for it, which i found to be relatively tricky. bonus of that board vs. an atmel devkit is that it looks relatively easy to have a totally arbitrary pin configuration (thus, you could closely match the aleph board), the downside is you have to add pretty much everything yourself. which would be expensive and time consuming but certainly educational.

2 Likes
#6

Thanks for answering, great information.
so yes I have the bf537 EZLite that you link. in the beginning I won’t try to completely replicate the Aleph’ functionality. I was thinking more of building say a wavetable synth with effects: this would allow me to get the required experience to better understand the source code and the architecture of the Aleph. So the missing features, like CV and more limited audio I/O are not a problem for now.

Of course, it’s on the low level stuff that I will be slower. I checked the application code and I can follow it: drivers, screen, etc I don’t.

From the same vendor I have now found this one
http://www.alvidi.de/shop/product_info.php?info=p32_AVR32-Development-Board.html
That also looks quite promising: there are way more peripherals.

So now I have another question: I think I am set on one of these two. Shall I get the more complete one? There’s the option to have a AT45DB321D Data Flash installed, I guess I should go for it, no?

It would be so cool to have another practitioner working with me with the same setup: if anybody from the forum wants to join on, everything it’s going to be easier and nicer.

#7

hm actually this other board i don’t think does a lot for you as far as approximating the aleph. it comes with SDRAM instead of SRAM, so the heap memory is much bigger and slower. RS232 port would still needs conversion to serial-usb (aleph uses a slaved AVR8 running LUFA for this; older monome devices used FTDI.) ethernet would go unused (unless networking is part of your vision.)

we don’t use any extra flash in the aleph beyond the internal 512k. (bees app stores everything on the sdcard - in hindsight more flash would probably have been a good idea; as it is we should at some point redo the scenes structuring to be more space-efficient and store the default scene+module internally.)

so my 2 cents would be: if you want to use avr32 go with the barebones version and build on it from there.

or maybe you have something else lying around that could serve as an initial testing controller. for example, an Arduino Uno would work fine - it has USB host capabilities and SPI, and is easy to program.

#8

ok, well last night I was thinking wether it was ok to use Arduino Uno. so, cool, for now I’m sorted! Will start try to get SPI working already today

#9

yeah i think that would be perfect - see if you can boot the bfin in SPI slave mode by sending .ldr file from the Uno, then send parameter changes once its booted.

pins used:

SPI

  • clock
  • select
  • MOSI
  • MISO

GPIO

#10

That’s such great info. There’s a rotary switch on the EZ-KIT that determines the boot mode of the processor.
The loader file to blink a led on the dev kit is 15 Kb, before I can even send a .ldr with SPI I’ll need some sort of storage or file system on the Arduino Uno (I had thought to save it as a literal char[] at least for a first try).
So now I am checking out flash.c and so on, as soon as I have something working I’ll write a follow up, maybe someone is interested.

#11

oh dear, i’m very sorry but i was totally thinking of the Due when i made those statements
https://www.arduino.cc/en/Main/arduinoBoardDue

that is the much bigger and faster ARM-based board with 512K of flash and USB host capabilites. it is actually more capable than the uc3a0512 and easier to work with. we even made an official monome host library [ https://github.com/monome/MonomeHost ], so it can talk to serialosc devices.

the Uno only has 32k of flash, runs at half the clock speed of the uc3a0512, and provides minimal I/O. blackfin executables can be up to 64K (and it’s not hard to hit that if you are using, say, static wavetables). so the Uno (sans external storage) will only work for the most basic test application. which could still be fine for starters.

#12

heh, yeah I think I can make it with the UNO, but that means keeping both bfin and SD card on the same SPI… and, I’ll need to read the “ldf” files from the SD in chunks, select the blackfin, send the data, select the sd card, all this in a loop because the memory is too small to keep the whole file. I will move to the Due after the holidays, even though dealing with Uno’s limitations has been quite instructional today.

#13

curious if you had any success with [quote=“alesaccoia, post:6, topic:818”]
building say a wavetable synth with effects
[/quote]
on the bf537 EZLite kit ?
@alesaccoia

#14

@mike actually I had started and then I got stuck in another project and never continued. I understood the architecture though, and I can attach say an Arduino to the SPI and have the EZ-KIT booting from there… that basically replicates what happens when changing program on the aleph. in the end it was all really instructional even if I stopped at some point! do you have something in mind, or want to collaborate?

#15

@alesaccoia @zebra
I would be interested in collaboration but Im afraid that my skill are probably to newbie at the moment. I was interested in working on a device that would be able to creative very flush FM sounds that have shimmering effects I feel when I listen to indian music. At the moment Im trying to educate myself thru PD on the properties of how to create these sounds. I very interested in the sounds produced but the buchla 700 and believe that it was written in C. Also I did see a BF533 EZ Kit on ebay for 50bucks. I dunno if this interests you…

#16

Good deal on the bf533 kit. Don’t need one myself, heh… In fact I gave one away to Scott Harvestman recently, maybe we’ll see more bf533 eurorack soon…

700 was all assembly. I believe I saw someone at Georgia tech had posted the disassembled code recently… If you wanna look. But that’s just control section. Voices were analog.

FM synths… One can only go so far, naively, in digital domain. Waves module is fun. Working on more efficiency == more voices. Getting there

Time is the weapon

2 Likes
#17

wow more voices on aleph would be amazing ! I cant code ( yet ) but can help if other ways if you think of anything. Interesting to know that the voices were analog on the 700. There is a recording I found on the internet some release party for it in a sake factory ? and it sounded soooooooo good !

#18

@mike , yeah I would say that from PD to the bf533 kit it’s gonna be quite a journey :smile:
I will try to get back on this because it’s really interesting. but, get in touch if you need

ps: vintagesynth.com says “The 700 had 12 voices with 4 digital oscillators per voice (48 oscillators!), capable of a wide range of sonic creation including FM, waveshape interpolation and timbre modulation. Filters, modifiers and amps are all still in the analog domain.”

pps @zebra I don’t get notifications to posts even though I have “Send me an email when someone quotes me, replies to my post” active, weird

#19

found the notifications now, no worries : - )

#20

First time I’ve ever read about the Buchla 700. Did a Youtube search. It sounds amazing for any year, but for 1987? Wow. I can absolutely understand wanting to revise/relive that experience.

1 Like