Deous:
I asked simple question and everyone is in attack mode
It's not so much 'attack mode' as frustration with trying to bring you to the understanding that your question is a logical nullity. It's akin to asking which is colder, the Arctic or the color yellow.
Can you provide a link to the datasheet of the TFT?
Deous:
Arduino is a 'platform' based on Wiring and Processing
Yeah, so? It just gives you handles to do stuff easy and cross platform. But, appart from millis() and micro(), it does nothing in the background aka does not eat up speed.
Deous:
There is no point for you being arrogant
You started it 
Deous:
- you apparently assume a lot of stuff and base everything on your narrow opinions.
And here you go again And yeah, my opinion might be narrow but about programming and electronics I just just facts...
Deous:
I know what's fRTOS and idea is simple - Arduino - no multitasking and RTOS multitasking,better interfacing with services.
And yeah, that multitasking comes at a price and that's speed...
Deous:
Multiplexer will work as well but must be controlled a bit different I just never knew switching speeds of multiplexers
That's why there are datasheets And hé, if you think it works, please enlighten us. I (and I think the rest as well) think it can't be done. Show us wrong and earn karma.
Deous:
Do you know it all? Why are you whining? What's your problem?
I asked simple question and everyone is in attack mode
Uhm, you started to attack and insult people after we told you you can't use a mux to save pins for a single parallel input.
Deous:
mux-select pin 0>write
mux-select pin 1>write
mux-select pin 2>write
mux-select pin 3>write
close connection/request
Define "write" and "close connection".
If a write is "latch the data" then you have a problem. On a parallel input the data of ALL inputs is latched at the same time even if that pin isn't connected.
Yeah, so? It just gives you handles to do stuff easy and cross platform. But, appart from millis() and micro(), it does nothing in the background aka does not eat up speed.
Heh...yes - in theory - in practice NO )
And yeah, that multitasking comes at a price and that's speed...
First of all what magical 'speeds' you are talking about.
I use cpu to control peripherals - not to simulate them.
If you claim everything is so easy than show me easy way on Arduino f.ex. of async blinking of 10 diodes every specific time that you can dynamically change )
With rtos multitasking it is easy and clear.
If a write is "latch the data" then you have a problem. On a parallel input the data of ALL inputs is latched at the same time even if that pin isn't connected.
It doesn't matter - I am not asking you to help me code stuff but about switching speeds.
Deous:
Heh...yes - in theory - in practice NO )
Proof? An Arduino doing nothing (empty loop()) will just do jumps in memory and only jump out because of a timer interrupt for millis()
Deous:
First of all what magical 'speeds' you are talking about.
Clock ticks/cycles. Doing stuff takes cycles in the processor. Doing more means you need more clock ticks to do all aka speed is reduced.
Deous:
If you claim everything is so easy than show me easy way on Arduino f.ex. of async blinking of 10 diodes every specific time that you can dynamically change )
Can be done (at least if you mean the light emitting type :p), isn't that hard. But that was not the point. Yes, that might be very easy with a RTOS to write, but under the hood the CPU needs to do a lot more stuff to make it tick. Aka, you can do it faster (not write it faster) without RTOS or do it for more LED's because that is basically the same.
What I say is, using a RTOS comes at a price and that is "speed" ( = what you can do in specific time) / overhead. Aka speed and RTOS don't go hand in hand.
And yes, you asked about hardware and we told you it can't be done. Unless you dare to show us different I still call you a lair if you claim it can be done
Clock ticks/cycles. Doing stuff takes cycles in the processor. Doing more means you need more clock ticks to do all aka speed is reduced.
All comes down to read write memory/register speeds.
And how advanced and efficient is a particular RISC cpu design - eg more pipelines and pairing - the more cycles/speed.
This is assembler world for some serious non-human readable code optimizations.
You would have to be maniac or paid hacker to consider that for long shot apps)
Can be done (at least if you mean the light emitting type :p), isn't that hard. But that was not the point. Yes, that might be very easy with a RTOS to write, but under the hood the CPU needs to do a lot more stuff to make it tick. Aka, you can do it faster (not write it faster) without RTOS or do it for more LED's because that is basically the same.
What I say is, using a RTOS comes at a price and that is "speed" ( = what you can do in specific time) / overhead. Aka speed and RTOS don't go hand in hand.
And yes, you asked about hardware and we told you it can't be done. Unless you dare to show us different I still call you a lair if you claim it can be done
You haven't worked with other OSes but Arduino - haven't you? Lol
This is ridiculous what you are saying here - sounds like you are repeating something from Wiki and have no idea about the point of this conversation.
Do you understand the difference between Peripheral and CPU ?
If I do processing on the thread or interrupt - the speed always depends on the CPU hardware speed limit.
This statement of yours is totally vague and abstract and I suggest for you to rethink what you are saying.
Deous:
Do you know it all?
All certainly not. But I do know about multiplexing and parallel inputs and I know all about that topic, having been doing stuff like that for over 40 years. I first used a multiplexer chip in 1975.
What's your problem?
You are.
You give advice and are told by someone who doesn’t even know how to look up the speed of a component in a data sheet, that you have no idea what you are talking about.
Just because you might know something about something you have ventured in an area where you know very little. But you are approaching it with a breathtaking arrogance unaware that there is any possibility that you are out of your depth and making a fool of yourself.
The very title of this thread you started shows that you are the one who does not understand multiplexing and you will continue to know nothing until you get a bit of humility and either read data sheets or listen to advice from people who do know about these things. See how many people are supporting your assertion that you can multiplex to a parallel interface.
You haven't worked with other OSes but Arduino - haven't you
Given that the Arduino is not an operating system you yet again produce something that underlines how out of your depth you are.
Deous:
If you claim everything is so easy than show me easy way on Arduino f.ex. of async blinking of 10 diodes every specific time that you can dynamically change )
With rtos multitasking it is easy and clear.
Yes an RTOS is for people who find it difficult to code simple concepts.
So here is an example of how to do what you asked so that you can learn simple concepts like this. Oh and it is for 16 LEDs not 10.
/* Random blinking lights
for use on a christmas tree
By Grumpy Mike
*/
#define numberOfLights 16
byte pins[] = {2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18};
byte pinState[numberOfLights];
long int changeTime[numberOfLights];
int flashRate[numberOfLights];
long flashChange; // how often to change the flashing patterns
void setup() {
for(int i = 0; i< numberOfLights; i++) {
pinMode(pins[i], OUTPUT);
changeTime[i] = millis() + random(1000, 200);
pinState[i] = LOW;
}
setFlashTime();
}
void loop() {
for(int i = 0; i < numberOfLights; i++) {
if(changeTime[i] <= millis()) {
pinState[i] = ~pinState[i];
digitalWrite(pins[i], pinState[i]);
changeTime[i] = millis() + flashRate[i];
}
}
if(flashChange <= millis()) setFlashTime();
}
void setFlashTime(){
for(int i=0; i<numberOfLights; i++){
flashRate[i] = random(200, 1500);
}
flashChange = millis() + 100000; // next time to change pattern
}
You obviously DON'T understand word 'async' aka asynchronous.
Please stay in your single loop world and do not bother me with your useless ideas.
You have no experience in serious coding for serious engineering tasks as I see it.
Cheers
Thank you Mike 
We're talking the same hardware. So all architecture and pipe-lining talk all doesn't matter given the compiler you use for RTOS and bare metal (but higher level) are as optimized.
Deous:
You haven't worked with other OSes but Arduino - haven't you? Lol
Yes, I've used some other stuff and yeah, the ease you can make it do stuff is great. But it comes at a price, overhead. And I'm still fond of tiny cheap and simple uC's so I like bare metal more. And with the Arduino Framework it's pretty quick as well. But yeah, even that includes some overhead.
Deous:
This is ridiculous what you are saying here - sounds like you are repeating something from Wiki and have no idea about the point of this conversation.
Do you understand the difference between Peripheral and CPU ?
Is it? Others don't seem to agree with you And are you saying everything on Wiki is incorrect? As far as I read (and I'm still in the process of reading all technical articles on Wiki 
) it does agree with my books and my education. Bit bluntly at times but correct.
And yeah, I know the difference between CPU and peripheral, but what does it have to do with this all? Your program runs on the CPU, nowhere else...
Deous:
If I do processing on the thread or interrupt - the speed always depends on the CPU hardware speed limit.
The clock speed does, the speed of the application also heavily depends on WHAT you do. The whole RTOS layer isn't free or in thin air. It needs computation time before it even starts doing what you programmed to do. Aka, overhead. OR where do you think it runs?
I think you misunderstand async. Yes, with a RTOS you can async run tasks on program level. But on hardware level your single core micro still has to do everything synchronous.
And yeah, youu can now get multi core uC's for cheap. But you can use that bare metal as well. And that still isn't a core per task aka, more tasks on a single core synchronous.
I think you misunderstand async. Yes, with a RTOS you can async run tasks on program level. But on hardware level your single core micro still has to do everything synchronous.
And yeah, youu can now get multi core uC's for cheap. But you can use that bare metal as well. And that still isn't a core per task aka, more tasks on a single core synchronous.
I think that you cannot admit you don't understand multitasking and never touched mcu like esp.
You are totally WRONG saying that it isn't core per task - in esp32 rtos you can execute two tasks on two different cores with minimal overhead. If you are still stubborn and don't believe me check here xTaskCreatePinnedToCore
I told you to rethink what you are claiming here
Whaha, you're funny
Yeah, duhh. Two cores and two tasks / loops. You don't need RTOS to do that... But that's not what I said. Or do you want to stick to two tasks because you just have a dual core. Or do you just buy a core per task... You're running a 256 core desktop as well? I was talking about doing multiple things on a single core. Indeed easy to do with a RTOS but with overhead. And yeah, they got pretty good at minimizing that but still, there is overhead compared to bare metal.
@Deous will be spending a little time away from the forum.
Keep it civil, ladies.
Use a demutiplexer or a shift register. A multiplexer does the opposite of what you want to do.
A multiplexer does the opposite of what you want to do.
You missed the bit where he was saying he was using an analogue multiplexer so it behaves as a multiplexer or demultiplexer depending on what you wire it up to.
Use a demutiplexer
Have you not been reading everything here, using a multiplexer or demultiplexer will not do what he wants because they only make one path at a time which is useless for a parallel input interface.
I think we all agree a shift register would work but not at the speeds the OP wanted.
A mux turns many outputs onto one line while a demux turns one input into many outputs. But I understand because the demux only has one output pin on at ever one time.
So a demux does not work.
That makes sense. :o
Try this than. Max speed I think is only 12 mega hertz.
But Arduino runs at 16 MH so only 4 MH faster.
Anyway I think the chip should handle it.
Unsigned_Arduino:
But Arduino runs at 16 MH so only 4 MH faster.
That does not make sense.
If an Arduino is clocked at 16Mhz, that doesn't mean things happen at 16Mhz.
SPI is probably the fastest at 8Mhz.
The 74HCxxxx series might be a better match for a 5volt Arduino than the CDxxxx series.
74HC595 shift register, 74HC4051 or 74HC4067 analogue muxer, etc.
Leo..
Let’s not forget the OPs origional requirements:-
Deous:
I want to drive TFT 16bit or 24bit parallel with 15-30Mhz clock signal
Just have not enough pins.
So all talk of a 16MHz Arduino is out of the window. As is most 74 seriese logic.
Here is the most simplest solutions my meager brain can think of:
Buy a new TFT that uses I2C or SPI
Buy a new Arduino with more pins
Make TFT run slower (8MHZ?) for your project and get normal shift register
Get Arduino Due or some Arduino that runs faster. (BONUS: More pins so no shift register!)