Nothing that can be done quickly, indeed an XMOS solution is 95% software. Next step will be to test with external ADC/DAC (easy to do, but the integration results are gating), then add SPI to I2S conversion in a tile (library is available), integrate with a SAR ADC, followed by fine tuning and finally testing. Works fine after, I'm in the process of testing the analog part. It turned out that a compilation flag (or a #define) needs to be added in order to make the firmware compatible with the Window native UAC2. It worked fine, after recompiling, with the Thesycon evaluation driver, though. However, as soon as the firmware was recompiled and loaded, UAC2 driver on windows will no longer play with the board. The XMOS mulitichannel board worked fine, out of the box with both the Windows 10, Ubuntu Linux, OS X, either with the native UAC2 drivers or with the Windows Thesycon evaluation drivers (with anything t Windows, the DFU works ok as well). Not sure if a rp4 has enough horsepower to do all the analyzer stuff that a PC can, but an OMAP certainly can, and in an elegant way.įinally, after a week of reading the UAC2 specification and the XMOS code, some progress. What I find exciting about the OMAP is that any eventually needed DSP functionality (filtering, FFT, etc) can be conveniently moved in, leaving the whole PC, Windows, UAC2, USB endpoints, etc. I have zero experience with the STM32, I’ll take a look. Even embedded programming is today much more flexible than this thing, and has a clear programming model.Įnough ranting for today, back to ruffling some high end audiophile feathers, it’s much more fun. Other than C language and knowledge of the USB and audio transport specs, it doesn’t seem they have much of transferable skills after spending some years at xmos. I wonder what are these xmos software guys writing in their resumes. Read the description of a nightmare straight from an xmos engineer (mon2) USB Audio 2.0 Stereo Driver for Windows 10 Update - XCore Exchange Try to change the VID and PID and the UAC2 driver bombs, and this is expected behavior, nonetheless, the xmos thesycon driver works fine within the trial limitation. Writing Linux drivers for a piece of custom hardware is a piece of cake compared to this monstrosity, if nothing else, at least I have printk() to write log files. Try to find a well documented way to put the DFU bootloader on the chip. I guess I’m not used with low level monolithic software written from ground up, without any layered structure, no OS services (at least a standard RTOS, not necessary Linux) no memory management services, in general no service that I have ever used exist, not a chance to reuse any code backward and forward. I can’t even find a way to program a new firmware, there is no DFU driver for Windows, requires the xmos Thesycon drivers (which in turn somehow overrides UAC2, and its trial only, time bombing after one hour), even if win 10 supports UAC2.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |