{"id":2333,"date":"2025-04-15T10:28:29","date_gmt":"2025-04-15T10:28:29","guid":{"rendered":"https:\/\/webprojects.cloud\/wordpress\/splatco\/?post_type=spl_knowledgebase&p=2333"},"modified":"2025-06-10T07:58:11","modified_gmt":"2025-06-10T07:58:11","slug":"iistrfind2-bbnnc-d29","status":"publish","type":"spl_knowledgebase","link":"https:\/\/webprojects.cloud\/wordpress\/splatco\/knowledgebase\/programming-reference\/instructions-arranged-by-function\/communications-instructions\/iistrfind2-bbnnc-d29\/","title":{"rendered":"iiStrFind2 bb#,nn,c [D>=29]"},"content":{"rendered":"\n

Match a string in\u00a0RAM<\/a>\u00a0to a table in\u00a0NVEM<\/a>.\u00a0This is subtly different to<\/em> iiStrFind<\/a><\/code>, which uses a different table format<\/em>.<\/p>\n\n\n\n

Consider an Xwire receive data block to be nn<\/code> bytes of RAM starting at address bb<\/code>. This instruction seeks to match the data in the block with one or more “canned” strings stored in NVEM.<\/p>\n\n\n\n

If argument c<\/code> is zero, the instruction treats upper and lower case letters as equivalent. If c<\/code> is non-zero, the case of the RAM string must match exactly the string stored in NVEM.<\/p>\n\n\n\n

The data in NVEM must be stored in a very specific Count\/Data format. This is best illustrated by an example. Lets say we want to detect which fruit has been requested via an Internet interface and transferred into an Xwire receive data block.<\/p>\n\n\n\n

1. NVEM: Message list<\/h6>\n\n\n\n

First you construct a list of all possible receive strings in NVEM. Each string must be preceded by a byte containing the length of the string itself.<\/p>\n\n\n\n

strOrange:      NV0Byte   7,\"Orange\",13\nstrApple:       NV0Byte   6,\"Apple\",13\nstrBanana:      NV0Byte   7,\"Banana\",13\nstrLemon:       NV0Byte   6,\"Lemon\",13\nstrPear:        NV0Byte   5,\"Pear\",13\nstrGrape:       NV0Byte   6,\"Grape\",13\n;   Byte count ___________^<\/pre>\n\n\n\n
2. NVEM: Pointer table<\/h6>\n\n\n\n
Next you construct a table, in NVEM, of pointers to the individual strings. This must be terminated in two 255 bytes. The 255s tell iiStrFind2<\/code> that it has come to the end of the table.<\/p>\n\n\n\n
FruitNames:     NV0Ptr    strOrange\t;Entry #1\n                NV0Ptr    strLemon \t;Entry #2\n                NV0Ptr    strApple \t;Entry #3\n                NV0Ptr    strPear  \t;Entry #4\n                NV0Ptr    strBanana\t;Entry #5\n                NV0Ptr    strGrape \t;Entry #6\n                NV0Byte   255,255      ;<<<<< Essential!!!<\/pre>\n\n\n\n
You will notice that the order of entries is different to the order of the strings themselves. They can be in any order you like. You can have several such tables, with different ordering. You can even use different sub-sets of strings at<\/p>\n\n\n\n
3. Code: Wait for a message string<\/h6>\n\n\n\n
Before trying to extract or recognize a string, you must know that a string has actually been received. How you do this will depend on the particular source of the data that is being stored in RAM. We cannot therefore provide such detail here. (See\u00a0ComRx_StrFind2<\/a><\/code>\u00a0to see how it’s done for serial data). Here we’ll just have example code for defining the Rx data block.:<\/p>\n\n\n\n
XWRxBlock\tdefBYTE\t30\nXWRxBlkLen\tEQU\t\t30<\/pre>\n\n\n\n
4. Code: Find a string match.<\/h6>\n\n\n\n
This is where we use the actual iiStrFind2<\/code> instruction. First we have to make sure the NVEM access is correctly set up.<\/p>\n\n\n\n
                NVSetPtr<\/a>    FruitNames
                NVSetPage   0           ;0 is the default, so playing very safe!
                LoadI\t 0\t\t ;Start the search at the start of the buffer
                iiStrFind2  XWRxBlock,XWRxBlkfLen,0<\/pre>\n\n\n\n
5. Code: Evaluate the result.<\/h6>\n\n\n\n
The iiStrFind2<\/code> returns its result in X<\/a><\/code>, as follows:<\/p>\n\n\n\n