nullstring
Posts: 178
Joined: Sun Oct 02, 2011 3:05 pm

Re: Sad about removal of I2S. Why was this change made?

Mon Jan 30, 2012 10:41 pm

However, that USB to I2S isn't async. I'm not really interesting in using isosynchronous transmission over USB. USB is just too finicky for that.

@terual, a squeezebox clone is an interesting idea. It looks like the software is just written in perl and is likely to work without a hitch.

User avatar
Gert van Loo
Posts: 2486
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: Sad about removal of I2S. Why was this change made?

Mon Jan 30, 2012 10:51 pm

meltwater said:

....
Fingers crossed for a hardware hack, shall have to wait and see.

...



If you can live with a real hardware hack: As I said there is an I2S if your are willing to solder some wires to tiny resisors on the pi.

User avatar
meltwater
Posts: 1015
Joined: Tue Oct 18, 2011 11:38 am

Re: Sad about removal of I2S. Why was this change made?

Mon Jan 30, 2012 10:58 pm

Gert said:


meltwater said:


....
Fingers crossed for a hardware hack, shall have to wait and see.

...


If you can live with a real hardware hack: As I said there is an I2S if your are willing to solder some wires to tiny resisors on the pi.


Sounds like an option, might have to be a 2nd RPi though, the 1st one I get will probably be too precious.  Might be enough to please a few.
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam

Steady_Bear
Posts: 110
Joined: Sat Jan 14, 2012 12:06 pm

Re: Sad about removal of I2S. Why was this change made?

Tue Jan 31, 2012 12:16 am

meltwater said:


Gert said:


meltwater said:


....
Fingers crossed for a hardware hack, shall have to wait and see.

...


If you can live with a real hardware hack: As I said there is an I2S if your are willing to solder some wires to tiny resisors on the pi.


Sounds like an option, might have to be a 2nd RPi though, the 1st one I get will probably be too precious.  Might be enough to please a few.



Hey, come on - it's all about hacking.

Although, it would be nice if someone in the foundation with a spare board could confirm if the hack is workable or not* (nudge, nudge, wink, wink).

* I now it sounds pushy, but I really do mean 'it would be nice'. I fully understand this is not a priority at the minute, and really appreciate the work going into the Pi + additions. Hey, I'm not even planing on using the I2S.

nullstring
Posts: 178
Joined: Sun Oct 02, 2011 3:05 pm

Re: Sad about removal of I2S. Why was this change made?

Tue Jan 31, 2012 12:40 am

Gert said:


meltwater said:


….
Fingers crossed for a hardware hack, shall have to wait and see.




If you can live with a real hardware hack: As I said there is an I2S if your are willing to solder some wires to tiny resisors on the pi.


So, which resistor numbers are we looking at?

It looks like we could be talking about R15, R16, R17?

speedevil
Posts: 7
Joined: Tue Jan 24, 2012 3:27 am

Re: Sad about removal of I2S. Why was this change made?

Tue Jan 31, 2012 2:42 am

Tomo2k said:


As Gert said, this is by far the best way to do 'real' motor control.

Closed-loop control of speed and especially position simply can't* be done accurately under any 'normal' operating system like Linux or


This is one point of PWM, you can simply configure it to output 50Hz at the right pulse-width, and you can then simply connect a R/C servo, or a motor speed controller to it, and it stays at one position/speed with no CPU input.

In addition, there are realtime patches for the kernel, which would be interesting!


terual
Posts: 7
Joined: Mon Jan 30, 2012 8:10 am

Re: Sad about removal of I2S. Why was this change made?

Tue Jan 31, 2012 1:32 pm

nullstring said:

@terual, a squeezebox clone is an interesting idea. It looks like the software is just written in perl and is likely to work without a hitch.

