Generating clk synchronized signal without using typical serial communication protocol (SPI, UART etc)

It would help us to help you if you could step back a bit and explain what the purpose of all this is.

Where are these 24 bits to go, what will they interface with ?

As you describe it the bit rate is 192MHz, the RPi is not capable of toggling a pin at that rate, let alonekeeping in synch.

A 192MHz logic level signal (such as an RPi IO pin makes has a maximum "range" if a few cm at most in wire or on a pcb.

But suitable trickery can get 1Gbit/s along 100s of meters of wire.

Your SPI suggestion is more promising (but still too fast for RPi), so please explain the core purpose of your project.

MK

What i should do is just generate 27 bits(start bit + commend 24bits + parity bit + stop bit as described above!) and one bit is generated every 1 / (8MHz) second (at rising edge).

When receiver detect 28 consecutive zeros, they distinguish the start of receiving.

And after clk signal and signals come in they interpret 27 bits and instruct commends which is already postulated in receiver(for example 0000 0000 0000 0000 0000 0000 means do nothing) and go on.

Hi 

Look for SERDES in combination with FPGAs. - Xilinx, Altera, Lattice offer these chips.

The RPi makes the host.

You have to create a data frame because of the possible interference in the transmission path.
All others are not usable.

And you need a very good cable, e.g. B. Coaxial cable, or much better, you need fiber optic cable, because the transmission of about 200 MHz over a copper cable is very difficult, -> low-pass.

How long will the transmit/receive length be?

Best Regards

Gerald

---

You still aren't going back far enough

What device will be receiving this message ?

But you have changed the definition of the problem a little bit.

I (and I think Gerald and Shabaz) interpreted your first post as needing a 24 bit frame at a frame rate of 8MHz.

But now I think you want a 24 bit frame at a bit rate of 8MHz. (Frame rate of 1/3 MHz).

The RPi SPI port can do this easily. RPi general IO could do it but might be hard to code.

But you will have problems with the recieving device remaining in sync.

That's why you need to te expalin the problem at a system level.

MK

Sorry, my elaboration wasn't enough

What i am going to make with raspberry4 is just signal generator, sending specific configuration of 24bits(commend bit)+3bits(start bit, stop bit, parity bit).

So when i select commend on raspberry4, it will send 27 bits synchronized with 8MHz clk which are already postulated on the manual of receiver(configuration of commend bits are already defined on the manual of receiver. I have to make raspberry4 to generate those commend 24 bits with start bit, stop bit, parity bit).

And to let you get it straight i need every single bit of signal generated at rising edge of 8MHz clk. So every 1/8*10^-6 second, one bit should be generated.(Those sets of little rectangle and bottom line of clk on image means 1/8*10^-6 second ) 

The receiving instrument is just a data collecting device. So it receives the commend from raspberry4 and send data with another data line to computer. I already have the signal generating device but i want to substitute it to raspberry 4, because it malfunctions quite often. 

Thank you :)

This may be possible with the Raspberry Pi but I'm not sufficiently familar with its SPI hardware top be sure.

It is common to send 24 or 32 bit words over SPI but SPI is a synchronous interface with a clock signal. The data bits in any single 8 or 16 bit word (the PI can use either word size in SPI) will be sent at a constant rate but there may be a gap between words.

You need a hardware setup that will send 27 bits (32 would be OK, you could pack with zeros) at a contant clock rate. Some SPI hardware will do this and some won't. You may be able to find a microcontroller with SPI hardware that has constant clock rate with no missing clocks between SPI words but it's not something that data sheets tend to be clear about.

From previous experiments with RPi it will not be possible to do it with standard IO and software, it just isn't possible to send lots of bits at a constant rate although the PI is fast enough to do 8MHz bursts.

The only bomb proof way to do this is with hardware or an FPGA.

How do you know that it is your signal generator that malfunctions and not the reciever, or a data integrity issue in the interconnection ?

MK

How do you know that it is your signal generator that malfunctions and not the reciever, or a data integrity issue in the interconnection ?

- I have the guaranteed transmitter(i may call it a 'Commend generater') which i am going to substitute. If i connect Commend generater to receiver i can see that receiver operates well, but as i mentioned it malfunctions often. And that transmitter is made of ASIC chips and SMDs(it has some layers of pcbs in it. So i guess that is why it can generate MHz signal as you mentioned as a solution).

Referring your suggestion, I will try SPI with 32 bits, but if it doesn't work than i should consider using another hardware.

p.s. Actually i am doing some kind of my own project(improving old test device('Commend generater') in my lab) within undergraduate level. So i may believe receiver and data line it self have no problem(ig that is outside of my level). I have no other tools that can say receiver is wrong. 

Thank you for pointing right direction. Really helpful! :)

How do you know that it is your signal generator that malfunctions and not the reciever, or a data integrity issue in the interconnection ?

- I have the guaranteed transmitter(i may call it a 'Commend generater') which i am going to substitute. If i connect Commend generater to receiver i can see that receiver operates well, but as i mentioned it malfunctions often. And that transmitter is made of ASIC chips and SMDs(it has some layers of pcbs in it. So i guess that is why it can generate MHz signal as you mentioned as a solution).

Referring your suggestion, I will try SPI with 32 bits, but if it doesn't work than i should consider using another hardware.

p.s. Actually i am doing some kind of my own project(improving old test device('Commend generater') in my lab) within undergraduate level. So i may believe receiver and data line it self have no problem(ig that is outside of my level). I have no other tools that can say receiver is wrong. 

Thank you for pointing right direction. Really helpful! :)