Hello,
Seems that you misundersand me....
>>>I know that I will firstly produce CRC16 of input string to be matched , then I can index it via table (but as it is 2 bytes table will need 65535 entries ) or compare one by one all CRC codes precalculated for strings to be matched and stored as constants in ROM .
No... I didn't mean that. I have CRC16 calculator, so I can easy calculate (by hand or with program) of all desired strings the CRC (CRC16 calculator is somewhere posted in electroda like file). So, if I have to search within 300 strings, I need 300 16 bit words = 600 bytes!!!! No one of the known algorythms can produce such compact and quick compare.. no one!
>>>I ment that the CRC code computed for one string (let say "+CMTI" unsolicited response in your appl) is not unique and there could be other string which gives exactly the same CRC code . If this string
(which has the same CRC has code as the
registered in hash table "+CMTI" string)
is not in the hash table , output from CRC function will point to the +CMTI string .
I know what you meant... but the possibility 2 strings to have same CRC16 is exactly 1/65000. If you use CRC32 practically you'll never have problems.
>>>Another question ,does CRC16 algorithm perfectly distribute all GSM Modem AT response strings into unique key's and if there are collisions ,how many collisions you have for all GSM Modem response strings?
No one... I never had problems. I used AT89C2041 to track over 60 responses with very different lenght. In addition this was on 12 MHz (1 MIPS) - no one algorythm was able to do this in such compact volume. I tried everything in vain - the processor was too slowly (and we had not to change it).
As I told you, it's very crazy approach - but just try it. For me it works great - I never had problems... I don't compare the strings, I don't gather the string in memory (no buffer required), I don't keep the etalons in memory.... what you wish more?... maybe one beer
Regards
Luben