The server software is written in perl indeed, but I want to use the R-Pi as a client. There exist a couple of options to do that, e.g. squeezeslave (http://wiki.slimdevices.com/in.....ueezeSlave), which I have already compiled for ARMv6 or squeezeplay (http://wiki.slimdevices.com/in.....queezePlay) if I get it to compile for the R-Pi.

Aquarius
Posts: 5
Joined: Thu Feb 16, 2012 9:32 am

Re: Sad about removal of I2S. Why was this change made?

Thu Feb 16, 2012 1:35 pm

Hello all,

Sorry to digg this topic from the grave...

In this topic, Eben & Lizz talk about re-adding I²S ouput pins to the header for a future revision. Is this kind of issue logged somewhere so that we can know if it is considered / remembered/ implemented ? There was no definitive answer in the thread.

Also, the quality of this I²S output will depend on the clock used. Audiophiles are always afraid of the dreaded "Jitter", a small (from a couple of picoseconds to a couple of hundreds picoseconds) degradation of the signal that lead to less-than-perfect sound. Is there a way to know what level of jitter we can expect from the RasPi ?

(note that currently, USB DACs seem the way to go with the Raspi, but an spdif out would have its advantages.)

Thank you for this great project!

nullstring
Posts: 178
Joined: Sun Oct 02, 2011 3:05 pm

Re: Sad about removal of I2S. Why was this change made?

Thu Feb 16, 2012 5:56 pm

It would be really cool if we could get a bugtracking site for the RPI.. to track issues like these.

As well as keep track of suggestions, etc.

User avatar
abishur
Posts: 4477
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
Contact: Website

Re: Sad about removal of I2S. Why was this change made?

Thu Feb 16, 2012 7:17 pm

I know that the RPF is hoping to keep things as centralized as possible for now at least.  Once the R-pi is actually released I expect things like this (bug tracking) to be addressed in order of importance   I'm not sure if that would mean a link to a dedicated bug tracking site or just a new sub-forum.  We'll have to wait and see what happens around here in the weeks following the release!
Dear forum: Play nice ;-)

error404
Posts: 351
Joined: Wed Dec 21, 2011 11:49 pm

Re: Sad about removal of I2S. Why was this change made?

Thu Feb 16, 2012 7:24 pm

Aquarius said:


Also, the quality of this I²S output will depend on the clock used. Audiophiles are always afraid of the dreaded "Jitter", a small (from a couple of picoseconds to a couple of hundreds picoseconds) degradation of the signal that lead to less-than-perfect sound. Is there a way to know what level of jitter we can expect from the RasPi ?


More generally, the whole clock generation problem is not really addressed in the datasheet – or not very clearly, anyway - there isn't even a diagram I can find of the clock domains / sources. Is there facility for PLL-generated audio clocks? From the language in the datasheet there seems to be weak inference that there is, how is this controlled?

I would not expect great jitter specifications from an internal PLL on this chip, but it appears to support external clocking, in which case it will be as good as your external clock is… which would of course make it ideal as a cheap 'audiophile' source, you could even run it from batteries easily. Alas, without the pins on the header I'm not going to bother pursuing designing such an addon, but I might do the hack myself for the SDR project I initially planned.

RAThomas
Posts: 7
Joined: Mon Feb 06, 2012 7:03 pm
Contact: Website

Re: Sad about removal of I2S. Why was this change made?

Fri Feb 24, 2012 5:21 pm

speedevil said:


Tomo2k said:


As Gert said, this is by far the best way to do 'real' motor control.

Closed-loop control of speed and especially position simply can't* be done accurately under any 'normal' operating system like Linux or


This is one point of PWM, you can simply configure it to output 50Hz at the right pulse-width, and you can then simply connect a R/C servo, or a motor speed controller to it, and it stays at one position/speed with no CPU input.

In addition, there are realtime patches for the kernel, which would be interesting!



Yeah, that's actually *the* main point of hardware PWM outputs.  Also, as an RT-patch user, I will definitely try running it with an RT patched kernel (assumes I can actually get an R-Pi).  Probably pointless for most users, though, since much of the important RT patch goodness has already been mainlined in Linux for some time now!

All of that said, I will almost certainly use my existing microcontroller based H-bridge motor drive design to interface the Pi to some wheels.

TechColab
Posts: 27
Joined: Tue Mar 06, 2012 10:27 am

Re: Sad about removal of I2S. Why was this change made?

Thu Mar 15, 2012 11:02 am

I too am very keen for I2S which in the next revision should get priority over another PWM or UART(rs232) etc. for admittedly selfish but I think justifiable reasons:

1) PWM & serial can both be done either directly in software (bit-banging) or by off-loading to a cheap micro-controller like the Teensy which has can do 3 serial, many PWM, analogue & GPIO concurrently for about USD 16.

2) The RPi has NO sound input so a solution is very desirable.  I believe that if a job is worth doing then it's worth doing properly.  The audio world is now standardised on 24-bit and 96kHz with some use of 192kHz.  It may not have filtered down to Jo Public yet but even Apple are deploying this in iTunes.  Current popular (affordable) USB audio devices are not up to this quality.  Even rare & expensive USB devices which are up to this audio quality will introduce additional latency due to the USB bus & it's controller.

