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

Hi, 

Regarding your comment:

using raspberry 4 and python

You're requesting about two orders of magnitude better performance than is realistic if you wish to operate at such rates that you mention.

With C, you're still one order of magnitude away, if you wish to do this in user-space code (i.e. using libraries like RPIgpio etc).

You'd likely need to do this at driver level, which has a learning curve. There are not many good books on it, you'd need to do some research online (or try to find a good book if you're lucky, please leave a recommendation here!) to learn how to do that.

Another option is to dispense with Linux and go with bare-metal code, but then you're losing access to all of the Linux functionality. Yet another option is to do this with different hardware (FPGA or microcontroller) and connect to the Pi as required.

Thanks for your courteous reply.

I didn't know that MHz scale signal is impossible to make, since it is low compare to fundamental clk of raspberry.

Since i know the problem, maybe I should try another one.

I found that SPI can be used to make MHz signal. How do you think about using SPI instead? 

Thank you for your advice :)

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

I have read your question and napkined this drawing to confirm your explanation and my understanding are the same.

The data signal (i.e the bits) has a frequency of 200Mhz? 

No - not in this way of thinking. Yes in second thinking about.

But first - the problem you have is signal leakage. Then the square wave becomes a sine wave or it cannot be transmitted through the cable as well may be the signal comes not to the receiver.
The higher or sharper the slope of the signal, the slower the frequency needs to be to transmit a digital signal and the shorter the cable length needs to be.

Sorry G, No & Yes? I was trying to confirm my numbers.

I was looking to determine the frequency of the data signal. Analog or digital waveform is not my concern. The question is "trying to make the signal". Transporting such a signal is another matter for consideration in transmission media.

I attended my very first HP systems course to learn how to install and configure HP Unix computer system used for weather forecasting. The instructor was providing the rules for terminators on the SCSI bus. The original SCSI bus in a computer was moving data at 100Mhz. I was confused until he indicated the bus speed of 100Mhz. Wait, that is in the radio frequency RF range. Rules for termination on the SCSI bus were no different than the termination in an RF transmission environment.

My background was RF transmission systems from HF to well past UH. My career path was taking me from electronic system support to computer system administration. Some of the knowledge between careers was transferable between careers.

Computers move data at giggly hertz all the time. It is only when the data is taken from the bus that I would start to consider transmission media.

Can you create a 200Mhz digital signal on a Raspberry Pi and if yes can it be exported?

HI,

It's a point of the type of RPi.

Not 200MHz. The SPI can transmit up to 125MHz with the chip BCM2711.

Please read this manual on page 17:

"Again the SPIs themselves have no throughput limitations, in fact they can run with an SPI clock of 125 MHz. But
doing so requires significant CPU involvement as they have shallow FIFOs and no DMA support."

https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf

Raspberry Pi Datasheets

Best Regards

Gerald

---