some problems with spi data transmission

[mnf]

I think the issue might be one of timing,

In the receiver - have an interrupt on CS change (it limits the choice of pins for this) - then attempt to receive the data. I don;t know whether it would be possible to receive in the interrupt handler (small number of bytes maybe? - depends if the receive uses any interrupts)

Martin

[chipfryer27]

Hi Martin

That is an issue for sure.

In the WiKi the examples show the use of the SSP interrupt but not all chips have this facility nor does his target an ATMega8.

There is (I think) an SPI flag that gets set so I'm guessing a custom interrupt may be necessary, which isn't my strong point but this WiKi link seems a good start.

https://www.matrixtsl.com/wiki/index.ph ... Interrupts

In my multi-programmer I have a PIC16F18877 that does have SSP Interrupt so that should be easy to get working and I think I might have a Mega8 in an old Arduino board somewhere.

I was going to experiment with IOC on CS/SS but as mentioned previously the pin activity isn't what I expected.

Regards

[gilanetugila]

Good afternoon! I looked at the description of the logic analyzer "cheapo", a device useful in the household, but it only allows you to see logical zeros and ones and their bundles or combinations, but does not decrypt this "logical fence", especially it would be useful to make sure that the information that we need is transmitted. Therefore, the name "logical visualizer" is more suitable for this device, so that users do not confuse "warm" and "mellow". The SS or CS signal, the slave controller selection signal, looks wrong everywhere on my charts. It should be of negative polarity, but I get a positive one. And the CKL sync signal is not visible .But this is in the simulation program.

[gilanetugila]

Good afternoon! The controller-PIC16F18877 is scary to look at, it needs a whole room for it. Have you not met the interrupts we need, as in the wiki example (which was shown earlier), but for PIC controllers where there are no more than 28 pins? Once upon a time I transferred data from one Atmega8 controller to another via the uart bus, it even turned out in the proteus program, but it was a test and in reality I did not collect it. And now here's a problem with spi. Have you asked other flowcode specialists how they solved this problem or did they have any problems with the program and data transmission over spi?

[gilanetugila]

Good evening! In general, I used to think that this forum was supported by professional developers who wrote the flowcode program to learn more about the shortcomings or to see some fresh idea. And it turns out that the forum is led by professionals and amateur users. And developers don't hear users. Here is such a sad picture looms. It would be great if there was user support by mail . Yes, I agree it will be difficult, but it can be solved. Especially if they carry such an important educational activity! And they have practically no competitors!

[chipfryer27]

Hi

Matrix do offer support, but obviously their focus is on the more recent versions. V8 is quite old now. Have you considered obtaining v10? All components are now free as are many "chips". The user forums I believe offer fair support from within the FC community.

As to the above, the cheap logic analysers I refer to, which you can get from well known market places are indeed logic analysers as they are compatible with free software such as PulseView. Also, many scopes can decode signals too but they can't be bought for around $10...

The diagram you show above is much better as you can see the CS/SS pin as high, only going low for the duration of transmission. This is what you want to see being sent by your Master.

The PIC16F18877 is just what currently is in my Multi-programmer. Another Multi-programmer currently has a PIC16F1939 which too has an SSP Interrupt available to it so I don't expect any issues using either of these chips. However your Mega8 doesn't have that capability so once I have it working using SSP, which confirms my Master is correct, I was going to experiment with IOC or such like.

It is very easy to transfer using UART and if your targets are more than a few metres away it may well be a better option for you.

Regards

[gilanetugila]

Good afternoon! I do not dispute that the version of my program is already somewhat outdated and that there was support from employees who wrote the code of this program, I just thought that this support would be more explicit (how do you help me) and throughout the entire time of the program-from where did I come up with this? I once watched a program where they talked about Rolls Royce engines for airplanes and it said that telemetry signals were coming from the aircraft to predict its operation.And they do it around the clock! I thought that such a service also applies to software products. Thank you for telling me the model of the PIC16F1939 microcontroller, I will try it out next week. In addition, I found a video lesson on transferring byte information from one atmega8 to another and there is a "confirmation" of work in the proteus program. And the signals there are surprisingly correct! I will also try again and then report the results.Yes, you're right about using uart, the distances are small there, but controllers like attiny 13,24,44 have only the spi bus, and there's not enough space where I wanted to put them. I2C would still come up, it's not there either. In general, we will try again. In the end, the work of an engineer is always a choice between necessary, possible, affordable and not expensive.