Nor can I2S be easily off-loaded to a micro-controller as the cheap ones don't have I2S (not fast enough) and the ones that do would still incur the additional latency of communication between micro-controller and RPi.

I2S was specifically designed for these reasons - to get a *lot* of data in/out of the CPU with minimal latency etc.  So I2S is the *only* way to do audio as best as possible.

Appart from the great number of project ideas that are basically home entertainment, I have read of several projects that would benefit from 2 fast & accurate ADC channels:

Real-time audio collaboration across the internet *needs* low latency.

A useful oscilliscope can be made with 2 channels of 24-bit at 96kHz (192 even better).

So I completely understand that the RPi is primarily an education tool for SOFTWARE and compliments the Arduino as a tool for HARDWARE but at no extra cost, the exposure of those little I2S signals can bring the RPi to the leading edge of audio which is a subject that is also a great educational pool.

User avatar
meltwater
Posts: 1015
Joined: Tue Oct 18, 2011 11:38 am

Re: Sad about removal of I2S. Why was this change made?

Thu Mar 15, 2012 11:26 am

If you didn't spot..it wasn't really dropped on propose, just a result of a board change.  Also, there is some mention that it may be available through a little modding, but we will have to wait to see if this is possible when the boards are received.
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam

nullstring
Posts: 178
Joined: Sun Oct 02, 2011 3:05 pm

Re: Sad about removal of I2S. Why was this change made?

Thu Mar 15, 2012 2:41 pm

It's worth adding that currently we have /half/ of the I2S pins brought out to the GPIO header.

These pins are rather useless other than as regular GPIO, and therefore the only logical move is to add the missing two I2S pins in a further revision.

It's very likely this will be their move.

Neil
Posts: 98
Joined: Thu Sep 29, 2011 7:10 am
Contact: Website

Re: Sad about removal of I2S. Why was this change made?

Fri Mar 16, 2012 4:43 pm

TechColab said:

1) PWM & serial can both be done either directly in software (bit-banging) or by off-loading to a cheap micro-controller like the Teensy which has can do 3 serial, many PWM, analogue & GPIO concurrently for about USD 16.
Its not easy to do bit-banging on a Linux system unless you play nasty tricks with system locks, and it'd kill performance.


2) The RPi has NO sound input so a solution is very desirable.  I believe that if a job is worth doing then it's worth doing properly.  The audio world is now standardised on 24-bit and 96kHz with some use of 192kHz.


Low-end digital hi-fi.  High-end goes up to 384kHz, such as is possible on Audio DVDs.


It may not have filtered down to Jo Public yet but even Apple are deploying this in iTunes.


Yeay!  Compress the hell out of music, then play it through a cheap "24-bit" converter on cheap hardware through cheap headphones.

Current popular (affordable) USB audio devices are not up to this quality.  Even rare & expensive USB devices which are up to this audio quality will introduce additional latency due to the USB bus & it's controller.
I guess you only care about latency for encode/decode applications like VoIP.  And if you really care about latency, you won't be using a RasPi.


Nor can I2S be easily off-loaded to a micro-controller as the cheap ones don't have I2S (not fast enough) and the ones that do would still incur the additional latency of communication between micro-controller and RPi.

I2S was specifically designed for these reasons - to get a *lot* of data in/out of the CPU with minimal latency etc.  So I2S is the *only* way to do audio as best as possible.


And cheaply.  Although by the time you've added all the hardware necessary to get true 24-bit performance its no longer low cost.


Appart from the great number of project ideas that are basically home entertainment, I have read of several projects that would benefit from 2 fast & accurate ADC channels:

Real-time audio collaboration across the internet *needs* low latency.


You mean Skype?


A useful oscilliscope can be made with 2 channels of 24-bit at 96kHz (192 even better).


Ha ha ha ha ha ha ha *breathe* ha ha ha ha ha *gasp* ha ha ha...

I guess if you restrict yourself to signals in the audio range, don't need fancy triggering features, have implemented a decent front-end preamp/attenuator to protect the codec from damage, etc, and all to a level of detail that supports the use of a 24-bit converter, then yes.  Otherwise you'd end up with something like the Seeed DSO:

http://www.seeedstudio.com/dep.....?cPath=174

with its 12-bit 1Ms/s converter.

An audio analyser might be a better application, although again to get any useful results the hardware needs to be designed very carefully to minimise noise and distortion.  To give you an example, probably the best audio analyser kit currently on the market is only good to 18 bits, and that costs about 1,000 RasPis (Audio Precision 2700 series, -112dB THD+N at 22kHz BW).


