问题与先前关于字符串生成器&将十六进制转换为十二月 [英] Question Related to previous posts about string builder & Converting Hex to Dec
问题描述
大家好（特别是原格里夫），
我一直在问很多关于如何解析从设备返回的字符串的问题，我现在已经想出要做什么了（我希望！）。它只是如何确切的。我现在可以正确地发送和接收低值我开始怀疑这是我打包其余字节的方式因为奇怪的事情发生了我的十六进制值，255或FF罚款，256或100的奇数事件被读取为16.
这是由于处理器在下面的行为方式是发送回复发送255我将其读回为255
Hi All (Original Griff especially),
I have been asking a lot of Questions about how to parse a string that has been returned from a device, I have now figured out what to do (I hope!). It just the exact of how. I now can send and recieve low values correctly I am starting to suspect it is the way I am packing the rest of the byte as strange things happen with the magic numbers to my hex value, 255 or FF fine, 256 or 100 is read as 16.
This is due to the way the processor behaves below is the send reply from sending it 255 which I read back as 255
0c FF 00 00 00＃0
＃3B025301 00000001 0
0c＃FF000000
0c FF 00 00 00 #0
#3B025301 00000001 0
0c #FF000000
以下是值256或100的响应
Below is the responce for the value 256 or 100
i＃3B025301 00000001 0
0c＃10000000
i #3B025301 00000001 0
0c #10000000
问题在于数据的呈现方式我坐下来的想法是（8位标题（正常）87 65 43 21读作21 43 65 87这对于低值是有意义的，因为我尝试的第一位数据是25（基数10）
87 65 43 21：回读为：我的标题是21 43 65 87
$ b $ 00 00 00 00 19（十六进制）19 00 00 00 19 00 00 00
我正在打字这个问题正在播放，发现问题在于价值的权利。问题是我解析十六进制数的方法是
The issue is with the way the data presented I sat down with the idea that it was ( 8 bit heading (normal) 87 65 43 21 read as 21 43 65 87 which makes sense for low value as the first bit data I tried it with was 25 (base 10)
87 65 43 21: read back as: I took the headings to be 21 43 65 87
00 00 00 19 (25 in hex) 19 00 00 00 19 00 00 00
I have as I was typing this question was playing and found the problem was with the right of the value. The problem is my method for parsing the hex number is
Value_Int = int.Parse(txtValueCredit.Text, System.Globalization.NumberStyles.HexNumber);
因为单位回复的字符串长度为八个字符。但是在一个奇怪的格式中，最大的数字可能是10,000 dec或2710 hex，我用一个子串切掉零线上的字符串，这可能会导致问题。
还订购字符串错误的257是＃01010000不是＃10100000
hyperTerm<< / cw 0c 01 01 00 00>> prog<<< / cw 0c 01 01 00 00>>
我想我疯了。我一直在看我认为的问题，然后发现它不是。
所以要么问题是我没有为超过255的值正确编写字符串，但这似乎纠正了问题将数字转换为十六进制并发症 [ ^ ]
或我没有正确阅读回复字符串构建器问题.... [ ^ ]
如果我手动将值设置为256，我会在＃00010000的间谍窗口中获取回声如果然后用我的软件读回来我会得到＃00010000如果我尝试用我的代码设置256我得到＃10000000或16
我想问题出在发送程序中？很抱歉，如果这个有点大并涉及Q& A问题我将其作为白板使用。
Glenn
As the unit replies with the value in a string that is eight characters long. but in an odd format the biggest the number can be is 10,000 dec or 2710 hex, I am going over the string with a sub string chopping off the zero, which could lead to problems.
Also ordering string wrong 257 is #01010000 not #10100000
hyperTerm <</cw 0c 01 01 00 00>> prog <</cw 0c 01 01 00 00>>
I think I am going nuts. As I keep seeing what I think is the problem and then finding its not.
So either the problem is I am not writing the string correctly for values over 255, but this appeared to correct the problem Converting Number to Hex with complications[^]
or I am not reading the reply correctly String builder problems....[^]
If I manually set the value to 256 I get the echo in a spy window of #00010000 If then read this back with my software I get #00010000 If I try to set 256 with my code I get #10000000 or 16
I think the problem therefor is in the sending routine ? Sorry if this is a little large and involved for a Q&A question I was usning this as white board.
Glenn
推荐答案
Glenn ，看着你的数据，我怀疑它是发送问题（和一个reciveing问题）
Glenn, looking at your data, I suspect it''s a sending problem (and a reciveing problem)
0c FF 00 00 00 #0 This is from you to the card?
#3B025301 00000001 0 Response - not sure what it decodes to exactly, but I assume "OK" with some info.
0c #FF000000 I assume this is the return?
如果是这样的话，我会发送十六进制123作为：
If so, then I would send hex 123 as:
0c 23 01 00 00 #0因为数据看起来是32位小端（而不是大端的PC，所以最低字节在RHS上）
如果是这样，它可以解释你遇到问题的原因 - 有什么办法可以检查吗？或者点击我的界面规格手册？
刚发送123 （十六进制）为0c 23 01 00 00使用命令/ cw 0c 23 01 00 00通过HyperTerm获取＃0当我用cr读取它时得到23010000（十六进制）我读入23010000我转换为00000123解析为291（dec）意思是我的阅读功能没问题。当我发送时我发送291（dec）是0c 12 30 00 00意味着我的发送错误。我需要回到字符串解析谢谢。
如果你需要的只是小端< - >整数，然后这很容易：
as the data looks to be 32 bit little endian (rather than PC which is big endian, so the lowest byte is on the RHS)
If so, it would explain why you are having problems - is there any way you can check? Or point me at the interface specification manual?
"Hi,
Just sent 123(hex) as 0c 23 01 00 00 with the command /cw 0c 23 01 00 00 via HyperTerm got a #0 when I read it with a cr I get 23010000(hex) I read in as 23010000 which I tranlate to 00000123 parse to 291(dec) Meaning my reading function is OK. When I send I am sending 291 (dec) is 0c 12 30 00 00 meaning my send is wrong. I need to go back to the string parsing thanks."
If all you need is little endian <--> integer, then that''s pretty easy:
public static string IntToLEString(int i)
{
StringBuilder sb = new StringBuilder(4 * 2 + 3);
sb.AppendFormat("{0:X2} ", ((i >> 00) & 0xFF));
sb.AppendFormat("{0:X2} ", ((i >> 08) & 0xFF));
sb.AppendFormat("{0:X2} ", ((i >> 16) & 0xFF));
sb.AppendFormat("{0:X2} ", ((i >> 24) & 0xFF));
return sb.ToString();
}
public int LEStringToInt(string s)
{
int result = 0;
string byte0 = s.Substring(0, 2);
string byte1 = s.Substring(3, 2);
string byte2 = s.Substring(6, 2);
string byte3 = s.Substring(9, 2);
result = int.Parse(byte0, NumberStyles.HexNumber) |
int.Parse(byte1, NumberStyles.HexNumber) << 8 |
int.Parse(byte2, NumberStyles.HexNumber) << 16 |
int.Parse(byte3, NumberStyles.HexNumber) << 24;
return result;
}
我可能想要进行一些错误检查，但你可能已经这样做以识别响应了。 （您可能还需要忽略返回值上的空格，但这很容易）
I''d probably want to put some error checking in, but you are probably doing that to recognise the response already. (You may need to ignore the spaces on the returned values as well, but that''s pretty easy)
这篇关于问题与先前关于字符串生成器&将十六进制转换为十二月的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
