SPI

[mdietinger@gmail.com]

Is SPI already supported?
If yes would you have an example how to use it?
I am trying to connect an RC522 RFID reader to z-uno.

[PoltoS]

Yes, SPI is supported. Please use 2.0.4 C++ test version. Here is the header file: https://github.com/Z-Wave-Me/Z-Uno-Core ... zuno/SPI.h

You need to include SPI.h and use it pretty like in Arduino.

We will release 2.0.5 next week. I stringly suggest to switch to it as it has some bug fixes.

[A.Harrenberg]

Hi,

@mdietinger: Did you try using the SPI with the RC522?
I am also trying to use the RC522 but can't initiate anything on the SPI... The documentation for SPISetting is missing on the webpage, so I can only guess that the defaults are the same as in the Arduino SPI library. I have use a simple RFID-library on an ATMEL and it worked, converting the code to ZUNO doesn't work for me...

I am using pin "0" SCK, pin "1" MISO, pin "2" MOSI and pin "8" SPI CS, and additionally pin "7" for RST of the 522.

The code seems to freezes in loop() at the first call to SPI...
Analysing the signals with my logic analyzer does not show any clock signal and MOSI/MISO are high all the time. Just the CS is reacting, nothing else...

@PoltoS: Is there an example available for the SPI? Even a non fully functional example would be helpfull for me...

Regards,
Andreas.

[mdietinger@gmail.com]

Yes tried and failed.
Parked it as I had other priorities.
Would be great if a RC522 library like : https://github.com/miguelbalboa/rfid could be ported to Z-UNO.

[A.Harrenberg]

Hi,

I made some slight progress, there is some communication ongoing on the SPI, but I got no sensfull responses from the RC522.

I started with another very small RC522 lib to make it running at first... I also have the library you mentioned here, but have not analysed the code yet.

Maybe I take a step back and just see if the SPI is running w/o problems and then directly switch to this library as it is the "standard" implentation...

So far I have some trouble calling the SPISettings function, I made a workaround but I am not fully sure that it works...

It seems that the initialisation of SPI and the RFID code take VERY long time, so I assume that there is some problems with timers or even with some interrupts from the ZUNO low-level implementation that interfere here.

I will post updates when there is some more news...

Regards,
Andreas.

[A.Harrenberg]

Hi,

some small update, but no real progress ,-(

The data send out to the RC522 seems to be more or less ok (for a while), i am not sure about the first data sent and there is something strange after a few some transmissions...

My logic analyzer does not recognize a valid frame in the first data, however the pulses are there and the data at MOSI is correct. It might be a problem with initialization or also a problem with my logic analyzer...

I have put several serial.print() calls in the library to see what is send and received to compare that to the output from my logic analyzer. After a few transmissions the serial monitor stops, windows make the "device disconnected sound", the red LED on the ZUNO is blinking once and from that moment the serial monitor is dead and there are no more serial transmitts. There are a few more "disconnected" sounds and then the green light of the ZUNO also stops blinking...
As long as there are still the "disconnected" sounds and the red LED blinking, there are sill signals on the SPI bus, after the green light stops blinkinge there are also no mor signals on the SPI bus.

I am not sure if the serial communication is maybe using (the same?) interrupts internally and that is interacting with the SPI code, there is this UsingInterrupt/ function, but I don't understand the description at all.

After the last successfull transmissin the SPI-Enable going HIGH and then LOW again, but there is no CLOCK signal generated any more... After that the SPI-Enable just do another HIGH/LOW pulse and that's it...

I will try to find the line of code that write the last successfull data and try to understand what happens next...

Keep you updated,
Andreas.

[A.Harrenberg]

Hi,

I deactivated all serial debug code and powered the ZUNO externally, now there is much more traffic on the SPI! It seems that a RFID card is now recognized, but then the ZUNO hangs just BEFORE a change I made to the library...

I will try to use Serail0 for debugging, if that does not work I will try with my OLED...

But it really looks like that the serial code has some very strange issues.

Regards,
Andreas

[A.Harrenberg]

Hi,

I tested now with Serial0 on pins 24/25 and it is more or less the same behavior, the ZUNO hangs/reset after a few transmissions... If I deactivate serial communication it runs for a longer period but for the moment I can't say where it stops/crash. I will connect my OLED on this ZUNO and try using that for debugging...

Regards,
Andreas.

[A.Harrenberg]

Hi,

I haven't tried with the OLED yet, but I did some more analysis with the logic analyzer. It really looks that the ZUNO is crashing during a function call that runs good for several times before...

If there is no card at the reader, two different "packets" of data are transmitted on the SPI like A-B-A-B-A-B.... As soon as I put a card at the reader the transmission stops after the first 5 transmitts of Packet "B", so in the middle of a transmission, and the ZUNO performs a reset, sometimes it just hangs and is non-responsive...

I can't find anything wrong within the code that is performed during that time. If I just let it run without presenting a card at the reader it will also freeze after some time. I will try to get a measurement for this also to see if it dies at the same position in the transmission but I expect it to be like that.

I am running out of ideas here what could be the issue...

Regards,
Andreas.

[droll]

I have found 2 problems with the current SPI implementation (2.0.6 and 2.0.7):

• The lowest frequency that I was able to make working was 1MHz (1000000). For lower frequencies no frame was generated. I tried with 100kHz, 500kHz and 800kHz.
• The CS/SS line is not generated automatically. It needs to be generated with 'digitalWrite'.

A functional simple example that generates SPI transactions is:

Code: Select all

#include "SPI.h"

void setup() {
	SPI.begin();
	pinMode(8, OUTPUT);                   // CS/SS pin direction
	digitalWrite(8, LOW);                 // CS/SS pin level
}
 
void loop() {
	SPISettings spi_settings = SPISettings(1000000, MSBFIRST, SPI_MODE0);
	SPI.beginTransaction(&spi_settings);
	digitalWrite(8, HIGH);                // CS/SS pin level
	//delayMicroseconds(1);               // No need to add extra delay, the core is sufficient slow ;-)
	SPI.transfer(0x55);
	//delayMicroseconds(1);               // No need to add extra delay
	digitalWrite(8, LOW);                 // CS/SS pin level
	SPI.endTransaction();
	delay(1000);
}