So I completely understand that the RPi is primarily an education tool for SOFTWARE and compliments the Arduino as a tool for HARDWARE but at no extra cost, the exposure of those little I2S signals can bring the RPi to the leading edge of audio which is a subject that is also a great educational pool.


If you want access to leading-edge audio (whatever that is) an external audio USB interface (of which there are many) would be far better than a low-grade on-board audio codec.  If you're going to pay for a 24-bit converter, don't you think it makes sense to try and use as many of those bits as you can?

TechColab
Posts: 27
Joined: Tue Mar 06, 2012 10:27 am

Re: Sad about removal of I2S. Why was this change made?

Sun Mar 18, 2012 4:36 pm

~Neil~ said:

Its not easy to do bit-banging on a Linux system unless you play nasty tricks with system locks, and it'd kill performance.
I'd definitely go micro-controller over bit-banging but it's got to be easier at PWM/rs232 speeds than I2S speeds.  You could call it an opportunity for educating in software techniques 

Low-end digital hi-fi.  High-end goes up to 384kHz, such as is possible on Audio DVDs.
Personally I'm happy to call 24/96 good enough for me.  My ears wouldn't benefit from 384kHz and I'd reserve the "Low-end" label for 16/44.1

Yeay!  Compress the hell out of music, then play it through a cheap "24-bit" converter on cheap hardware through cheap headphones.
The iPod is a great way of having a lot of music on the move. But I use my home system which wasn't particularly cheap so I'd appreciate the benefit that 24-bit support in iTunes brings - I.e. improved dynamic range (when the producers wake up).

I guess you only care about latency for encode/decode applications like VoIP.  And if you really care about latency, you won't be using a RasPi.  You mean Skype?
I think normal conversations can tolerate a surprisingly low quality connection - look at the phone system.  So I wouldn't say Skype or other VoIP systems suffer too badly.  There's an interesting paragraph about latency here http://www.musicianlink.com/co.....amlink/faq
Google for "site:raspberrypi.org jamlink" to see the forum post that I was referring to.  Also "site:raspberrypi.org Guitar amp modelling"

Ha ha ha ha ha ha ha *breathe* ha ha ha ha ha *gasp* ha ha ha...

I guess if you restrict yourself to signals in the audio range, don't need fancy triggering features, have implemented a decent front-end preamp/attenuator to protect the codec from damage, etc, and all to a level of detail that supports the use of a 24-bit converter, then yes.  Otherwise you'd end up with something like the Seeed DSO:

http://www.seeedstudio.com/dep.....?cPath=174

with its 12-bit 1Ms/s converter.

An audio analyser might be a better application, although again to get any useful results the hardware needs to be designed very carefully to minimise noise and distortion.  To give you an example, probably the best audio analyser kit currently on the market is only good to 18 bits, and that costs about 1,000 RasPis (Audio Precision 2700 series, -112dB THD+N at 22kHz BW).


I find a multi-meter to be very useful and I'm happy to concede that RF projects are beyond my skill levels.  The fact that there are commercial products like the DSO Nano seems to imply that I'm not alone. I doubt many home hobbyists could afford (or need) the audio analyser you mentioned.
Google for "site:raspberrypi.org oscilloscope" to see the forum post that I was referring to.

If you want access to leading-edge audio (whatever that is) an external audio USB interface (of which there are many) would be far better than a low-grade on-board audio codec.  If you're going to pay for a 24-bit converter, don't you think it makes sense to try and use as many of those bits as you can?
Google for "site:raspberrypi.org wolfson" to see some of the forum posts that discuss the use of well reputed audio chips which are far from low-grade.
I don't see how moving a 24-bit ADC/DAC to an external box at the end of a USB cable makes those 24-bits any better.  And it misses the point about latency.

Besides, where is the educational value in just buying a ready made product?
If you were to open a comparable USB audio device you'd find some analogue stuff, some power stuff, USB stuff, ADC, DAC, micro-controller and perhaps some memory.  Most of which is in the RPi so how can a comparable design based on the RPi be significantly worse?  The only difference is the plastic box.

Neil
Posts: 98
Joined: Thu Sep 29, 2011 7:10 am
Contact: Website

Re: Sad about removal of I2S. Why was this change made?

Sun Mar 18, 2012 11:50 pm

TechColab said:


Personally I'm happy to call 24/96 good enough for me.  My ears wouldn't benefit from 384kHz and I'd reserve the "Low-end" label for 16/44.1


