Matrix user forums

The screen from the oscilloscope screen did not fit. I had to take pictures, for some reason the screen is saved on a flash drive.

Good evening! He is especially kind today! It turned out to send the number "13" over the spi bus. The graphs turned out to be so-so-I had to catch them with a camera, for some reason the waveform drawings are not saved on the flash drive. It turned out that there is a menu in the settings of the spi module where you need to select "soft". And then it turned out to send. Now I will work on getting the data.

An addition to the previous message.

An addition to the previous message. When sending data over the spi bus via an interrupt, the "clk" and "mosi" signals match the signals from the previous messages, and the signal from the ss output is different.

Hi

If I haven't used a scope in a while it takes me more than a few minutes to refamiliarise myself with it. I actually have a few and as they are all different the fun knowns no beginning.....

When I'm next beside one I'll capture a transmission and post for comparison.

Regards

Good afternoon! Today I tried again to receive data on the spi bus. For the first time, I used a signal from the ss output to start transmitting and receiving data, and the initialization of the spi bus took place at the moment the signal from the ss bus from mastera arrived at the into0 output for interruption. And the spi shutdown signal after receiving data. There were inscriptions on the display of the receiving controller, but there was no confirmation of reception. The second time I connected the ss output of the receiving controller to the ground (on the recommendation of some sources).He began to measure the signals.
And then it starts to get interesting again. Instead of the signals coming when I press the button. They start coming at some interval. I take out the receiving controller and the signals start coming again when I press the button. Thus, when the ss pin was connected to the ground of the receiving controller, it began to send signals from clk and ss.The program was made for the controller to receive signals in master mode. In slave mode, the program simply cannot be compiled-it writes about an error.In this program, the initialization of the spi bus is already beyond interruption.

Hi
Did you try to work without using interrupt?

Hi

Following on from Viktor, I think you need to provide a little more information.

We don't know what, if anything, you are connected to that transmits / receives your data. From looking at your chart it appears that after you initialise you enter a loop. In each iteration you enable an interrupt. This isn't necessary, it only needs to be enabled once so you should move this interrupt enable to before the loop.

The interrupt is set to trigger on the rising edge. If as I assume (and I may be wrong) you have your SS/CS pin connected to the interrupt, then the interrupt will only trigger at the end of your transmission. SPI SS/CS idles high going low for the duration of the transmission before returning to high at the end. Therefore you are unlikely capture your characters.

In your ISR you assign variable "a" to the SPI GetChar component. before returning. You then display this value before sending it back out on the SPI. Again, as you are only triggering the interrupt after the transmission it is unlikely you will capture what you expect.

You could try setting your trigger for falling edge and perhaps consider using GetString or GetArray (if you know how many bytes you are receiving).

Regards

Good evening before Christmas! Let me congratulate you and your loved ones on this holiday! I wish you all the best, health, creative success, new interesting and extremely useful projects, and financial well-being. In a separate line, I want to thank you for not leaving me alone with this technical problem and pointing out the shortcomings-I saw in the interrupt settings that I had incorrectly set the trigger moment-it was necessary to use the falling edge, but I did it on the ascending one. And I will try to work out your version of the program for receiving data over the spi bus without interruption.

You wrote "In your ISR you assign variable "a" to the SPI GetChar component.
before returning. You then display this value before sending
it back out on the SPI. Again, as you are only triggering
the interrupt after the transmission it is unlikely you will
capture what you expect."
This means: if I send a certain byte number" let's say "13", I will receive not this number, but some other data, not even a byte number?
According to your recommendation, I will try to get the "getString or getArray" over the spi bus. As soon as I check any of the versions, I will write.

Hi

Merry Christmas to you too and a Happy New year when it arrives.

If you triggered on falling edge, then looked for incoming data you would have a reasonable chance of catching it especially if using an appropriate timeout value.

Have a good festive season.

Regards

Good afternoon! I have now tried the option of receiving data over the spi bus without interruption. Unfortunately, there are no changes yet on the lcd1602 indicator of the receiving controller. It turned out to take better pictures of signal voltages, only the signal from MOSI was poorly caught and turned out to be a little different. I will continue further.

Screenshots of CLK and MOSI signals.

Hi

Your two traces look as expected.

However without any form of interrupt it will be practically impossible to capture any received byte as without such you are relying on nothing more than pure chance that something will be present when you look (including clock). If you do manage, can you please pick me some numbers for next week's lottery too ?

Remember that data is clocked in and out and some devices also require CS/SS to go high before "actioning".

Regards

Good evening! I tried to receive data using a program where there is an interrupt and it starts with a falling edge. Unfortunately, there are no positive results. No numbers appeared on the indicator connected to the receiving controller. I have identified a feature when two wizards are used-they both send data from the MISO pins and there are synchronization signals on both controllers. When the controllers are connected to each other, the signals "stack up". View the attached files. To clarify, 1 controller is transmitting, 2 is receiving. File signature.

Continuation of the screenshot from the screen.

