some problems with spi data transmission

[chipfryer27]

Hi

No, it is totally free and will work both in simulation and hardware without time limit.

Included are certain chips, but you may need to purchase "chip packs" if the free options don't meet your needs.

Do note that although "free", if you intend to sell or otherwise commercialise your code then you would need a professional license.

Hope the above helps to clarify.

Regards

[gilanetugila]

Good evening! Now I tried to accept data from the modified program, where I put the "master" module instead of the "slave" module. There are no changes for the better. This "master" module generates pulses on all pins of the spi bus, except the miso pin.
But we had such a result before, only now the pulses on the "cs" pin are a positive pulse, and on the "mosi" pin the pulses are similar to the pulses on the "clk" pin. And when I send data, the pulses from the transmitter add up to the pulses of the receiver on the "cs" pin, on others it seems to be fine, but the signal walks in time. There are no data reception labels on the lcd display.
But I noticed a good feature: when you send data through an interrupt, you pressed the button-the signal appeared on the oscilloscope (it concerns the pins "cs, mosi, clk" and you do not need to look for it on the oscilloscope monitor, how long do you hold the data send button, the signal on the oscilloscope is visible for so long.
Apparently, we have gone through all possible options for using the "master" module in data reception mode, so it does not work-a negative result, this is one step closer to a positive one...

[gilanetugila]

Good evening! Thanks, I'll try to download it, I won't try it yet, except on the spi bus, when I try all possible options here on version 8. What if it works here?

[chipfryer27]

Hi

In my tests the button on the Master was a "one-shot". When pressed it would send a single value then wait for the next press. Once confirmed that all was well I modified to send a few random values.

The traces were captured using a Logic Analyser and depending on settings can sample from a few microseconds to tens of seconds.

At the Slave, as interrupts are employed along with a Circular Buffer, there wasn't much else to do. Once the interrupt routine was called it placed the incoming value(s) in the buffer to be processed in the Main loop.

In the SPI component properties you can set clock polarity (resting state High or Low) as well as a few other parameters. It is important that both Master and Slave devices use the same settings. If you are creating both Master and Slave you can use any format you wish (Idle High or Idle Low). Same goes for CS/SS with many third-party devices idling high.

You will not achieve much if you have both devices set as Master though.

As mentioned in an earlier post, v8 is now an old version and unlikely to receive much in the way of official support. Also your target device (Mega8) is an old discontinued chip too so there probably really isn't much appetite to investigate. Moving to Flowcode v10 and one of the newer free chips would most likely be better in the long run.

Regards

[gilanetugila]

Good afternoon! Yes, you are right about the fact that atmega8,16,32 production has stopped. I read about it, but they say that for now they will produce the same chips, but with the letter "A".
As for the study of "outdated" chips-atmega8 -everything in this world is "relative", let's take some branches of the railway in England, with trains from the 60s that use 3 rails. I used to think this was some kind of technical know-how, and then I read that this is a technology from the 60s, which is still being used normally. As they say, why shoot a horse if it can pull a cart, but there is no car yet. The same will happen with atmega 8,16,32 controllers. They will be studied, exploited, and designed for them until the reserves run out.
And it's not that I'm "stuck" with this atmega8, but that using the flowcode program it's not possible to receive data over the spi bus for MOST controller names. At least today I will switch to receiving data over the spi bus using some kind of "pic" controller (except for those latest modifications that you wrote about), but the program will not work here either, otherwise this topic would have been closed at least 3 years ago. On the other hand, the developers described the process of receiving data over the spi bus and framed it in the form of examples in the "help" menu.That is, they had it working, but I didn't. There are 4 options here: 1) someone is lying, 2) I am ignorant 3) someone made changes to the flowcode program and it stopped working properly.(different people worked in all versions of the program, conflict of interest, incorrect legal support of the program) 4) not known.
In the near future I will watch a video on this topic, I will try to repeat someone's successful experience using c code.

[Benj]

Hello,

Trying to play catch up here but please can you send me your latest Master and Slave programs and I'll have a dig in and see if I can find out what's not working for you.

[chipfryer27]

Hi

but that using the flowcode program it's not possible to receive data over the spi bus for MOST controller names

Sorry, but I have to disagree.

You are having issues with a Mega8 using v8, issues I have also identified. However I have also given examples of using two other microcontrollers in Master / Slave configuration that work in hardware, and I've no reason to believe that the Mega8 v8 example wouldn't work using v10. I don't recall reading anything about you using any other chip in hardware therefore it is a bit of a stretch to make the claims that you do.

I have even provided traces showing the transfer, Master to Slave and Slave to Master (MOSI/MISO).

With Flowcode it is a simple matter to change your target chip to anything you have. What other chips have you tried? If let me know which ones you have and I can probably assist further.