Its certainly good enough for the vast majority of people.  And there's plenty of evidence to suggest that there's no benefit going any better, other than marketing spin of course


The iPod is a great way of having a lot of music on the move.


Oh absolutely agree – these little portable media players are perfect for that.


But I use my home system which wasn't particularly cheap so I'd appreciate the benefit that 24-bit support in iTunes brings – I.e. improved dynamic range (when the producers wake up).


The issue of dynamic range in modern recordings is a hot topic in pro audio circles at the moment.  If anyone's interested there is a talk this coming Thursday in Cambridge on precisely this subject:

http://www.aes-uk.org/meetings.....-meetings/


I think normal conversations can tolerate a surprisingly low quality connection – look at the phone system.  So I wouldn't say Skype or other VoIP systems suffer too badly.


Agreed.


I find a multi-meter to be very useful and I'm happy to concede that RF projects are beyond my skill levels.


I don't think there was any mention of RF in this thread? For an oscilloscope you really need about 10x sample rate to the maximum frequency of interest.  So your 96kHz audio codec is only really useful for observing signals upto around 10kHz.  Beyond that you're likely not capturing enough information to visualise the waveform to a useful degree of resolution.


The fact that there are commercial products like the DSO Nano seems to imply that I'm not alone. I doubt many home hobbyists could afford (or need) the audio analyser you mentioned.


That's not the point.  I agree most hobbyists don't need an audio analyser.  But a decent scope is essential.  A poor quality scope just lies to you.  Certainly at A-level I would expect students to understand the limitations of the equipment they are using, and understand measurement uncertainties, etc.


Google for "site:raspberrypi.org oscilloscope" to see the forum post that I was referring to.


Thanks for the link.  It looks like the summary is: doing it properly is not cheap, might as well by a PICO kit, better to use the RasPi as the GUI and leave the sampling to a scope-grade front-end.


Google for "site:raspberrypi.org wolfson" to see some of the forum posts that discuss the use of well reputed audio chips which are far from low-grade.
I don't see how moving a 24-bit ADC/DAC to an external box at the end of a USB cable makes those 24-bits any better.  And it misses the point about latency.


I think I was the one who mentioned Wolfson in that thread   The point of an external USB box is that it gives you physical separation between the ADC/DAC and the noisy environment of the CPU.

Why is this important?  Lets take your 24-bit converter.  As it is designed for audio lets also give it a -10dBV domestic hifi input range (about 890mV peak-to-peak) and lets set this to the full range of the converter to get the most out of it.

I'm sure you can work out the maths yourself, but the result is that the least significant bit corresponds to about 53nV.

Please think about that.

While you do, here's an interesting thought: to get the thermal noise of a 1k0 resistor to below this level you'd need to cool it down to 1 Kelvin.

So unless you're going to cool your electronics down to this level then the intrinsic thermal noise of the electronics will render meaningless the lowest few bits of the converter.  You could use a 20-bit converter and still be at the thermal noise level of that 1k0 resistor.  Add in the rest of the circuit and you'll likely lose another couple of bits in noise.  Now we're down to 18 bits.

For a scope, the vertical resolution is not that important.  What matters more is the sample rate.  High-end scopes don't go much above 12 bits as there's little point.  They're more interested in high sample rates and accurate timing.

Oh, that's another thing.  In the noise budget we also need to include the noise from the clock source that drives the timing signals that tell the the ADC when to sample the input.  Any noise here (jitter, phase noise, etc) will manifest itself as yet another noise source.


Besides, where is the educational value in just buying a ready made product?


What, like a RasPi?   Sure, a few students will find it useful to design and build a codec interface, but the majority will find it far more useful to use a ready made product so they can get on with what they want to do.

It can also be a great education understanding the limitations of the equipment, how to design experiments within those limitations, and interpretting the results given the limitations of the equipment.  Its an excellent way to teach precision, accuracy, uncertainty, probability, random processes, etc.  If you have to build the interface yourself you can very quickly get bogged down in minutiae detail and generally tedious engineering issues that distract the students from their real projects.

(If the goal is to design a codec or scope interface then of course they would be looking at understanding codec datasheets, how to layout the PCB to minimise noise, codec imperfections like INL and DNL and so on, plus low-noise circuit design, EMC/RFI shielding, etc).


If you were to open a comparable USB audio device you'd find some analogue stuff, some power stuff, USB stuff, ADC, DAC, micro-controller and perhaps some memory.  Most of which is in the RPi so how can a comparable design based on the RPi be significantly worse?  The only difference is the plastic box.