It seems to me that when the signals go towards, when the master sends and the master accepts, the idea is so-so, although at first glance it seems to be working. I tried in the simulation program to get away with unnecessary signals from the receiving master using a diode-nothing worked.

Hi
What is the reason you constantly re-enable the interrupt?
I think you have been told:
In each iteration you enable an interrupt. This isn't necessary, it only needs to be enabled once so you should move this interrupt enable to before the loop.

Hi

Whilst your traces are helpful, what would be very helpful is to use both of your channels and post, along with more explicit details of what they are capturing. You mention when two "wizards" are connected they both send data from MISO pins. Being honest, I really have no idea of what your traces are intending to show. It sounds, and I may be wrong, that you are capturing what a slave is sending (MISO), but the slave cannot send unless a master instructs it to. If your Slave is accepting instructions, what then exactly is the issue?

For example can you send

Ch1 triggers on Master CS/SS falling edge
Ch2 shows clock

Next capture

Ch1 triggers on Master CS/SS falling edge
Ch2 shows MOSI

Ch1 triggers on Master CS/SS falling edge
Ch2 shows MISO

I really don't think your issue is related in any way to what you are transmitting, rather you aren't set up to receive correctly. The chips you are using are old, so any issues would have been flagged and addressed by now.

I also appreciate that this forum is global and things can get lost in translation, therefore traces can be extremely beneficial.

Regards

Good evening! I will clarify some questions that you have: 1) the controller chips came to me about 2 months ago, there is no year of manufacture on them 2) when measuring signals over the spi bus, I always looked just in case if there was anything on the MISO pins-nothing ever appeared there.3) I'll try the option where the interrupt is behind the loop. I use it in a loop because in a real device where I plan to use data transmission over spi, there will be many variables and the value of some will change over time. And if I use an interrupt without a loop, I won't be able to enter them completely and at the right time. 4) when transmitting data over the spi bus, I do not use the "slave" module, my data from the "master" module goes to the "master" module, which is configured to receive data.5) I do not use the "slave" module because the flowcode program does not compile the program-well, I wrote about this earlier.6) to confirm that the controller that is supposed to receive data, and it sends it, I took out the transmitting one from the panel.
I can't answer the rest yet, I'll write as soon as possible.

Hi

I think there is a misunderstanding in the use of Interrupts.

It only needs to be enabled once, outside of your loop. Once enabled it will continue to call your Interrupt Service Routine (ISR) every time it is triggered, until you disable it.

If for example you triggered on the falling edge of INT0 calling ISR_Macro, once enabled, every time a falling edge occurred on INT0 it would immediately jump to ISR_Macro.

I hope to get a chance tomorrow to capture some traces for you to compare.

Regards

Hi

I created a simple chart to send a single value out on the SPI.

Chart uses SPI Master component and has

C5 = MOSI
C4 = MISO
C3 = Clock
C2 = CS/SS

Clock idles high and CS/SS is active low.

The below shows the traces captured on a logic analyser set to trigger on CS falling edge.


I'll create a chart for MISO when I get a chance.

Regards

PS
Forgot to show in above, the time from CS/SS going Low to MOSI starting is approximately 7.5uS (chip is running at 19.xxxMHz with SPI Prescaler set to Fosc / 64).

Hi

What is it exactly you want to achieve? Is it just to have two chips send bytes to each other, or are you intending to just read or write from one to another? Will the data be in the same format each time (e.g. a four byte array or string)?

Regards

Good afternoon! Ideally, I need to transfer byte variables from one chip to another, which will participate in the operation of the program in the device. And I would like these variables to be in a form suitable for use in mathematical operations , or become so through an operation . One of my friends writes programs in flowcode, but he has a very early version and he usually checks the performance in a virtual simulator, in any case, he did not move further along the spi bus. I tried his version. He wrote that the controller that sends the data should not have a CS output connected to the CS of the controller that receives the data. And on the CS of the receiving controller, you need to apply "0" in any way-either connect to the minus circuit, or apply a logical 0 to the output, and after receiving, apply a logical 1. I tried both options. When a logical 0 was applied to the CS output and then 1. Even the inscription disappeared on the receiving lcd.(in another example, the data was not displayed) and I had a thought what if the data in the receiving device is not in the form of a byte variable, but in some other. (By the way, you have already written about this scenario).It would be great if you had the opportunity to test this theory on the controllers available to you. It would be ideal to get preliminary results in a virtual simulator, but old controllers are used there. And there are new ones in the flowcode program for data transmission over the spi bus.But the friend I wrote about did not work exactly in the flowcode program, but he also entered the code there. I'll watch his lesson and try to repeat it, because it doesn't work any other way.

Hi

And on the CS of the receiving controller, you need to apply "0" in any way-either connect to the minus circuit, or apply a logical 0 to the output, and after receiving, apply a logical 1. I tried both options. When a logical 0 was applied to the CS output and then 1

That sounds to me the description of CS during normal operation, and is displayed in my traces above.

I'll try and send you an example of Tx /Rx soon.

Regards