Regards

[gilanetugila]

Good evening! I am sending you the latest programs that I have worked with on a homemade mock-up.

As for using other chips to receive data, I will leave this for later, when I have exhausted all possibilities for using atmega8 to receive data over the spi bus. I'm still working on it, I won't be available for a while.

Program name :"SPI_Slave_MEGA8_INT_v8_lcd1602_master" -for receiving data.
Program name: "test_send_spi_push_mom-inter_8MGr_soft"-for sending data.

I tried it on a homemade board:1) connect the cs pins between the two controllers and the wire to the "int0" pin, 2) do not connect between the cs pins -but only connect the cs output of the transmitter with the "int0" controller pin, "-" was applied to the cs output.

[chipfryer27]

Hi

Can you provide a sketch of your connectivity?

Alternatively something like this

Master - Slave

Pin x (MOSI) - Pin x
Pin y (MISO) - Pin y
etc
etc

There may be an issue with connections as your previous traces did show as expected.

Regards

[gilanetugila]

Good evening! I'm not sure exactly, but it seems there was such a connection as in the attached picture. I just rewired the circuit a bit and tested other programs. If it is very necessary, I will test the programs that I sent you again, write to me.

[gilanetugila]

Good evening! one of my friends posted a video where he sends and receives data in the flowcode program, it didn't work from the beginning, then corrected some values and it worked. But it has no indicators. The orientation is that the program works only on waveforms .How data reception is determined-some number is sent there, and when it is received, +1 is added to it and sent by the "miso" output. Unfortunately, I couldn't redo it so that the number was displayed on the LCD screen.

[gilanetugila]

Good evening! and there is a program with positive clk impulses. The previous and this program have clk pulse back-edge synchronization.

[chipfryer27]

Hi

I think I might have an Uno board somewhere, running a 328 which is similar. If so I'll run a couple of tests.

Regards

[gilanetugila]

Good afternoon! Yes, that's for sure! that video lesson was made for atmega328p, I converted it to atmega8.But I tried to use the button to send and the indicators-it doesn't work, it doesn't work. I tried to trim the program so that it sends only one number and without receiving, it also does not work as it should-there is a constant sending of "clk" pulses-a continuous stream and "mosi" are also generated, but there are no signals on cs.

[chipfryer27]

Hi

Sorry to be brief, just heading out.

I didn't see a constant stream of clock pulses, I saw a burst which is what I would expect.

When CS/SS goes low and the Master initialises communications it supplies a clock and sends out a byte with a clock pulse per bit. If no more bytes are to be sent then the clock stops and the CS/SS return to high. If more bytes are to be sent the the clock continues, per byte until complete, then CS/SS returns to high.

There is still the problem of compiling using v8 that isn't apparent in v10 though. If I attempt to use either SendChar or GetChar it fails to compile. I don't know the chips well enough to know the differences between the ATMEGA8 and it's successor chips such as the 328 that can be found in Nano / Uno etc but they may be close enough.

Regards

[gilanetugila]

Good evening! probably the problem with compilation is due to the fact that it is not a professional license-I can compile it for you so that you can see what is happening there, just write which chips (boards)you use it to send and receive data.
It was possible to edit the file for sending data a little, it works fine. You press the button, the data is sent (only clk pulses are negative), the number that you sent appears on the LCD indicator (this time in decimal format).I edited the reception program, but it is not known what is happening there-there is nothing on the indicator.

[chipfryer27]

Hi

That's interesting to hear.

My issue isn't to do with licensing and I can compile when using v8 with an ATMEGA8 target and a SPI Slave component, but if I then include either the GetChar or SendChar then compilation to Hex fails.

Does the above work for you?

I'm reading up a bit more about the Mega8 and the 328 chips.

Regards

[gilanetugila]

Good afternoon! You are absolutely right about the knowledge of controllers and programs for working with them, I am not trying to challenge your authority in this area, most likely I misunderstood your message. As for the "slave" element, I also can't compile with it.

[chipfryer27]

Hi

