Fast CRC library (uses the built-in crc-module in Teensy3)

Frank B · Apr 23, 2016

Ok, thank you! I don't have any AVRs at the moment. Maybe it's an endianess or other little issue, don't know.
That's why I can not do anything for it, and have to rely on pullrequests.

https://github.com/FrankBoesing/FastCRC/issues

manitou · Apr 23, 2016

for the 16-bit CRC's that are failing to validate on AVR's, i think the problem is failing to do PROGMEM read's in the prolog and epilog of the *_upd functions.
compare ccitt_upd with mcrf4xx_upd ...

and the problem with CKSUM is REV32 , need to use uint32_t
uint32_t REV32( uint32_t value)

in the benchmark example in setup(), time needs to be uint32_t

float mbs = (8.*BUFSIZE)/time;

(updated post #50 with compelling noInterrupt() evidence)

Frank B · Apr 23, 2016

Thanks.. !
Have to update the examples, still...

Do you know a way to determine the RAM and FLASh size (at compile time)?

manitou · Apr 23, 2016

Frank B said:
Thanks.. !
Have to update the examples, still...

Do you know a way to determine the RAM and FLASh size (at compile time)?

You left out the & in your read_pgm_word() updates, should be pgm_read_word(&crc_tabl...
(having all pgm_read_word() seems OK)

I don't think you can get FLASH/RAM at compile time -- you could run IDE in verbose mode, and see if any useful info is in the compiler arguments -Dxxxxx

manitou · Apr 23, 2016

OK, downloaded latest FastCRC. everything validates OK for mega2560, and examples still work on Teensy 3.2

Good to go.

Frank B · Apr 23, 2016

There are some days.. that are not good to edit anything... this was such a day

I'll do the examples later..
No way to use the -Defines without myriads of #ifdefs.
I think, I keep the T3.x "Benchmark", check for TEENSYDUINO, and print an error for others.
But I'll add the validation for devices with small flash.

Frank B · Apr 23, 2016

..and - still - my Question : Is there any important CRC missing ? I'd be happy to add it.

Frank B · Apr 24, 2016

I've added some more examples with lower Flash usage, updated keywords, and another little issue.
Most examples should work now for devices with small RAM or small Flash.

They compile OK for Teensy 2.0, but I could not test them.

stevech · Apr 24, 2016

you can at compile time get the MCU type and from that, infer the flash/RAM sizes.
In Arduino's IDE it's not easy to add #defines via the IDE.

Frank B · Apr 24, 2016

That's right.

It would be usefulful to have it. For EEPROM, it is existing.
But now, you need myriads of #ifdef (for every mcu) if you need something like this.

el_supremo · Apr 24, 2016

Frank: I've been playing with FastCRC and have been comparing its output with some online calculators.
In my copy of FastCRC_validate I've added tests for some additional CRCs at http://www.scadacore.com/field-applications/programming-calculators/online-checksum-calculator/. I don't know if they are "important" CRCs but here's the code for the additional tests I have so far.

Code:

// this uses the same polynomial as the built-in MODBUS, but it uses an initializer of zero whereas the built-in
// MODBUS uses 0xFFFF. This link gives example C code for generating a MODBUS CRC and it agrees with FastCRC.
// http://www.ccontrolsys.com/w/How_to_Compute_the_Modbus_RTU_Message_CRC
//CRC-16-IBM
  crc = CRC16.generic(0x8005, 0, CRC_FLAG_REFLECT, buf, sizeof(buf));
  printVals("IBM", 0xbb3d, crc);

//CRC-16-DECT
  crc = CRC16.generic(0x0589, 0, CRC_FLAG_REFLECT, buf, sizeof(buf));
  printVals("DECT", 0xcab0, crc);

//CRC-32C - Castagnoli
  crc = CRC32.generic(0x1EDC6F41, 0xffffffff, CRC_FLAG_REFLECT | CRC_FLAG_XOR, buf, sizeof(buf));
  printVals("CRC-32C", 0xE3069283, crc);

//CRC-32K - Koopman
  crc = CRC32.generic(0x741B8CD7, 0xffffffff, CRC_FLAG_REFLECT | CRC_FLAG_XOR, buf, sizeof(buf));
  printVals("CRC-32K", 0x2D3DD0AE, crc);

Have you looked at Table 4 in this paper? Lots of CRCs to play with, but a lot of them are probably not important

Pete

stevech · Apr 24, 2016

CRC32 is most often the ITU standard for V.42 and ANSI X.366.
Scroll down to "Specification" here, and the next section lists popular standards. The table lists polynomials and the standards define the initial value and the bit/byte order.

https://en.wikipedia.org/wiki/Cyclic_redundancy_check

Frank B · Apr 25, 2016

el_supremo said:
Frank: I've been playing with FastCRC and have been comparing its output with some online calculators.
In my copy of FastCRC_validate I've added tests for some additional CRCs at http://www.scadacore.com/field-applications/programming-calculators/online-checksum-calculator/. I don't know if they are "important" CRCs but here's the code for the additional tests I have so far.

Thank you .)
I use this : http://reveng.sourceforge.net/crc-catalogue/ as a reference.

manitou · Apr 30, 2016

Frank B said:
..and - still - my Question : Is there any important CRC missing ? I'd be happy to add it.

How about CRC-7 (poly 0x09)? used by SD card (along with CRC-16, which you have). might be needed for SDHC/SDIO support on teenys++3.1

Frank B · May 1, 2016

manitou said:
How about CRC-7 (poly 0x09)? used by SD card (along with CRC-16, which you have). might be needed for SDHC/SDIO support on teenys++3.1

Don't know.. i havn't read the specs for MK66/SDIO. I could imagine, that it does CRC7 automatically(???)
But anyway, maybe it's useful - at least for other MCUs

I've added it.
It was a bit tricky (needs some bitshifts on the T3.X 32-Bit CRC-Hardware), but fun

manitou · May 1, 2016

Frank B said:
Don't know.. i havn't read the specs for MK66/SDIO. I could imagine, that it does CRC7 automatically(???)

You're right, looking at the ref manual, the SDHC has internal CRC. (I had been looking at a generic SDHC driver, and it had table-driven CRC's).
thanks. glad it was "fun"

