Arguments error

[mnf]

Added to bugs (also in general programming at viewtopic.php?f=7&t=20135)

Sometimes basic argument handling seems to go wrong:

uart.png

(7.29 KiB) Downloaded 1908 times

http://www.matrixtsl.com
Errors when generating C source code:
LUT.c : 1 : error : Incompatible argument: UART1::SendNumber
LUT.c : 679 : error : Incompatible argument: UART1::SendNumber

Also the AppendByte function in the FAT component...


Martin

[Benj]

Thanks Martin,

I've now found and fixed the problem with the UART::SendNumber and FAT:SendByteToFile functions. I'll push these fix to the updates system in the next hour or so. For some reason the parameters had become arrays instead of singular values.

[mnf]

Thanks Ben,

The update system should really be a major plus - can the enviroment / toolchains also receive updates or is it limited to components?

Sadly this bug is still present in UART::SendNumber (as of 18:34) Updated and restarted....


Martin

[Steve]

can the enviroment / toolchains also receive updates or is it limited to components?

In the past we have rarely updated the toolchains and so these were left out of the update system. The toolchains are separate installations and we will issue patches for these when necessary.

[mnf]

Another similar query:

In the RFID (MFRC522) library (trying to convert a small test program to v8 - and much has changed )

In the MifareRead and MifareWrite macros buffer size is defined as an array of byte:

mifare.png

(32.63 KiB) Downloaded 1814 times

Looking at the code for the Read/Write macros - the code uses BufferSize[0] - but why use an array (here effectively a pointer to single byte) rather than a byte (or an int - depending on allowable buffer size?)

Martin

[Benj]

Hi Martin,

We did a lot of work in v7 to bring the MFRC522 component more up to date as we knew there were problems but struggled to get these resolved.

The library we based the component on basically got completely re-written so we had to do the same for the component. This time rather than being clever and simplifying things I simply used the library as is to save my time and sanity next time the library completely changes .

This topic should explain things a bit more in depth and provides a working example.
viewtopic.php?f=63&t=19788&p=86578#p86494

Are you still having problems with the UART component SendNumber function? I've re-tested this here and it seems ok for me using the latest update to the component.

[mnf]

Thanks Ben,

UART SendNumber now seems to accept arguments correctly...

I can't get the RFID reader to work correctly though - I see a lot of the names/functions now reflect the Arduino library (which in turn reflect the....)
Recognizes a card is present - but attempting to read 1k of data from it (as 64 blocks of 16) gives the same 16 bytes for each read (and a return value of 4 from MifareRead). I'll play some more and see if I can get things working....

Martin

[mnf]

Hi Ben,

One step forward and one back... Looking at the code for MifareRead I notice that the buffer needs to be 18 bytes long (16 + 2 crc - MifareWrite creates an extra (18 byte) buffer so needs 16 bytes...)

That leads - to MifareRead returning 3 (Timeout?) and some (4) values stored in the buffer.....

However, it only works if the SPI is set to software - hardware mode doesn't work (I've mentioned this before - but I still couldn;t give a definitive answer as to when software mode only works - and when it changes and hardware mode works. I've noticed in several projects that there is a sudden changeover when hardware mode 'suddenly' starts working) - Scratch that - I've just noticed that hardware mode seems to get 'locked' so resetting the Arduino (by pulling the plug) re-enables hardware mode.... Once it is working it seems 'hard' to lock it again - if I notice an example I'll pass it on (but until then 'Have you tried switching it off and on again' still seems to be sage advice ) (Or not - just tried adding a repeat read of a block until return is 0 - and we are back in software mode only )
Even in hardware SPI mode - I get error 3 returned from MiFare read (it is a problem with Flowcode that there isn't an easy way to document the return values such as this - so I peeked at the C and made an educated guess...)

Code is:

rfid.fcfx

(15.42 KiB) Downloaded 205 times

The hardware does seem to work AOK - tested using the Arduino library too.

Martin

[Benj]

Hi Martin,

It could be an authentication problem, might be worth following the example here more closely as this is know to work very well.

https://www.matrixtsl.com/wiki/images/9 ... Write.fcfx

The module is very complex with very little documentation regarding the protocol so it's best to follow the examples to the letter where possible.

As for HW SPI not working, this is odd and maybe needs some further attention. If you find any patterns to the problem then be sure to let us know.