Linux port

[hramrach]

The changes here allow running a sketch on Linux (rather than uploading it to an Arduino) and read some tags.

I tested DumpInfo and maybe one or two other sketches.

Since operating this card reader by writing random values to the SPI bus by hand proved unsuccessful so far this might be useful for other people trying to use the thing on Linux.

Two more complex sketches fail to build because I did not add code for some features in the Arduino environment emulation layer.

travis environment does not have sys/ioctl.h so all tests fail

[Rotzbua]

@hramrach Thanks. To merge this, travis has to be successful. Can you correct the the travis check?

[mdxs]

Perhaps this is better kept in another project? Since it seems to depart from the main "Arduino library for MFRC522 and other RFID RC522 based modules" goal.

[Rotzbua]

Yes, that maybe the better solution. I think this library should be still for Arduino IDE only to avoid issues.
Many boards are supported by the Arduino IDE and they implement the Arduino specific functions.

So I think I close this pr and maybe add a link to this repo in the readme? @hramrach

[hramrach]

Missing sys/ioctl.h can be only fixed on Travis.

It is present on Linux systems which I target with this port.

This is not another project. It is port of this project to run on Linux.

I can understand that you may not want to merge the port since you are focused on Arduino.

FWIW if you install libc6-dev in travis the build will probably work.

Also you may want to look at the first three patches that just fix issues with the existing code.

Thanks

[pasc-04]

hi guys im a student and new in this world, i have a doubt about this, can it uses this with python interface on an intel galileo board?

[hramrach]

There are no python bindings. There is another project which targets Raspberry PI which is written in Python. It uses broadcom-specific library for GPIO, however.

[admo]

I believe it won't work. E.g in MFRC522::PCD_WriteRegister you wrote:

	for (byte index = 0; index < count; index++) {
		SPI.transfer(values[index]);
	}

Which means that after each SPI.transfer chip-select will go off, and goes on in next SPI.transfer call. It does not meet writting multiple bytes to register algorithm (see 8.1.2.2 SPI write data).

However, it good start point to have working implementation on Linux:)

[hramrach]

The thing is that it does NOT work when using the Linux API that triggers chipselect properly and it DOES work with this bastardized sketchy implementation. Maybe there is some undocumented 'feature' of the chip that the author of the Arduino library found by trial and error captured in this code.

I don't see where in the patches I added this code so it was probably that way to start with and it may well be what is required to communicate with this chip even if it is not how SPI is supposed to be used.

[admo]

The author of the Arduino library handles chipselect properly. In this implementation this is not properly handled, because chipselect is on only during ioctl call.

When it goes to writing values to registers, two bytes (address and value) have to be send without switching off the chipselect. In this implementation chipselect goes off and on between address and value bytes. The result is that, the value is not set in register.

Below the results of the simple demo, which I run right now with MFRC522 v2.0:

    // The right way of writing register
    write_register(spi, CommandReg, 0x00); // write with one ioctl
    read_register(spi, CommandReg); // returned value 0x00 (OK)
    write_register(spi, CommandReg, 0x20); // write with one ioctl
    read_register(spi, CommandReg); // returned value 0x20 (OK)
    write_register(spi, CommandReg, 0x00); // write with one ioctl - just for reset the value
    // The way of writing register in implementation from this pull request
    write_register(spi, CommandReg); // write with one ioctl - only address was sent
    write_register(spi, 0x20); // write with one ioctl - only value was sent
    read_register(spi, CommandReg); // returned value 0x00 (NOK) - should be 0x20

It shows that writing register with flapping chipselect does not work.

I just want to warn future users:)

EDIT:
Just realized that CS line is handled through GPIO, not through CS line handled by Linu spi driver.

[hramrach]

yes, and that's the biggest difference between this library and using Linux ioctls directly. Doing everything manually takes time and the chip probably needs some delays inserted somewhere to work properly.