some problems with spi data transmission

[gilanetugila]

Good evening! So it is, of course, but no one assumed that two controllers would send CLK and MOSI pulses, because we assumed that only the transmitting controller would do this!

Now I have looked at how the program for receiving data over the spi bus will work without using a loop. It will not work-or rather, it will work for 0.1 seconds and stop.

Tomorrow is the last day of the year, happy New Year!

[chipfryer27]

Hi

With SPI there can only ever be one Master but as many slaves as you wish. Usually MOSI/MISO are connected to each slave with unique CS/SS pins that let each slave know it by itself is being addressed.

MOSI is Master Out Slave In and is unidirectional from master to slave device
MISO is Master In Slave Out and is unidirectional from slave device to master

The slave device can be anything from a sensor to a display, or even another microcontroller.

However the Master controls ALL communications. It is impossible for a Slave to instigate communications.

Although MOSI/MISO are unidirectional, it is quite possible to have simultaneous bi-directional communications as when the Master "clocks", data is clocked in at both ends.

Do note however that the Master must know how many bytes in advance to send/receive as it needs to know to clock them in/out. That's why I was asking about your intention. SPI isn't good for random data lengths.

Regards

PS
This link is quite informative https://learn.sparkfun.com/tutorials/se ... ce-spi/all

[gilanetugila]

Good evening! Thanks for the clarification. Otherwise, I was "close to creating an interface similar to the spi bus."..- but my CS pulse length is not proportional to the data, and maybe 1.5-2 times longer than necessary.
In classical theory, it turns out that the length of the CS pulse from the master has a length proportional to the number of synchronization pulses and MOSI output data pulses.

But we are working in the flowcode program where the spi bus slave module does not work everywhere. Instead of the slave module, we use another master. Since the master module can transmit and receive data. Maybe it is necessary to output the MOSI of the master (transmitting)connect not with the MOSI of the master (receiving), but with the MISO of the master (receiving)?

If my suggestions and in general all correspondence about the spi bus had been read by the creator of this interface, he probably would have called the exorcist monks...

[chipfryer27]

Hi

he probably would have called the exorcist monks...

Hahahaha

SPI can be a very fast communications protocol ideal for relatively short distances. However the protocol does stipulate a Master / Slave(s) relationship in that there is only one Master and it controls ALL communications.

If you have a scenario where you have slave devices, which could be anything really, that need to send data to the Master at random intervals, then SPI may not be the best solution.

Having the Master poll each device whenever it wants an update is certainly possible. Is that an option for you? This could be done using Timer Interrupts or polling within loops or the like. Point being that the Master will instigate ALL communications, the Slaves can never.

Have you thought about other ways such as the UARTs? Using them would allow you to send data each way at random (and random length).

Regards

[gilanetugila]

Good evening! So far, my research in the field of receiving data over the spi bus has had no positive results. It wasn't me who chose the spi bus, it was me...When the creative idea arose, there was a need for a small controller with a large memory. I came across the ATtiny series-and there's only the spi bus.

It seemed easier-take the data bit by bit and form bytes or strings from them. Probably this process could be described in C, but you need to know it.

There's not much left to dig around. Moreover, you can see for yourself that the program has such a problem with the spi bus.Recently, an idea came to me on this topic , but what if the developers of all kinds of interfaces or buses demand their margin for using them. And the creators of the flowcode program faced this and there turned out to be unaffordable amounts.