I have been reading up a bit. With regards to the Uno R3 which uses the 328p (which should be compatible with the 8') it has SS/CS on pin B2 and this cannot be remapped and is required by SPI to sync.

This pin however is part of Interrupt On Change (IOC) but is port based rather than pin. Also it can only be set to trigger on both edges.

So you could perhaps set up an IOC on Port B

In the ISR immediately have a decision testing $B.2
If B.2 doesn't = 0 then Exit
If $B.2 = 0 then in that branch perform your SPI Rx routine.

Now, if the CS/SS pin changes from high to low your SPI Rx routine will capture data. If it transitions from low to high, or any other Port B pin transistions, it will be ignored.

I have an Uno R3 somewhere so I'll test this when I get a chance.

Regards

PS
Of course you could create your own custom interrupt for B.2 as an alternative

[chipfryer27]

Hi

OK, the attached chart has been tested on an Uno R3 which uses a 328p chip and I believe that it is compatible with your Mega8. Note that due to issues using the GetChar and SendChar component Macros in FC v8, it is written in FC v10, and as mentioned earlier FC v10 is now totally free for hobby / non-commercial use and includes the Uno R3 and Mega328 as free chips.

The chart contains a SPI Slave component and also a UART which I use for testing. The UART is connected to my PC running a terminal program and I frequently use a UART during development, sending out debug info at key points.

The chart initialises, enables an interrupt then enters an endless loop toggling the output C3. Instead of toggling C3 in this loop you could have it do something more usefull.

Note that I used a PIC as the Master simply as it was in my programmer but you can use anything as long as the the SPI settings are correct. The master simply looped counting and transmitting a byte value.

Slave SPI connections are:-

MOSI = Port B3
MISO = Port B4
CLK = Port B5
CS/SS = Port B2 (note this idles High)

SPI settings for Master and slave are:-

Master SPI
Clock Phase = Leading Edge
Clock Polarity = Idle High
Sample Point = Middle

Slave SPI
Clock Phase = Trailing Edge
Clock Polarity = Idle High
Sample Point = Middle

When the Master initiates communications it brings CS/SS Low, transmits the byte, then returns CS/SS to High.

The Slave has an IOC on Port B. This means any change on any pin on Port B will trigger an interrupt, so the first thing we do in the ISR is test to see if B2 (CS/SS pin) is Low. If not it exits.

When CS/SS is brought Low by the Master the Slave branches to the ISR and gets the incoming character. It then immediately sends out the incoming character on the UART befoe exiting. You could of course do anything you wish such as displaying the character or putting it into a Circular Buffer or Array. Choice is yours.

The screenshot below is from my PC connected to the Slave UART and you can see the incoming values being displayed.

Screenshot 2024-01-29 133258.jpg (64.81 KiB) Viewed 130947 times

This is the Slave SPI running on an Uno R3

SPI_Slave_R3.fcfx

(16.4 KiB) Downloaded 32 times

Regards

[gilanetugila]

Good evening! Thanks for your example. It may work, but I can't test it either on a practical circuit or in a simulator, and it's slightly different from what I want to get in the end. I am currently working on other solutions to the problem with receiving data over the spi bus. As soon as I get at least some result, I will write.

[chipfryer27]

Hi

The above was just an example to show that the 328p / Mega8 can be a Slave and receive data using FC components. If I remember correctly you wish the Master to send 4-bytes for the Slave to receive.

Probably an easy way to do this is using the Circular Buffer, if you know how many bytes you will be receiving.

In the Rx ISR simply use GetChar to receive the incoming byte then PutByte to store it in the CB. That's all that's needed, two instructions.

In your Main program test to see how many bytes are in the CB. If four (or whatever) then branch to process. Loop the number of bytes in CB and in each iteration you could for example use GetByte to fetch this first number and perhaps store it in the first position of an array. Each iteration will fetch the next byte and store in the next array position. You will then end up with an array containing your values at known locations that you can use for whatever.

You can of course send data back to the Master but remember the Master must clock in the bytes from the Slave.

Regards

[chipfryer27]

Hi

As I mentioned in an earlier post SPI isn't greatly suited to sending "random" information, it really needs to be in a structured format that both ends have prior knowledge about.

By that I mean if you are going to send from the Master four bytes, then the Slave needs to know to expect four bytes, and if sending from Slave to Master then the Master needs to know how many bytes to "clock in".

If I get time over the weekend I'll try to knock up a couple of examples.

Incidentally I believe the v8 issue is with the Slave Component itself as it always fails to compile irrespective of chip when GetChar/SendChar is used.

Regards

[chipfryer27]

Hi

I tried capturing a fixed number of bytes being sent.The Master side was not much issue but at the Slave things didn't go quite to plan when trying to capture an "array" of bytes being sent as one burst. Without using "C" to interact directly with registers I think it will be easier to simply use the Circular Buffer to store the incoming bytes to be processed later in the Main loop.

I'll try and post an example over the weekend.

Regards

[gilanetugila]

Good evening! It seems to me that the problem with receiving data can be solved more simply, I'm trying to do it now. Today I looked at the data sending programs again, for some reason errors began to appear-they did not exist before...The program compiles, the signals on the oscilloscope are normal, but during compilation it reports errors: :
1757: warning: passing argument 2 of 'FCI_TOSTRING'
discards qualifiers from pointer target type
1772: warning: passing argument 1 of 'FCD_04071_LCD__PrintString'
discards qualifiers from pointer target type .
An error message also appeared when you turn on the program to view how it works.