Parsing a Record File

Here is a converter to convert it to a binary file, if that helps:

http://www.keil.com/download/docs/10.asp

The problem is how to read from file (Ex: i have 134567 but i just need 345 ) and then turn it into a number type not string.

It depends on what language you are using. First, you have to parse the string to extract "345". In C/C++ conversion from string to number can be done as shown here.

Number System Base Critical to Code Writing

345 is ambiguous and requires one to know the base of the number system to be able to generate an accurate binary number. From Rixter's formats, most of the characters in the records are hexadecimal(base 16) numbers which typically come in two character(per represented byte) pairs. To turn a hexadecimal 0345 into a binary number you do this:

16x16x16x0 + 16x16x3 + 16x4 + 5

Had the characters representing the number been decimal you would do this:

10x10x10x0 + 10x10x3 + 10x4 +5

So, you must be sure what base your characters are in to translate them into a number. This has a significant impact on the code you will need. For hexadecimal you will also need to convert A's to 10, B's to 11, C's to 12, D's to 13, E's to 14, and F's to 15 if you encounter them in your character string numbers. I see some of these characters in your first S1 example record. If this is an academic exercise then I am sure that your grader will be checking to see if you understand number system bases. Just getting the code from somewhere else will not help you to learn this important concept. This is a concept which you apparently have not yet managed since 345 might be any base (six or ten or sixteen or any base higher than five) and you have asked for someone to give you code to convert it to a number. The number would be different for each different number system base your champion might implement.

Just one example of a single S1 record is also an inadequate description of this problem if your program needs to absorb and translate the whole file. Rixter's links to format descriptions of record types S0 through S9 are pertinent to any truly useful program to deal with this data. Your post leaves out essential information regarding the high level coding problem to be solved. I suspect that you might also want to actually do something with the information described using this data format. If you translate the number character strings as decimal numbers when they are really hexadecimal then the result will be wrong and any Motorola radio control function will run amok using such code. GA to Rixter for recognizing the (very probable) origin of the data format from the single record sample and the file name.

thewildotter

That's a good point, the numbers are in hex. In C, you can extract with sscanf using the "%x" to specify that the string is to be interpreted as hex.

https://www.tutorialspoint.com/c_standard_library/c_function_sscanf.htm

Look at this

There are 42 characters. You can guess that the data is sixteen two character hexadecimal bytes

I'm guessing that the first eight characters are the address and the last two are CRC.

Examine subsequent addresses for sequences: it may be that the address is only 11300, the first data byte is 00 and the CRC is 7C2A.

When you've figured out the structure; just import the file into a spread sheet two characters wide per column; then you can easily cut and paste the data into another file and use the spread sheet to convert it to decimal ( use Hex2Bin() ).

Self Flagellation All the Way to the NUL, Doh !

Rixter's format links describe the real format. It is a bit different from your guess. The s1 is the opcode, the 13 is a hex length which converts to 19 bytes which when represented in hex takes 38 characters beyond the length field. No need to guess when the format is described. Note that beyond s1, the s2,s3 details take a little more digging into Rixter's links but they are there. The record organization can also be gleaned which involves more s# records to decode. The OP should read all the provided documentation with considerable care before writing much code unless delay, pain, and suffering is viewed as character enhancement.

The Rixter %x pseudo-I/O on a string is a major time saver for the OP. As I recall there are some issues with stringrange using that technique which is a ditch that may require some care to avoid. In general, it is wise to put recognizable junk past the end of the real stuff in the source string to make debug easier ala sourcestring = strcat(sourcestring,"gggg") . Then you can be vigilant for 'g' characters in your debug to perceive running off the end of your input rather than wondering what put those seeming random unprintables(like \0) in your variable values. Notice I chose one past a valid hex character('G' is 'F' plus one and 'g' with its descender is easier to spot in a page full of poorly formatted debug droppings than 'G') so that hex conversion might fail earlier which is better than later.

C has that insane NUL character string termination rather than using a length field so you can shoot off in all directions, fetching lots of stuff until you encounter a NUL. What a major programming language architectural blunder ! In C++ and many other languages(perhaps even a 'C' struct but without methods, somewhat awkwardly) you can define varying length string objects with a pre-allocated length field as part of the object. Since length(string) is THE most common string operation, it behooves an architect not to require fetching the entire string to return a length(string) value. But no, they have to do it using nearly the worst conceivable concept. Also, strstr() is not reentrant so parsing cannot be nested without contortions. This ugly wart is also driven by choosing to use NUL terminated strings. NUL terminated strings has even infected hardware with some processors doing perverse things to reduce the time required to return the current length, abeit not by very much since once you have to engage in a fetch-fest your cache sizes usually get blown out. "NUL hurts sooo goooood." -- Some Anonymous TechnoFlagellate

thewildotter

Use a binary convertor

You need to use convector