[kersing]

You can certainly get the same level of support for software if you pay the same amount for it and a hefty maintenance fee. In all other cases it is a reality that software gets outdated and support stops.

For Flowcode you can update to the current version and that one is supported (as is the previous version), older versions rely on other forum members and spare time of the engineers.

[gilanetugila]

Good evening! I agree with you completely about honesty! But you said that you purchased the latest version of the flowcode program. Is there an opportunity to solve the problem with the spi and atmega8 bus using standard program tools ?It occurred to me that maybe the developers of the flowcode program know a little more than others about the future of AVR chips, you remember that the chip manufacturer PIC -Microchip Technology bought Atmel in 2008, and perhaps the future of atmel chips is very vague...and writing programs for them is not very promising? When I bought the program, I heard that there was an opportunity to receive longer support with advice, but either the amount was large or I read this item too quickly and did not focus on it.

[gilanetugila]

You mentioned the saying "Honesty is when you do the right thing, even when no one is watching." As a philosopher -philosopher, I want to note that this statement does not contain the whole palette of relationships between people or nations. Therefore, the word "right" for different peoples or groups of people has a different context -for some it is "right" to eat their enemy, for others it is "right" to send Jews to the ovens, for others it is "right" to deceive a person of another race or religion. Therefore, I rather choose "Don't do to people the way you don't want to be done to you", this is the saying of Jesus Christ, whose authority in the knowledge of man and his weaknesses is beyond doubt.

[chipfryer27]

Hi

I'm a bit confused. In an earlier post you said you were going to try the PIC16F1939, which does have an SSP interrupt, so should be quite simple to achieve, and the WiKi examples can easily be modified for the target.

Are you now saying that you still wish to persevere with the Mega8?

Regards

[gilanetugila]

Good evening! Yes, you are right, I continue to solve the problem with atmega 8, because I read in the description of my programmer that it cannot program the PIC16F1939 and PIC16F18877 controllers. I do not know if my device is needed or not, so I will try to make do with what I have. The new programmer is expensive. In addition, there will be spending on details to check the performance. I started studying the available video tutorials, but so far it is not going very fast. In one lesson, just a piece of video is cut out. But there are different authors and different examples. It may be possible to send and receive data over the spi bus.

[chipfryer27]

Hi

I've been a bit busy during the last week, but when I get time I'll try and get something running.

Regards

[gilanetugila]

Good evening! I was away for a while as I further realized the meaninglessness of our conversation when I draw conclusions about the operation of the SPI data bus in a virtual simulator. I soldered a real circuit for communication between two atmega8 microcontrollers and two lcd 1602.I checked the operation of the controllers and indicators. In the near future, I will report on the operation of the SPI bus using an oscilloscope DS02D15. But it is desirable, of course, that the results in the proteus program and the pictures from the oscilloscope match-this greatly simplifies life and increases confidence in the results of work in a program with a virtual simulation.

[chipfryer27]

Hi

I'm always a little sceptical if purely relying on any simulation, so it is good to hear your hardware is performing as expected.

Regards

[gilanetugila]

Good evening! Well, the situation is somewhat more complicated, but the fact that I soldered it works-the display and the button, but problems begin with the SPI bus. First, I made a program where the button was pressed and while it was pressed, the count took place and this data had to be sent to lcd1602 and sent by the spi master module.Everything worked in the flowcode program, but in reality it began to hang somewhere after 1-2 counts of the variable. I thought I had done something wrong and redid it and ran this program without sending data over the spi bus-everything worked out correctly. So the problem is in the spi module. I redid the program several times, but it still started to hang in reality.

[gilanetugila]

Next, I made a program without a button, there was a looped process of sending data over the spi bus once per second. On the oscilloscope, we could only see the signal from the SS output-it turned out to be what it should be-of negative polarity. But for some reason I didn't see the rest of the signals. Now I will try to see the signals when the data will be sent from a short-term button press.

[chipfryer27]

Hi

To simulate in FC I changed to CS pin from B2 to C2 and could then use the datalogger to see what was happening on the pins. For some reason it wouldn't let me use B2.

It ran fine in simulation.

In hardware, how are you monitoring the pins?

Regards

[chipfryer27]

Hi

You updated as I was replying

Assuming you have a two channel scope (at least) set it to trigger on CS going low (when you push your button to start) with the other channel on MOSI. You should see CS go low then shortly afterward a burst of MOSI data before CS returns to high.