stevech · May 1, 2016

SDIO 1, 2, 3, or 4 bit interface?

Frank B · May 1, 2016

stevech said:
SDIO 1, 2, 3, or 4 bit interface?

From the feature-list in the manual :

- Supports 1-bit/4-bit SD and SDIO modes, 1-bit/4-bit / 8-bit MMC modes, 1-bit/4-
bit/8-bit CE-ATA devices
• Up to 200 Mbps of data transfer for SD/SDIO cards using 4 parallel data lines
• Up to 416 Mbps of data transfer for MMC cards using 8 parallel data lines in
Single Data Rate (SDR) mode

And in the next chapter:

60.3.4 Modes and operations
The SDHC can select the following modes for data transfer:
• SD 1-bit
• SD 4-bit
• MMC 1-bit
• MMC 4-bit
• MMC 8-bit
• CE-ATA 1-bit
• CE-ATA 4-bit
• CE-ATA 8-bit
• Identification mode up to 400 kHz
• MMC Full Speed mode up to 20 MHz
• MMC High Speed mode up to 52 MHz
• SD/SDIO Full Speed mode up to 25 MHz
• SD/SDIO High Speed mode up to 50 MHz

stevech · May 1, 2016

Since 1-data line SDIO can be 25Mbps and up, it's often best to use 1 or 2 lines since I/O pins are rather scarce in the Teensy 3.x. Maybe next generation (Teensy 4.x?) will have a 100 pin package or some such.

But the feature list implies one cannot use the 2,3 bit modes but rather, 1 or 4.

manitou · May 2, 2016

stevech said:
Since 1-data line SDIO can be 25Mbps and up, it's often best to use 1 or 2 lines since I/O pins are rather scarce in the Teensy 3.x. Maybe next generation (Teensy 4.x?) will have a 100 pin package or some such.

But the feature list implies one cannot use the 2,3 bit modes but rather, 1 or 4.

From Teensy++3.1 thread, Paul indicates microSD/SDHC will have dedicated embedded pins (PTE0-6) for SPI/SDIO access. I'm not an SD expert, but I think 1-bit and 4-bit modes are modes that the cards support, there are no 2 or 3 bit modes.

stevech · May 2, 2016

manitou said:
From Teensy++3.1 thread, Paul indicates microSD/SDHC will have dedicated embedded pins (PTE0-6) for SPI/SDIO access. I'm not an SD expert, but I think 1-bit and 4-bit modes are modes that the cards support, there are no 2 or 3 bit modes.

