After asking my question, I realize that I need a MCU with many free pins that I can program. I will start my research in that direction but if you have a good reference, please do not hesitate :)

You need to post more information before people can offer useful suggestions. :) What are these inputs? Logic states? A strings of bits? Analogue signals? How long a sequence or sample do you want to store? What sample rate? What resolution? What is the signal bandwidth?

Are these Binary signal inputs? Whether binary or some form of 8 bit data, it sounds like you would benefit MUCH more by using a memory chip, such as an https://www.alliancememory.com/wp-content/uploads/pdf/Alliance%20Memory_64K_AS6C6264v2.0July2017.pdf 8K words x 8 bit each. What you are speaking of is using a micro as a memory chip,a waste of time and effort, and materials. with a memory IC you could use 1 port of a PIC micro to send out an 8 bit address, and read and write to 8000 memory locations! Much more efficient. Major overkill, actually for your project, but you get the idea. -Lisa

@Lisa: you nailed it, that is exactly what I need! @Andy: I am sorry I didn't give more info (wrote out of my head, really) I will go for the largest IC I can find. It doesn't even need to be non volatile. Actually, it would be best non volatile.

@Markl, Are your inputs synchronous? In other words, do you need to latch the state of all the lines before you write them into RAM?

@andyfierman: The system in question is a continuous stream of audio or noise that is coming from slave boards and has to be analyzed by a master cpu to know what further action it has to do. Those sounds are continuous in time but I need to store each chunk of input to analyze them separately. I need to analyze all the lines/buffers and then clear them all, then letting the next chunk of stream in, to analyze it as well and so on.

BTW, is there an effective way to compare two audio signal amplitudes at the circuit level? That would lower the logic inside the cpu further down the road..

You are asking questions about stuff without giving any clear context or scope. Need a block diagram of what you are trying to achieve. Better still a Design Requirements Specification.

@Andy: sure thing [The simplified schematic][1] I drawed the current setup and the setup I want to achieve. Let's forget about the comparison done in circuit, it will massively bloat my pcb in the end. Please tell me if something is not clear [1]: https://easyeda.com/editor#id=af895e3116c941fc85e2fa4a5ddc5edd

@Markl, So the inputs you want to process are analogue signals. Presumably you have a microphone in each box to convert the sound inside it into the electrical signal? You need a pair of wires (in a coax of signal and grounded screen) for each audio feed to avoid noise pickup. You'll probably need to this anyway to get the mic signals up to the ADC input dynamic range. You may need to put a microphone pre-amp in each box so maybe need 3 wires to include power to each pre-amp. You may also want to put active or passive dynamic range limiting or clipping in the pre-amp stage. What is the frequency range of the audio? Consider including low and/or high pass filtering to reduce extraneous noise (both acoustic and electrical). You can get cheap 8 bit ADCs with I2C or SPI ports on them to read data serially into the MCU but this may limit how fast you can read the output of each 8 bit ADC with a 44.1kHz sample rate. ADCs with 8 bit parallel ports could all be paralleled up onto an 8 bit bus and then read at N times 44.1kHz where N is number of ADCs. Do you really need to do an audio amplitude comparison in real time or could you do it in data post-processing in the MCU? The latter would give you a lot more control over how you could measure and compare the signal amplitudes. :)

Hi Andy, The frequency range is 0-5000hz. Above is useless in this context. Yes you are perfectly right: I won't do the comparison in the circuit, that is too troublesome. I will follow your advices on prototype and we will see where it gets us. Anyway, and as usual, a big thanks to you Andy.

Markl, The question that keeps coming to mind for me is, do all the channels need to be sampled simultaneously? If so paralled ADC's would work fine. The sampling rate of most all cheaper ADC's is plenty fast enough for your needs. Also when you say router, don't you really mean multiplexer? If you can Multiplex the data, you must not have to sample simultaneously. If not than things could be alot cheaper by sampling each channel sequentially, into a PIC ADC pin. Any way sample all channels at once necessary? Or is fast sequential reading OK? -Lisa D

