Hi
in my project I use the lm3s9b92 eval kit to connect a digital microphone via I2S. Now I want to send the whole raw data from the microphone to a pc. The sample rate of the microphone is 48 kHz and every sample has a resolution of 24 bit and will be stored in a 32 bit integer variable, so I will get a total amount of 1.536 MBit/s = 192 kByte/s. This is to much to use UART for the transfer, even if I would lower the sample rate. Therefor I want to use USB but I never developed an usb application before. I thought it would make sense to use isochronous transfer mode to have a continious and correctly ordered data stream send to the host. Unfortunately I don't know where to start. Where do I have to take care and how do I read out the send data on the host?Thank you for any kind of help.,
Maker/provider of this digital microphone "pops up" as first to guide/advise. (not we MCU forum lurkers) Have you asked maker? Further - somewhat hard to believe that microphone maker/provider failed to address, "mic. to PC" connection - as this surely impacts Sales. (at very least - they should have provided Ap Note / Tech Brief...)
Moving bit, "out of the box," perhaps a commercially available, "USB to Parallel adapter," can far more easily "mate" with parallel port of LM3S9B92. (while providing acceptable data rate) Such vastly eases (and speeds) your development - and may serve to "justify/confirm" the usefulness & resulting viability of your audio project... Note that this method completely removes USB efforts/issues from your task-load...
Yes - I2S to USB may be "ideal" - but as you appear bit less than USB expert - expect long, hard development road. (and beware - deadlines!)
Finally - project "deal-breaker" may result from MCU's inability to process and output the data conversion at minimally required rate. Wise always to look for such - fails - before charging into a project...
Thank you for your reply. I think it's not a problem of the mic provider because the mic is just the source of the datastream that I want to transfer. So the transfer itself and the interaction with the host PC is the task of the MCU. Of course you're right with the long and hard road to usb but unfortunately it's a requirement of the project. Even if it isn't a high priority one.
Andre Marianovichmic is just the source of the datastream
Mon ami - Sales are greatly heightened by - Comfort - Convenience - rarely by undefined/unguided DIY. (Do It Yourself)
Provide maker, part no. of your microphone - we'll have intern staff contact - will bet "serious" maker will have encountered your issue - have suggestions...
Parallel port (easy for MCU) not to your liking?
cb1- Mon ami - Sales are greatly heightened by - Comfort - Convenience - rarely by undefined/unguided DIY. (Do It Yourself) Provide maker, part no. of your microphone - we'll have intern staff contact - will bet "serious" maker will have encountered your issue - have suggestions...
Of course you're right again ;-) So there is an evaluation kit for the mic but in fact this is not an option. The main task is to process the incoming mic data on the MUC and send the results per usb to the host. At the end of the project the MCU should work as a test and measurement usb class device. At the moment I just want to see what's the quality of the raw mic data. So finaly the code for the raw data streaming will be reused again to fulfill the project requirements. That's why I don't think it would make that much sense to use the eval kit of the mic producer, if you know what I mean.
cb1-Parallel port (easy for MCU) not to your liking?
24 Bit per parallel port would mean many wires, wouldn't it?! ;-)
Sounds more & more like school project...
Indeed 24 bits in "one transfer" is, "many wires." As alternative - 3 8 bit transfers (Stellaris currently maxes out @ 8 bit port - unless EPI)
Another perspective - you "seize" on 24 wires (stinks - I agree) but what will that take - 2-3 hours to wire/verify? I'd bet serious money your USB alternative method will not see, "light of day" for 2-3 weeks - likely longer. (and - pardon - good chance of never...)
cb1-Sounds more & more like school project...
It's a university project...but in fact it's maybe the same ;-)
cb1- I'd bet serious money your USB alternative method will not see, "light of day" for 2-3 weeks - likely longer. (and - pardon - good chance of never...)
And I bet you wouldn't not necessarily lose your wager. Theoretical I know the usb and that's why I know that it's easy to use but heavy to develop.
Hi Andre,
It's a university project
StellarisWare implements USB audio of sink (speaker), but not for source (microphone).But around 80% of the source code is still available as is, to change it into microphone. You'll need to modify the source for the rest.
Do you want to learn on USB audio with me?
My agenda is,1. Briefing on USB audio spec2. Modification - Descriptors3. Modification - class-specific requests4. Modification - isoc endpoint5. Modification - I2S
Tsuneo
@Andre - poster Tsuneo is known/well qualified - you have maneuvered into a, "gold-mine." (opinion both mine, multiple others...) You could not do better than to accept his generous offer - and do any/every thing he directs... (I'd join - if so invited - but am buried w/ M4 project currently...)
In light of this unexpected development - this reporter hereby withdraws earlier, "exploratory" wager...
At the moment I read the stellaris usb library user guide and there stands that the usb audio class only supports 16 bit stereo data stream. So how can I yet still transfer my 24 bit data stream? Is this even possible?
Someone switched to parallel - did 3 back to back 8 bit transfers - and finished project last week...
Sometimes - bending the project to "conform" to an "unnatural" application - delays & confounds...
Your learned, school advisor has what comment/reaction? (16 bit stream limit) Should not this limitation have been recognized much earlier?
there stands that the usb audio class only supports 16 bit stereo data stream.
@Tsuneo - you clearly are talented, caring guy - have helped many here.
OP's project - (did we hear?), "impaired captain - rudderless ship - uncharted course." Subsequent tacks frequent - sometimes violent - impinge strong head-wind. Such voyage "tad short" of glossy, travel ad's promise...
To get a more general overview without to much details, what would be the steps to get the data from the microphone to the host PC? I think, beside the fact of the device configuration, descriptor modification, etc., it would be the rather simple model: the mic fills a puffer (IN endpoint of the device) which the usb controller reads out to the host if the host sends a request, for example from an audio recording application using the default device driver for usb audio class devices?
Well, I don't see the forest for the trees a little bit. So here are some questions I hope you can solve:
1.) Is it right that the whole enumartion would be handled by the USBDAudioInit() function which calls the USBDCDInit() function? Because in the "ubs_dev_audio" example there seems to be no additional code that deals with any kind of usb configuration processes. Also the usb peripheral won't be enabled explicitely.
2.) In the theory of usb, the host would send the device an IN token to signal the device that it can send new data from the IN endpoint fifo of the usb controller. Will this token be handled automaticly by the usb lib or do I have to add this functionality in my firmware?
3.) What interrupts can occur that I need to handle in my firmware?
Can nobody answer my questions?