LeafLabs Garden

A place to share, learn, and grow...

1. 

   soundcyst
   Member

   from a few things i've read, i've gotten the impression that you guys aren't really fans of ST's StdPeriph libraries, but they also have a USB library (that'd i'd guess you're probably not using?)

   i've been admittedly lazy in diving into the maple codebase, but has any thought been given to turning the board into different usb class devices? like for audio or video? or a mass storage with special features (drobo in pants?)?

   i haven't really toyed around much with changing the usb device on the fly (probably isn't the best idea?), but it would be really cool if there were an easy way to make it into a class-compliant programmable audio interface.. or a class-compliant midi device.. driverless arduinome type deal..

   does this seem interesting to anyone else?

   Posted 5 years ago #
2. 

   gbulmer
   Moderator

   I am very interested in a few USB device classes, but I need to focus on a different Maple area first (couple of months, minimum).

   When I do get back to it, my USB interests are mostly about 'driverless' (i.e. pre-installed host-OS driver supported) devices.
   My plan is to focus on a few Open Source USB projects, like LUFA.

   What are you focused on, and what are your timescales?

   Posted 5 years ago #
3. 

   soundcyst
   Member

   yeah, driverless is really the key here, and it's my main interest in using MIDI over OSC. OSC's more friendly, for sure, but you'll most likely need middleware to use it with anything other than pd, max/msp, vdmx, or faw circle.

   i've been toying with the ST library on an STM3210E-EVAL board using IAR for the day.. got their HID example to compile and function properly, and got their AudioSpeaker example compiled.. my computer sees that there's another sound device, but it won't actually send sound to it, so i'm a bit stumped ((oh /this/ is why you don't like ST's stuff, huh? ;))

   my timescale is variable. i'm lucky enough to be developing on an STM32 for work, so i'm basically getting paid to gain XP with the chip. i'm entirely new to USB though, and while investigating it is encouraged by my boss, it's extracurricular nonetheless. so, developing this sits between work, making music, making music apps, and non-computer non-music extracurriculars.

   my personal focus (if you haven't already gathered) is music devices and controllers. i'm full of pipe-dreamy kinda stuff (i.e. what if your computer saw your MPC1000 as an audio interface in addition to a regular old mass storage device, so you could run your programs and sequences straight into your daw without more than just a usb cable?).. or an open source modular sound card.. once the link to the computer is handled, it's basically BYO-converters, preamp, and analog out stage...

   not to mention the possibilities of using the maple as the brain of a standalone sampler or synth...

   Posted 5 years ago #
4. 

   poslathian
   LeafLabs

   Hey, this thread deserves a long answer since we have thought about this problem a lot. It has always been our intention to get more than just the SerialUSB out of the USB. That is the primary reason why we decided not to put an FTDI chip onboard, since we thought using the stm32 USB in various configurations would be a prime feature for the board. However, USB development is hard - and so getting libraries out to drive HID or Mass Storage etc. have been idling near the middle of the pile. It is coming though!

   LUFA! Yes! MyUSB (now LUFA) is a great library, and very well written. We spoke to the author (great guy, username: abcminiuser on #avr at freenode IRC) and discussed a little bit about how to port LUFA on to the stm32. At the time another guy in the community was working on it, so we stepped aside - but I dont know the status of his efforts. Ive looked through the code extensively, and it is definitely portable to stm32 - requiring only that we write our own low level USB driver and ctrl-endpoint stack (we currently use a modified stdUSB library from ST). We have to do this anyway for various reasons so you can expect better usb support soon.

   Posted 5 years ago #
5. 

   gbulmer
   Moderator

   poslathian - very helpful response.

   My choice of chip is driven by:
   1. Reasonable ADC & DAC (midfi audio at low-cost)
   2. Open Source tool chain
   3. On board USB with plenty of endpoints.

   So, I didn't want an FTDI chip on board :-) I want to be able to make a range of USB devices from the same hardware.
   I've 'spoken' to Dean, and he gave me some good ideas.

   I seriously considered Atmel ATmega with USB, mostly because of LUFA and the Arduino IDE, but ATmega fails at 1.
   Almost NXP, but STM32F seems much better at 1 (1msps vs 200ksps)
   Atmel AVR32 a bit new (though I have development kits, and they are very nice chips).

   I am starting to refocus on Maple/STM32F (a big part of my September goals was completed earlier this week).
   Maybe we could discuss USB and try to help each other once you guys have recovered from Maker-fair-fever?

   Posted 5 years ago #
6. 

   poslathian
   LeafLabs

   That would be stellar. Lets come back to this for sure.

   Posted 5 years ago #
7. 

   tesseract
   Member

   I am looking at the stm32 for an upcoming project and have been underwhelmed with the ST driver libraries. I was looking into porting LUFA and I see from this thread that this has been contemplated - or maybe even started? - previously. Is there any porting effort started that I could help out with? Or would someone care to outline the discussion with Dean about how it might be accomplished?

   Posted 5 years ago #
8. 

   gbulmer
   Moderator

   I haven't started on a LUFA port. I am still futzing with the robot (my colleague is thinking of doing another event in November!).

   I asked Dean if he knew of anyone porting LUFA to STM32F (last week) and he said not that he knew of.

   He also said he was going to work on refactoring the low-level, LUFA code; especially around end-points.
   Dean said he's a bit busy at the moment, but plans to do that work when he does his 32-bit port.
   So it would be worth discussing with Dean how he would like to move forward, and see if we can help each other.

   Hopefully, when LeafLabs have 0.0.7 released (expected near this weekend), they will return to this thread to talk.
   My priority is to make the bootloader driverless, then move onto other USB devices. I'd like a few (i.e. HID, Mass storage, ...)

   Posted 5 years ago #
9. 

   structuresound
   Member

   Wondering if anyone has touched this topic recently?

   Looks like Dean is headed to Norway to hang with Atmel so I'm guessing he won't be delivering LUFA to STM land anytime really soon.

   I have a couple versions of the USB midi class descriptors kicking around and would love to hard-code it in, but I'm not quite sure what else has to be done other than hacking the char tables to get the maple to enumerate as anything other than vcom.

   plus I mostly never have any real idea what I'm doing when it comes to low level coding so I'm hoping someone else has had a go of it.

   Posted 5 years ago #
10. 

    poslathian
    LeafLabs

    if someone wants to work on this, well help support the effort - its just not at the top of the stack at this exact moment. But with strong interest it could be. One of the things weve been wanting to do in future Maple revisions/other boards is to drive the usb port of a completely separate (and smaller and cheaper) stm32 like what arduino UNO has done by adding an avr-usb to drive the port. With this approach, a LUFA port would be very handy.

    Posted 5 years ago #
11. 

    soundcyst
    Member

    i've been quietly reading into this more, and i haven't gotten too far.

    i'm not really convinced that adding another stm32 will solve the problem, unless there are two usb ports -- one for programming, and one for running the midi device. instead, it seems like it just pushes the problem upstream.

    if i'm understanding the bootloader correctly, the maple actually appears as one type of usb device during the programming window, then turns itself into a different type of device for serial comms.

    basically, for a midi device to happen, we need a setupUSB() function that sets up the device as an audio class instead of cdc, which torches the ever-useful print() function.

    i've been thinking that making the computer think the maple is a hub might be a good approach, but haven't investigated it too much.

    Posted 5 years ago #
12. 

    structuresound
    Member

    Yes I'm happy to do some work on this, just am not at the programming level that someone who is helping maintain a public codebase should be at.

    @soundcyst that's about as far as I've gotten too, it seems the bootloader has a different usb headers than the base for the IDE, also it seems a call to setupUSB() would be fine, thankfully the maple folks have put in software control over usb "discovery" so it shouldn't be that hard to change the USB device in user code and leave the bootloader alone for re-programming, would just have to hit the button to stay in permanent bootloader to re-write.

    The confusing thing to me for adding new descriptors is that the maple lib seems to have it's own struct's for the desciptors rather than using the normal char table were descriptors are "daisy-chained" with a size char at the start of each set.

    Posted 5 years ago #
13. 

    gbulmer
    Moderator

    i'm not really convinced that adding another stm32 will solve the problem, unless there are two usb ports -- one for programming, and one for running the midi device.

    I think having two USB's is exactly what poslathian is describing for a future product.

    One USB correspnds to the 'existing' USB, and their would be a second USB for program loading and debugging, implemented on a second STM32F. The 'existing' USB would be available to be programmed in any way the user chooses.

    Some development boards work this way, including the new STM32F103RG board from ST.

    Posted 5 years ago #
14. 

    soundcyst
    Member

    hmm. having two cables seems less useful to me.. at that point, why not make a programmer and a device? usability is a bit taxed there too.. "why isn't my device working? oh, woops, i plugged in the wrong usb cable".. sure, using a mini and a full sized cable solves that problem, but it's still potentially confusing.

    slightly OT, i'm dying to see the 16/44 fx pedal mentioned in the blog.. and to know what codec you guys are using. =D

    Posted 5 years ago #
15. 

    metaphysician
    Member

    hi folks - newbie scott here...just thought i would add my voice to the other posts here to say i am VERY interested in being able to address the Maple from a computer as a USB class compliant device (ideally audio and MIDI). i can basically stand on the sidelines and cheer you on and test the result, but i have almost zero microcontroller experience. however in the last year, i've played with a Teensy, a Lilypad, a UBW32 and most recently, purchased a Maple rev 3.

    i can guarantee that as the user base of Maple increases, there will be those wanting or needing direct USB interaction, not just uploading programs to a standalone processor. hacking LUFA (or reworking it) sounds like the best way i know. CNMAT had been doing something supposedly allowing any microcontroller to be enumerated as an OSC device, but that's probably not sufficient in terms of audio device access.

    at any rate, one of the chief reasons i purchased it was because of the near CD quality A/D conversion, and yes, Okie's project holds a huge amount of interest for me. i would LOVE to start working on the audio DSP ability to see how hard it could be pushed into being a flexible reasonable quality modular DSP platform.

    Posted 5 years ago #

RSS feed for this topic

Reply »

You must log in to post.