And the PCB layout.  And the choice of surrounding components.  And the quality of ADC.  And many other factors.  That's why, for example, the USB scopes from Pico Tech have significantly different feature sets and prices compared to USB audio interfaces.

But this is getting rather off the topic of an audio interface.  I would suggest that for the relatively small number of people who need something approaching a decent audio interface to the RasPi that they investigate USB audio interfaces.  And anyone who wants to experiment with low-level ADCs and DACs get an Arduino and build R2R ladders for themselves and bit bang the pins.  After all, this is all about education, of which the RasPi board is just one means of achieving that aim.

Ville
Posts: 8
Joined: Sun Apr 01, 2012 5:55 am

Re: Sad about removal of I2S. Why was this change made?

Sun Apr 01, 2012 7:00 am

I am quite happy to solder wires to resistors if needed. I realize that it's not possible to route all features to 0.1" pitch header and keep the compact form factor.

This being a development board however, I would really like to see all features of SoC being accessible at least through some (tiny) solder points.

urxle
Posts: 1
Joined: Sun Apr 01, 2012 12:57 pm

Re: Sad about removal of I2S. Why was this change made?

Sun Apr 01, 2012 2:18 pm

I am also sad about absence of I2S as my first inclination is to use Pi for a Hi Fi

player. Can anyone tell me the points at which I could take I2S from the Pi please?

Neil
Posts: 98
Joined: Thu Sep 29, 2011 7:10 am
Contact: Website

Re: Sad about removal of I2S. Why was this change made?

Sun Apr 01, 2012 9:44 pm

Ville said:


This being a development board however, I would really like to see all features of SoC being accessible at least through some (tiny) solder points.


It is not a development board.  It is an aggressively cost-reduced computer targeted at school kids.

Chii
Posts: 10
Joined: Wed Mar 07, 2012 8:42 pm
Contact: Website

Re: Sad about removal of I2S. Why was this change made?

Mon Apr 02, 2012 10:48 am

Ok so they lost I2S by accident, that’s fine. At least with Gert’s help we may be able to get it back with a hack. If Gert will help us/me find the pins I am happy to do the mod to my board, and upload a how to video to youtube and write a wiki entry.

As for the external clock I would look to use the pink fish media FLEA as its pretty much what its designed to do.

User avatar
Gert van Loo
Posts: 2486
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: Sad about removal of I2S. Why was this change made?

Mon Apr 02, 2012 5:35 pm

Rambling post coming up as I try to answer mutitple items from the last weeks. (Sorry the 'new posts' function of wordpress does not seem to work so well for me)

I2S interface can be driven from internal or external clock. I have not looked yet how to prevent that the processor does not overflow/underflow the internal I2S FIFO when using an external clock.

I2S interface can also be used as input. So theoretical the raspberry-Pi has an audio input.

As to 'I would have likes all pins to come out': Read the forums. It was not financial possible to make a cheap PCB with all GPIO connections on it.

No clocks on the data sheet. yes, this is an omission. Not only for the I2S but also for PWM, SPI, I2C and a lot more peripherals. It is being address but it will take a while for the next version of the data sheet comes out.

I2S on the board. There are now picture of production boards so the following may be visible: You will find the extra 4 GPIO pins on the resistors next to the GPIO header. There you find R1-R10 (See the silkscreen). GPIO 28/29/30/31 are connected there. Each GPIO pin has a pull-up (R8/R7/R4/R5) resistor and a pull-down (R10/R9/R6/R3) resistor. (Beware: I kept strict order of GPIO numbers and resistors). Rove all of the R3-R10 pull-up/pull-down and find the common pin of R8/R10 .. R5/R3 and you have the GPIO pin. (The other side of the resistors are 3V3 and GND so simple to eliminate.)

There was original the idea to use those for a board revision (e.g. A/B) but I have been informed that there are at the moment no plans to use those pins in the software builds. If in the future a board revision number is required it is most likely to be programmed inside the BCM2835 alongside the MAC address. Certainly the current (B-boards only) builds do not use those pins. All that is speculations. I still can't see into the future so any modifications are still your own risk.

An image says more then a thousand words so:


User avatar
meltwater
Posts: 1015
Joined: Tue Oct 18, 2011 11:38 am

Re: Sad about removal of I2S. Why was this change made?

Mon Apr 02, 2012 6:50 pm

Thanks for the extra info...will have a look in more detail when I get chance to put in the wiki (if not done before then).

I think it is better they aren't tied as version numbering, the more pins the better!
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam

Return to “General discussion”