Hi Lisa, Thanks for your reply, The router is really a network router (not multiplexing here): raspberry pis equivalent are connected to it via ethernet cables, and on the main computer we reorder the packets thanks to the timestamps. At specified intervals, the little boards buffer the inputs and send a -quite- large chunk to the router, then relayed to the main computer. The main computer is dedicated to the task, without an OS running on it. The whole works but is slow and not very reliable. Actually, **it is a nightmare**. A parallel treatment, as direct as possible, is very preferable here because we need to compare variations occurring **at the same time** in the different boxes and as close to the event time as possible. Any offset can make the whole simulation wrong. That is why we need to ditch the other hardware and concentrate as much as possible on the simplest circuit possible: less expensive (electricity, hardware), less heat, less bugs, faster.

@Markl, If your max audio frequency of interest is 5kHz then why not lowpass filter at about 6kHz with a 4th or higher order filter and sample at say 14.7kHz (ideally 5kHz would be sampled at 10kHz but you can't meet that low a sample rate because you cannot make a brick wall low pass filter at 5kHz so a more realistic option is to use a filter made from one of the cheap switched capacitor multi-order filters you can get). http://cds.linear.com/docs/en/design-note/dn016f.pdf http://uk.farnell.com/w/c/semiconductors-ics/filters-active/switched-capacitor-filters/prl/results?st=switched+capacitor+filter&sort=P_PRICE (You can find some cheaper at LCSC!) Then you have reduced your sample rate by a factor of 3 which in turn reduces the rate at which you have to read the 8 bit parallel bus in order to read each of the N off 8 bit ADC outputs before the next set of audio samples all arrive (that's a whole set of N off ADC outputs to be read every 1/14.7kHz , i.e. 68us). So if you have N off 8 bit ADCs then you need to read each one in 68/N us. Probably a little less to allow for some ADC output enable, RAM write cycle timing and jitter. Another trick might be to have a 16 bit or even wider RAM bus so that you can line up 2 or more ADC outputs all at once and then write them all into RAM on the same write cycle. Your software can then split up the bytes corresponding to each ADC in the post-processing. * BTW, your cheapest option for microphones is probably electret capsule microphones. Lots of them around for phones etc. so their bandwidths are not unnecessarily high (i.e. not hifi). https://lcsc.com/product-detail/Electret-Condenser-Microphone_Electret-Condenser-Microphone_C31839.html Electrets have a built in jfet stage so need a dc feed (which is fed from the downstream circuit so the mic still only needs 2 wires). * There are some simulation examples including an electret mic model in: https://easyeda.com/andyfierman/Projects_for_beginners-tqkewO60i In particular: Simple audio peak detector Sound operated flash 02

@Andyfierman: wow, perfect, will dig into it right now :)

@Markl, Do you need to continuously sample the audio streams non-stop or can you sample for a period of time then stop and post-process at you leisure? If you can post-process in slow time then the only fast stuff needs to be sampling and writing the bytes/words into RAM. All the reading back out of RAM and workings out can be done slowly.

@andyfierman: Sorry for the delay! Everything will end up in RAM, yes. So we keep the parallel ADCs, poll them by the cpu and store the bits directly into RAM (done by the cpu), right? (<-> we ditch the sram units altogether) I made some testings, and it appears the simulation is not affected at a sample rate of 8000Hz, which we will go for, instead of the initial 44,100Hz or 14,700Hz divider. That is a lot less data to treat.

@Markl, You haven't said if you need to store **and** process everything all the time or if you can store a block of data then process that block, then store another block then process it and so on. That makes a *huge* difference to the architecture you need to make the scheme work. This is why I go on about writing a Design Requirements Specification. (See: https://easyeda.com/andyfierman/Welcome_to_EasyEDA-31e1288f882e49e582699b8eb7fe9b1f for background.) Until that exists you do not know what requirements you have to meet. Hence you don't know what you need to do to meet those requirements and so you don't know what you are trying to design. Thus you don't know what questions to ask and more to the point *neither does anyone who might try to help you*. Without that spec people can spend a lot of time trying to advise you and you can spend a lot of time trying to figure out what they are talking about with both sides quite likely not actually solving the real problems. I appreciate that you may not want to discuss the fine detail of your application or project in public but you have to find a way to convey enough information about your system to inform a meaningful discussion. If you wish to pursue getting detailed design help then I may be able to help but that will be outside the free support that I can give within EasyEDA. Otherwise you need to think about your requirements and post more information. You're not far off anyway with what you've described so far but you need to put more information out there rather than have people on the forum trying to guess what you might need or might be able to do, and some form of design requirements spec is the way to do it. Sounds very formal but it's actually only what you need to do before starting any design task.