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

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! :)

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

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 :)

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

---

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?

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.

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? 

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

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

---

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.