As for your question, am I going to receive data from the slave device - in principle, no, I just need to write variables to the slave controller so that the program then works according to these variables. Maybe if nothing happens with the data reception, or rather with the display of information about the received data on the lcd1602 type indicator, you can try to send some information from the slave device confirming the data reception-let's say data came at a certain pin, logical 1 appeared, data was not received-logical 0 appeared. And the receiving controller will work without an indicator, so I'm trying to guarantee to send the data (we've already succeeded) and accept it as well.

[chipfryer27]

Hi

As for your question, am I going to receive data from the slave device - in principle, no, I just need to write variables to the slave controller so that the program then works according to these variables

Okay, then SPI is a good way to do it.

However I think it would be good for you to define the format of what you will be sending / receiving. By that I mean for each slave, what information will it need and how many bytes etc. Each slave can differ in need, but if you can predefine such it makes communications easier. Note that this also applies for any information the slave needs to return to the master, and that the master will collect this data when it requires it.

Regards

[chipfryer27]

Hi

I was in my Evil Lab today and created a circuit in hardware with one uC acting as a Master and another uC acting as a Slave, based on the WiKi examples.

My charts however use PIC16F1939 as the uC, simply because they are already in my programmer boards.

The Master simply counts up and transmits the byte over SPI.

The Slave receives this byte and displays it on a LCD. It also transmits a character back to the Master.

I put my logic analyser on the wires and it clearly captures all activity.

I had to leave before finishing, so as I should be back in tomorrow I'll forward my charts and traces then.

Regards

[gilanetugila]

Good evening! Oh, it's just super what you did and what was displayed on the lcd 1602 indicator. So, in principle, we are moving correctly, but something is not working properly for us. This is a great success!

I was sent programs in .hex files for receiving data over the spi bus in versions 5 and 6 of the program, I tried them on real hardware. There was nothing on the lcd1602 indicator in both cases. Only when the program was written in version 6 of flowcode, since the CS leg was connected to the minus, for some reason the chip sent some of its data on MOSI and CLK with a certain frequency.

As for data transfer from one master to other controllers, it is planned to use one master for several separate devices with a controller for reception. Everywhere the data will be approximately the same -byte type, let's say the variable n is tens of hours,m is units of hours, t is tens of minutes, d is units of minutes. Well, this is an example.

[chipfryer27]

Hi

Based on the WiKi examples, but chips changed to PIC16F1939.

Created a Master chart which simply counts from 0-255 sending out the value on the SPI. At the Slave end it receives the value, displays it on the LCD and "echoes" the value back out on the SPI.

SPI_Master_1939.fcfx

(9.65 KiB) Downloaded 116 times

SPI_Slave_1939.fcfx

(13.75 KiB) Downloaded 157 times

Logic analyser captures the traces.

SPI-1.jpg (55.12 KiB) Viewed 2435413 times

SPI-2.jpg (57.69 KiB) Viewed 2435413 times

You will see that although I'm echoing the received value back out, the value on the MISO line is one value below that received. This is because although the SPI is duplex, data is only clocked in/out under Master control. When the Slave receives a byte (e.g. 1) this is then passed to the buffer ready to be sent back to the Master. However transmission only takes places as the Master "clocks". The Master clocks data in and out so in the examples, the Master will receive the "echo" only when it clocks out the next value.

In the above examples the Slave has an interrupt set to trigger on SSP1, but not every chp has this feature (your intended targets do not).

In the next chart, we don't use the SSP interrupt, instead we interrupt on INT0 (falling edge) and this should also work on any interrupt pin. If you send this to hardware you will see that if you disconnect the SS/CS pin then the Slave count is suspended until reconnected.

SPI_Slave_1939_INT.fcfx

(13.76 KiB) Downloaded 112 times

As mentioned, the above have been tested on hardware so if they don't work on your Proteus then the problem may lie there.

Regards

[gilanetugila]

Good evening! Last night I dreamed about how to simplify the procedure for receiving byte numbers over the spi bus and end the hegemony of the flowcode program for receiving data .

The solution looks very simple, but to tell the truth, I haven't tried it yet. In general terms, the slave spi element looks like a logical "and" element. You remember that 1*0=0 and 1*1=1. Synchronization signals come to one input of this element -this is always a logical 1. Pulses come to the other input, the duration and shape of which correspond to ( 2^0 -means 2 to 0 degrees, 2^3-means 2 to 3 degrees = 8 and so on).

Next, we multiply these numbers in the controller and add them up - we get a byte number. It remains a small matter... how to do it? But this can already be done in any version of flowcode, there is arithmetic here. It will probably be more understandable from the drawings of the signals that appear when transmitting byte numbers over the spi bus.

[gilanetugila]

Continuation . It will probably be more understandable from the drawings of the signals that appear when transmitting byte numbers over the spi bus.

[gilanetugila]

Good evening! I have some positive news. I found an error in the program that caused the receiving controller to send pulses. View in the attached file.
The second news. The receiving controller started showing the receiving number. Just not the right thing. I sent the number 6, and he writes that he accepts 0, 25, less often 85, and a couple of times the numbers 1 and 95. Moreover, it receives constantly, but I do not press the button to send data. On the schematic diagram, I tried two options-the terminals of the "CS" controllers are connected to each other and the output of the "CS" of the receiving controller is connected to the minus, and nothing comes from the output of the "CS" of the sending controller. The results of receiving the data have not changed.

[chipfryer27]

Hi

I'm not sure why you seem to be trying to "reinvent the wheel".

In the above posts I provided an example of a Master sending out data, and two examples of Slaves receiving. One Slave used SSP (a feature not all chips have) and the other used an Interrupt. The interrupt example should work on any chip providing the pins are modified to suit. Your chip has inbuilt SPI capabilities so there really is no need to try and write your own.

Although written in v10 if it helps I can modify for v8?

SPI connections were as expected between the two chips in my examples, with the inclusion of an additional wire connecting the chip grounds.

Did you try the examples?

Regards

[chipfryer27]

Hi

v8 example.

SPI_Slave_MEGA8_INT_v8.fcfx

(11.69 KiB) Downloaded 156 times

Regards

[gilanetugila]

Good afternoon! I received and tried your examples, but they did not display very correctly on the 2d panel in the program. And there was also an element that I've never used and I don't know what it's "circularbuffer" for? and where do you get it in the flowcode program. Yes, you're right about "reinvent the wheel" and I've already started doing it. Remember in the last letter I wrote that the numbers 0.25.85 (mostly) began to appear on the screen of the receiving controller. I tried it today-I removed the transmitting controller and these numbers were also displayed. So this is a problem in the program of the receiving controller.

Now I'm going to try the atmega8 program that you sent on the forum.

[gilanetugila]

Good afternoon! You asked if the program written in version 10 is suitable for 8. No, it is displayed with errors and may not work correctly, but seeing the composition of the program, I can repeat it already in version 8. You can repeat the programs for the pic16f1939 chip, but what's the point-I don't have such a chip in reality and there is no programmer for it. That's why I'm trying to do something on atmega8.

[chipfryer27]

Hi

Bit busy just now but later I'll explain circular buffer and uses, but my last post was written in v8 and if you look under Project Options it is for a Mega8. If that isn't your chip just change to suit (you may need to alter pins).

However as you say, you can see the steps so can create from scratch.

Regards

[chipfryer27]

Hi

When using any form of communications the receiver needs to know exactly when the incoming data is present. If we were to just rely on a loop for example, then how can we be sure it is looking at the correct time the data is present at the pin to say nothing of actual sampling? If that works then pick me next weeks lottery numbers as whomever does this successfully is the luckiest guy around...

A better way is to use an interrupt. This way the processor can be busy doing something useful and when data arrives it will automatically branch to handle. Many types of interrupts are available including on specific pins and they can be defined further to trigger on leading / falling edge.

OK, so now by using an interrupt we know we have incoming data to collect. What to do with it now? Interrupts should be as short a routine as possible and shouldn't be interrupted themselves. A good way to store the data, for processing later (outside the interrupt) is to use the Circular Buffer component. The WiKi has good explanations / examples.

Basically the CB is a First in First out (FiFo) buffer. It's a great component. In the example when the interrupt is called it captures the incoming byte and then stores it in the CB before exiting. Now we won't miss any incoming data.

Within Main we can test the CB to see if it contains any data and if so extract it byte at a time, or we could look for a specific value or sequence held within and act if present. It really is a very useful component.

Hope this helps explain its use in the example.

Regards

[gilanetugila]

Good evening! Yes, you are right to guess which pulse will be read, and which one cannot be missed, especially since it is assumed that the data will be displayed on the indicator, and there a delay of 100-200 ms is needed so that the inscription does not blink. I tried the program, installed my lcd 1602, but the program does not compile with the "slave spi" module, I send a screenshot from the screen. I've had this before when I tried to use this module.

[chipfryer27]

Hi

I compiled to Hex and got different results. For me

SPI_Slave_MEGA8_INT_v8.c:(.text.FCM_SPI_Slave+0x2): undefined reference to `FC_CAL_SPI_Slave_RxByte_1'
SPI_Slave_MEGA8_INT_v8.c:(.text.FCM_SPI_Slave+0xc): undefined reference to `FC_CAL_SPI_Slave_TxByte_1'

seem to be the problem.

Not sure why though. I'll redo. My database is fully up to date is yours?

Regards

[chipfryer27]

Hi

I started to create a chart from scratch, testing as I went (saving to Hex).

All went well until I used the SPI_GetChar component macro. This then failed to compile with

C:\Users\user\AppData\Local\Temp/ccftAoPc.o: In function `__vector_1':
v8_SPI.c:(.text.__vector_1+0x22): undefined reference to `FC_CAL_SPI_Slave_RxByte_1'

Regards

[chipfryer27]

Hi

In the pervious chart I posted, the one using interrupt INT0 on the PIC1939, I changed the target to a Mega8, moved display to PortC and successfully compiled to Hex.

This suggests a possible issue with the v8 Slave Component. Unfortunately as v8 is a bit old now it may no longer be officially supported.

Have you thought on upgrading to v10? All components are free as are many chips.

Regards

[gilanetugila]

Good afternoon! Yes, I was updated about 1-2 months ago. To upgrade to version 10, is it necessary to pay 75% of the cost of the program, or are there options for a free upgrade to version 10? And about the problems with the "spi slave" module, I wrote at the beginning of the discussion. Could you write down which variables and how they are called you used in your recent examples? I will try to make a program for receiving data over spi using the "master" and "CircularBuffer" modules. I'm asking because I imagine the "CircularBuffer" module very roughly, so I'll have to make a program based on yours-add code to display data on the lcd, maybe it will work.

[chipfryer27]

Hi

I'll reply in more detail later, but regarding FC v10 this link will explain things further

https://www.flowcode.co.uk/

All components are now free as are certain chips, and I believe there is a discount too for existing users, but you would be best to contact Matrix directly for specifics.

Regards

[gilanetugila]

Thanks, I followed the link, but it says "try it for free". It's like everything will work visually, but if you make a program, it won't work in real life or in a simulator. I don't have the opportunity to purchase it yet. Then maybe sometime. Although there are interesting modules there that I don't have.