As I read/use the spec, most commonly the 1 or 4 bit modes are used, but the SDIO hardware and the standards allow for use of 2 or 3 pins. Mass market, they all use 4 pins now.
The 1 pin mode can be SDIO or SPI.

The rather new interface is eMMC used in high performance products like high end cameras.

manitou · Aug 25, 2016

@Frank B
I downloaded latest github FastCRC and ran benchmark on T3.2 @120mhz (with 16KB buffer), and I don't get 275us for hardware CRCs, rather 2168us?? I fear it's my error somehow, and i'll look harder, but has something changed with hardware CRC calculations??

tni · Aug 25, 2016

manitou said:
@Frank B
I downloaded latest github FastCRC and ran benchmark on T3.2 @120mhz (with 16KB buffer), and I don't get 275us for hardware CRCs, rather 2168us?? I fear it's my error somehow, and i'll look harder, but has something changed with hardware CRC calculations??

Are you using an old Arduino/Teensyduino version? The library is now checking for "KINETISK" being defined and it isn't there in older versions. So you are most likely using the software version.

manitou · Aug 25, 2016

tni said:
Are you using an old Arduino/Teensyduino version? The library is now checking for "KINETISK" being defined and it isn't there in older versions. So you are most likely using the software version.

I'm using latest 1.6.11 and 1.30beta3 -- FastCRC looks like it is using __KINETISK__ and not KINETISK ??

I changed lib to use KINETISK and also had to add #include "Arduino.h" in the .cpp's, and benchmark is using hardware now. Here is data for Teensy 3.6 (K66 beta) @180 mhz

Code:

CRC Benchmark
F_CPU: 180 MHz, length: 57344 Bytes.

Maxim (iButton) FastCRC:	Value:0xD2, Time: 718 us (638.93 mbs)
Maxim (iButton) builtin:	Value:0xD2, Time: 23276 us (19.71 mbs)
MODBUS FastCRC:	Value:0x25F1, Time: 720 us (637.16 mbs)
MODBUS builtin: 	Value:0x25F1, Time: 22319 us (20.55 mbs)
XMODEM FastCRC:	Value:0xB217, Time: 718 us (638.93 mbs)
XMODEM builtin: 	Value:0xB217, Time: 22639 us (20.26 mbs)
MCRF4XX FastCRC:	Value:0x4BE4, Time: 718 us (638.93 mbs)
MCRF4XX builtin:	Value:0x4BE4, Time: 3827 us (119.87 mbs)
KERMIT FastCRC:	Value:0x9137, Time: 718 us (638.93 mbs)
Ethernet FastCRC:	Value:0x29C6653B, Time: 720 us (637.16 mbs)

Frank B · Aug 25, 2016

manitou said:
I'm using latest 1.6.11 and 1.30beta3 -- FastCRC looks like it is using __KINETISK__ and not KINETISK ??

I changed lib to use KINETISK and also had to add #include "Arduino.h" in the .cpp's, and benchmark is using hardware now. Here is data for Teensy 3.6 (K66 beta) @180 mhz

Code:

CRC Benchmark F_CPU: 180 MHz, length: 57344 Bytes. Maxim (iButton) FastCRC: Value:0xD2, Time: 718 us (638.93 mbs) Maxim (iButton) builtin: Value:0xD2, Time: 23276 us (19.71 mbs) MODBUS FastCRC: Value:0x25F1, Time: 720 us (637.16 mbs) MODBUS builtin: Value:0x25F1, Time: 22319 us (20.55 mbs) XMODEM FastCRC: Value:0xB217, Time: 718 us (638.93 mbs) XMODEM builtin: Value:0xB217, Time: 22639 us (20.26 mbs) MCRF4XX FastCRC: Value:0x4BE4, Time: 718 us (638.93 mbs) MCRF4XX builtin: Value:0x4BE4, Time: 3827 us (119.87 mbs) KERMIT FastCRC: Value:0x9137, Time: 718 us (638.93 mbs) Ethernet FastCRC: Value:0x29C6653B, Time: 720 us (637.16 mbs)

If something is wrong pls make a pullrequest. Im not at home, can not test it, but i can merge it.

Fast CRC library (uses the built-in crc-module in Teensy3)

Senior Member

Senior Member+

Senior Member

Senior Member+

Senior Member+

Senior Member

Senior Member

Senior Member

Well-known member

Senior Member

Well-known member

Well-known member

Senior Member

Senior Member+

Senior Member

Senior Member+

Well-known member

Senior Member

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member