OK, so the other IDE tools are fully portable between Linux, Windows and other operating systems?
Except Eclipse, I don't know the others IDE.
I think yes....
The compatibility issues are with the STM32 tools from STM32 Cube.
ST provides a tool to configure the STM32 (mainly the IO ports) and generate source code.
This tool is mainly designed for windows and not linux.
This is the same with the ST eclipse plugin : does not work under Linux.
So... This a choice: STM32 performance but learning curve to develop on it or Arduino : easy to develop, but low performances
Update time
Power supply + power management done. I've switched RPI/DSP connection to SPI, the same SPI is used for USBi connection and front panel LCD connection - this will save me some board estate. I connected two DSP GPIO to DSP, because why not..
. One of GPIO is routed to power management, so when you push on/of button the DSP can mute outputs.
Well my original idea about slightly expanding the design + sorting out bugs was quite naive - it feels like I'm just doing the board all over again
@Mjjg - OK
Power supply + power management done. I've switched RPI/DSP connection to SPI, the same SPI is used for USBi connection and front panel LCD connection - this will save me some board estate. I connected two DSP GPIO to DSP, because why not..
. One of GPIO is routed to power management, so when you push on/of button the DSP can mute outputs. Well my original idea about slightly expanding the design + sorting out bugs was quite naive - it feels like I'm just doing the board all over again
@Mjjg - OK
I think the discusion in
http://www.diyaudio.com/forums/digi...re-detect-0dbfs-waveforms-overload-times.html
is relevant if upsampling and AD upsampling IP is involved.
The input signal should be attunated -3 to -6 dB to avoid intersample distortion generated by most modern music recordings.
You can test any artifacts with signals enclosed in linked post.
http://www.diyaudio.com/forums/digi...re-detect-0dbfs-waveforms-overload-times.html
is relevant if upsampling and AD upsampling IP is involved.
The input signal should be attunated -3 to -6 dB to avoid intersample distortion generated by most modern music recordings.
You can test any artifacts with signals enclosed in linked post.
For easy ARM development, I forgot to mention the "mbed" platform. This includes an "in browser" IDE, and an open source, cross platform library which is (more or less) as easy to use as Arduino, and a whole bunch of supported hardware platforms. If you're not doing anything too complicated then the online IDE will probably work fine. It should be noted that you're not "locked in" to the online IDE - you can just download the libraries and toolchain to use offline if you wish.
More information here: https://developer.mbed.org/explore/
Sorry for the late reply, I've had a lot on my plate these last few days. The source is here, though I guess you've found it yourself by now
The documentation seems a bit outdated, given that some structs described in the docs don't seem to match what is in the code. But I'm slowly starting to get it. It actually seems quite easy to develop a driver, once you get the hang of how the API works.
Not dead
Hi,
just to let you guys know I'm not dead, and I'm slowly getting there.
Still some routing left. I've managed to squeeze it into 10cmx10cm.
Bottom-right connector is for USBi programmer, bottom-left are GPIO,adc,power management, i2c from RPI(for lcd) - front panel connector.
Hi,
just to let you guys know I'm not dead, and I'm slowly getting there.
Still some routing left. I've managed to squeeze it into 10cmx10cm
.Bottom-right connector is for USBi programmer, bottom-left are GPIO,adc,power management, i2c from RPI(for lcd) - front panel connector.
Attachments
hey nice job !!! it looks fantastic ��
I can see a couple of u.fl surface connectors, maybe for an external master clock?.
What do you use for the design ? (eagle,etc). I find really difficult to route the ADAU1701, cannot imagine what is like to route the 1452 with so many pins
cheers
Pepe
I can see a couple of u.fl surface connectors, maybe for an external master clock?.
What do you use for the design ? (eagle,etc). I find really difficult to route the ADAU1701, cannot imagine what is like to route the 1452 with so many pins
cheers
Pepe
I've looked through the HifiBerry DAC driver, set up the toolchain and done some test compiling. I getting ready to implement a driver now, which brings us to a question, namely what do we want to achieve with this driver? Let's state some use cases.
1. DSP board with one fixed clock. R-Pi connected to one of the I2S lines as a music source. The R-Pi resamples to whatever fixed frequency we've set. This is the simplest, out-of-the-box case. The Linux driver can be very simple, basically setting the R-Pi in slave mode. It might be that there is already a generic I2S driver that does this for us.
2. DSP board with two clocks for 44.1/48kHz and integer upsampling. The DSP works at one of two fixed clock frequencies, and the R-Pi does integer upsampling to this frequency. The R-Pi is the sole audio source that needs different clocks (other I2S inputs connected to ADCs or such). Some part of the firmware now has to control which clock is used and reprogram the DSP accordingly. This control can be either in the sound driver, in a program running in user space or on a separate uC. DACs might need programing too.
3. Same as 2 but without resampling. The control software now has to set the clock dividers in the DSP to match the wanted frequency. The R-Pi has to signal wanted clock frequency, not just which clock base to use. Only slight change with respect to 2, so not so much extra work. DSP needs more sets of parameters, one for each supported frequency.
4. Multiple digital inputs with individual clock frequency needs. The software now has to communicate with and identify the different inputs and control input selection of DSP. Each input communicates wanted frequency over I2C, and if it is the active input, the firmware changes to this clock. Unused/dumb input will not reply to a query and will be given a predetermined frequency.
Please fill in with whatever you feel is missing.
Case 1 is the bare minimum we want to achieve, and is pretty much already there I guess. It is generic, and works out of the box.
The other cases are more tricky and will probably require some hands-on for the individual DIYer, depending on his/her input/output setup etc. We probably won't be able to decide on a commomnd setup here, so what we can realistically do is to make sure there is the possibility to extend the DSP board with these functions in one or more ways.
It is my opinion that clock management should not be part of the sound driver, because that would only really work if the R-Pi is the sole source. So either it runs in user space or on a separate uC, both can be implemented just as easy, henceforth called the Controller. What is needed from the DSP board is the following:
1. Possibility to connect the controller to the I2C bus
2. (optional but nice) Possibility to connect the DSP master control bus (now SPI?) to the controller or external EEPROM board.
3. Possibility to control I2C addresses of all connected device so that inputs can be identified as 1-4 or some similar range. I have little experience with I2C but as I understand it, the lower few bits can usually be set. Optionally we would simply have to hardcode the addresses of the inputs in the controller.
Given how these advanced use cases needs some hands on, I would go for an Arduino compatible uC.
1. DSP board with one fixed clock. R-Pi connected to one of the I2S lines as a music source. The R-Pi resamples to whatever fixed frequency we've set. This is the simplest, out-of-the-box case. The Linux driver can be very simple, basically setting the R-Pi in slave mode. It might be that there is already a generic I2S driver that does this for us.
2. DSP board with two clocks for 44.1/48kHz and integer upsampling. The DSP works at one of two fixed clock frequencies, and the R-Pi does integer upsampling to this frequency. The R-Pi is the sole audio source that needs different clocks (other I2S inputs connected to ADCs or such). Some part of the firmware now has to control which clock is used and reprogram the DSP accordingly. This control can be either in the sound driver, in a program running in user space or on a separate uC. DACs might need programing too.
3. Same as 2 but without resampling. The control software now has to set the clock dividers in the DSP to match the wanted frequency. The R-Pi has to signal wanted clock frequency, not just which clock base to use. Only slight change with respect to 2, so not so much extra work. DSP needs more sets of parameters, one for each supported frequency.
4. Multiple digital inputs with individual clock frequency needs. The software now has to communicate with and identify the different inputs and control input selection of DSP. Each input communicates wanted frequency over I2C, and if it is the active input, the firmware changes to this clock. Unused/dumb input will not reply to a query and will be given a predetermined frequency.
Please fill in with whatever you feel is missing.
Case 1 is the bare minimum we want to achieve, and is pretty much already there I guess. It is generic, and works out of the box.
The other cases are more tricky and will probably require some hands-on for the individual DIYer, depending on his/her input/output setup etc. We probably won't be able to decide on a commomnd setup here, so what we can realistically do is to make sure there is the possibility to extend the DSP board with these functions in one or more ways.
It is my opinion that clock management should not be part of the sound driver, because that would only really work if the R-Pi is the sole source. So either it runs in user space or on a separate uC, both can be implemented just as easy, henceforth called the Controller. What is needed from the DSP board is the following:
1. Possibility to connect the controller to the I2C bus
2. (optional but nice) Possibility to connect the DSP master control bus (now SPI?) to the controller or external EEPROM board.
3. Possibility to control I2C addresses of all connected device so that inputs can be identified as 1-4 or some similar range. I have little experience with I2C but as I understand it, the lower few bits can usually be set. Optionally we would simply have to hardcode the addresses of the inputs in the controller.
Given how these advanced use cases needs some hands on, I would go for an Arduino compatible uC.
I've looked through the HifiBerry DAC driver, set up the toolchain and done some test compiling. I getting ready to implement a driver now, which brings us to a question, namely what do we want to achieve with this driver? Let's state some use cases.
1. DSP board with one fixed clock. R-Pi connected to one of the I2S lines as a music source. The R-Pi resamples to whatever fixed frequency we've set. This is the simplest, out-of-the-box case. The Linux driver can be very simple, basically setting the R-Pi in slave mode. It might be that there is already a generic I2S driver that does this for us.
2. DSP board with two clocks for 44.1/48kHz and integer upsampling. The DSP works at one of two fixed clock frequencies, and the R-Pi does integer upsampling to this frequency. The R-Pi is the sole audio source that needs different clocks (other I2S inputs connected to ADCs or such). Some part of the firmware now has to control which clock is used and reprogram the DSP accordingly. This control can be either in the sound driver, in a program running in user space or on a separate uC. DACs might need programing too.
3. Same as 2 but without resampling. The control software now has to set the clock dividers in the DSP to match the wanted frequency. The R-Pi has to signal wanted clock frequency, not just which clock base to use. Only slight change with respect to 2, so not so much extra work. DSP needs more sets of parameters, one for each supported frequency.
4. Multiple digital inputs with individual clock frequency needs. The software now has to communicate with and identify the different inputs and control input selection of DSP. Each input communicates wanted frequency over I2C, and if it is the active input, the firmware changes to this clock. Unused/dumb input will not reply to a query and will be given a predetermined frequency.
Please fill in with whatever you feel is missing.
Case 1 is the bare minimum we want to achieve, and is pretty much already there I guess. It is generic, and works out of the box.
The other cases are more tricky and will probably require some hands-on for the individual DIYer, depending on his/her input/output setup etc. We probably won't be able to decide on a commomnd setup here, so what we can realistically do is to make sure there is the possibility to extend the DSP board with these functions in one or more ways.
It is my opinion that clock management should not be part of the sound driver, because that would only really work if the R-Pi is the sole source. So either it runs in user space or on a separate uC, both can be implemented just as easy, henceforth called the Controller. What is needed from the DSP board is the following:
1. Possibility to connect the controller to the I2C bus
2. (optional but nice) Possibility to connect the DSP master control bus (now SPI?) to the controller or external EEPROM board.
3. Possibility to control I2C addresses of all connected device so that inputs can be identified as 1-4 or some similar range. I have little experience with I2C but as I understand it, the lower few bits can usually be set. Optionally we would simply have to hardcode the addresses of the inputs in the controller.
Given how these advanced use cases needs some hands on, I would go for an Arduino compatible uC.
Hi,
many thanks for your progress...
I had a quick a read on the Linux drivers as well,
1/ With regards to the source source code, not sure if the the RPI is in slave mode, there is no resample. I didn't have time to have a look on the impact of the RPI clock on the Interrput system. I think this is a point to investigate or... maybe faster/better way to measure the output with a Hifiberry DAC+ Pro driver working. It may be a blocking point.
2/ with RPI in master mode, I think the best is to play at x48khz frequencies, having a software resample by player before. player algorithms for resampling are far better than the average centric RPI interrupt system.
=> To continue on this way, I suggest to plan a talk.
Hi,
many thanks for the link! I already had a look on the web site, but the access to the online ide was broken...
Well,.... For me is not a final IDE. somewhere I can read "beta test" or "technology preview"....
I didn't see any "legal" agreements... but I can be wrong on this point.
To be honest, I really prefer the eclipse way... Which has a big communauty or cloud
and has definitely a better support and improvements, and a clear legal contract.I recently downloaded the new features for STM32 and I have to code a test.
What is sure is the new upgrades look good. Not as good as I would like, but good to start a solid, learning (for people who want), and opensource project.
Pitrsek, the new board looks great, very much like I want it to be! Thanks for including the USBi header!
I prefer this one, it follows KISS principles. Having the RPi in slave mode is the most important thing to achieve. The rest adds a lot of complexity for little real benefit.
There is also a slight alternative to 2 (2b?), where there are two clocks for the RPi interface, but the ASRC in the DSP does the resampling to a fixed clock for the processing. The ASRC in the DSP is the same as the well known AD1896.
Being a DSP developer by trade, I know what a hassle it is to have a DSP that needs to support different sampling frequencies that can change arbitrarily. Like it's been said earlier, you can change the filter coefficients when that happens, but keeping that nicely in sync with the changing samplerate without experiencing dropouts or artifacts in the audio is really tricky.
I prefer this one, it follows KISS principles. Having the RPi in slave mode is the most important thing to achieve. The rest adds a lot of complexity for little real benefit.
There is also a slight alternative to 2 (2b?), where there are two clocks for the RPi interface, but the ASRC in the DSP does the resampling to a fixed clock for the processing. The ASRC in the DSP is the same as the well known AD1896.
Being a DSP developer by trade, I know what a hassle it is to have a DSP that needs to support different sampling frequencies that can change arbitrarily. Like it's been said earlier, you can change the filter coefficients when that happens, but keeping that nicely in sync with the changing samplerate without experiencing dropouts or artifacts in the audio is really tricky.
Hi,
many thanks for the link! I already had a look on the web site, but the access to the online ide was broken...
Well,.... For me is not a final IDE. somewhere I can read "beta test" or "technology preview"....
I didn't see any "legal" agreements... but I can be wrong on this point.
To be honest, I really prefer the eclipse way... Which has a big communauty or cloud
I recently downloaded the new features for STM32 and I have to code a test.
What is sure is the new upgrades look good. Not as good as I would like, but good to start a solid, learning (for people who want), and opensource project.
Atollic true studio lite.
TrueSTUDIO - Atollic