Bigbufferbinstable

[nitraiolo]

After exploring more deeply with @magedelfador the use of printable log format, I've come to the conclusion that with the limitation of RevE hardware it is much better to manage log in binary format on chameleon. The use of a bigger buffer is still required to avoid a card's reset, due to slow SPI write and conseguent timeout during communication with the reader. The new log implementation uses commands compatible with the RevG implementation, but not all RevG's commands have been implemented (no LOGMODE and no STORELOG).

• "LOGDOWNLOAD" is an alias for "WORKMEMDOWNLOAD" and starts a XMODEM transfer of the log.
• "LOGMEM" reports the free log memory available.
• "LOGCLEAR" clears the log and resets the logstatus to enabled.

Optional

• "LOGPRINT" prints the log in a human readable format on the terminal. This function requires some space so it's a compile option and requires some other to be disabled. Output example: 00016/02827: [00013] R | IDLE | 26 00022/02827: [00013] T | READY | 0400 00029/02827: [00014] R | READY | 9320 00036/02827: [00014] T | READY | FFFFFFFF00 00046/02827: [00016] R | READY | 9370FFFFFFFF0027D0 00060/02827: [00016] T | ACTIVE | 08B6DD 00068/02827: [00032] R | ACTIVE | 500057CD 00077/02827: [00032] T | HALT | 00082/02827: [00038] R | HALT | 52 00088/02827: [00038] T | READY | 0400 00095/02827: [00039] R | READY | 9370FFFFFFFF002750 00109/02827: [00040] T | ACTIVE | 08B6DD 00117/02827: [00048] R | ACTIVE | 500057CD 00126/02827: [00048] T | HALT |

The main goal of the logging function is the reader's analysis, so to reduce the card reset due to SPI write, I've implemented a dynamic trim function for tag data in the log. This function requires some space so it's also a compile option. There are 3 trim levels triggered by consecutive buffer flush due to fullfilment:

1. remove Tag data longer than 9 byte and mark source as "+" instead of "T"
2. remove Tag data for all tag logs and mark source as "+" instead of "T"
3. don't log anything about Tag (removes the entire "line")

To parse the downloaded binary log file I've also added the code of a simple parser under Software/LogParser with a sample.

The binary log format is very simple and has been reduced to contain the minimal overhead to be parseable:

Header

Record

To get enough space to play with logs, I had to move the previous commands about WorkingMemory in a compile option that can be disabled to save space for log functions.

[MageDelfador]

Iceman only care about AUTHOR name,don't mind this:) I will follow your branch

[ca1e]

can this reduce the size of firmware? maybe helpful for me if it is..

[iceman1001]

Hard to tell, some odd comment and silence.

[ca1e]

seems like its goal to consistent with revG log funcs, its always good to use unified commands with revG or others. after some tests for this PR, it DOES reduce some fw size by uncomment 'MF_CLASSIC_LOG_SUPPORT'

// original
Program:   32676 bytes (88.6% Full)
(.text + .data + .bootloader)

Data:       2573 bytes (62.8% Full)
(.data + .bss + .noinit)

EEPROM:       44 bytes (4.3% Full)
(.eeprom)

// binlog
Program:   32118 bytes (87.1% Full)
(.text + .data + .bootloader)

Data:       3460 bytes (84.5% Full)
(.data + .bss + .noinit)

EEPROM:       44 bytes (4.3% Full)
(.eeprom)

so I'd like to use this log func instead of old workmem funcs with my revE :) perhaps we can just keep one of them, instead of commented the old.

besides, if you can modified the pr title for more suitable content and cleanup some dirty codes, I think we can easier to accept this.

[nitraiolo]

Sorry I have some overload at work and I had no time to work on this continuously. @ca1e no this doesn't reduce firmware size sorry. Log function is quite heavy. I've tried every optimization I know to reduce his weight.

[nitraiolo]

Hard to tell, some odd comment and silence.

Sorry for late response. Have you got any question about? I'll try to explain.