Regards

[gilanetugila]

Good evening! yes, you're right, I also noticed that by default in the flowcode program, the ss output is used in the c2 output. But I didn't try to connect it that way, I tried when ss uses pin b2. In addition, some sources say that when transferring data from the master to the slave, if only one slave, then the ss output can not be connected at all. As for how I measure, I connect the ground of the probe to the minus of the circuit, and connect the signal pin alternately to the pins of the spi bus.I have two pdip28 connectors on my breadboard, the spi bus terminals of one controller are connected to the spi buses of another controller by short wires. The wires are marked and the insulation is removed from them in the center. I connect the signal output of the oscilloscope probe to this part. Now I have checked the operation of the program where one number is transmitted to lcd1602 and over the spi bus. Everything worked in the flowcode program.(I didn't watch the program in the oscilloscope only).I started it on a real board-there is no image on the display when the button is pressed, but there is only a signal from the ss pins, I have it from the b2 pin. There were no signals on the other pins of the spi bus: the waveform is a straight line. I will be able to continue working on the spi bus on Monday after 14-15 hours. I would like to ask you if you have the opportunity to repeat my programs but in an earlier version and a later version of the flowcode program and send hex files? So that you can find out if what is not working is a defect in my spi module or something else. And I'll try out these programs on a mockup.

[gilanetugila]

The addition is where the button and the photo of the board for the spi bus are connected.

[chipfryer27]

Hi

I don't have that chip so cannot test with it, but I think it unlikely that there is an SPI issue as it has been around for a long time and if there was an issue it would have been flagged before now (I would hope).

How long does your scope run for once triggered? It may only be able to capture one burst or so.

The displays will work if connected correctly, of that I'm sure, so I would concentrate on looking at your SPI. I would connect your CS as some slaves won't actually "action" an instruction until CS returns to high.

Anyway, for testing you don't need any device connected. Ideally have a scope on cs / clock / mosi pins, triggering when cs goes low. Have your chart loop outputting anything you wish. You should be able to capture activity each time you "run" the scope.

Regards

[gilanetugila]

Good afternoon! It is a pity that it will not be possible to check the performance of the spi master module, I will try with another specialist in the flowcode program, but I do not know if he will be able to help me or if he will be willing to help with this program. When I was watching the signals on the oscilloscope, I used two channels once and one channel the other time. I used static and dynamic (in time)the scan. Unfortunately, nothing appeared except the signal on the ss pin. I will also try to make and check the program when the ss output is on the c2 output as by default, I will also try the option so that when the button is pressed, an interrupt is triggered-there is such an opportunity on atmega8 and data will be sent via the spi bus in the interrupt. Maybe this will cause signals to appear on other pins of the spi bus, or maybe the problem with the indicator will be solved, which has stopped showing what I am sending when it works in conjunction with the spi module. Well, as the first point, I will write to a friend about trying to send me the hex file of the project.Why do I insist so much on atmega8 -this is probably the most common chip and besides, there are a lot of pages on the network where it is shown in the C programming language that implement information transfer over the spi bus. If you can't do it in the flowcode program, we'll insert it in the c programming language. You just have to be patient, search and try.

[gilanetugila]

Good afternoon! I have conducted several experiments with the spi bus, but the results do not please me. Well, first of all, the signals are the same - there is a negative pulse on the ss pin, on mosi or clk - it is empty. When I use 1 MGr instead of 8 MGr, the picture on the ss pin gets worse-the pulse length decreases by 4-6 times for some reason, I also noticed that if the signal end of the oscilloscope on the mosi pin and took the ss pin with my fingers, then for some reason there are negative pulses on the oscilloscope screen, very similar as if I was taking a signal from the ss pin. It was not possible to check your version of the program. A friend has lower versions of the flowcode program and it seems to be version 9 of the program. I will try to make a program for pwm modulation to see what I will see there and at what settings of the oscilloscope, because I do not have much experience using an oscilloscope.

[gilanetugila]

Good evening! I checked the operation of the oscilloscope using the example of a program with a PWM signal. Everything shows that there are some errors in what pulse length values are in the program and in real life, but overall a satisfactory result in the sense that when I tried to see the spi signal, but it was not visible, it means that it is, and not a measurement error. I will continue to solve the problem with the spi bus. When something appears, I will write.