그래서 직렬 통신 구성표 작성과 관련된 문제가 다시 발생하기 시작했습니다. 타이밍 때문인 것으로 보입니다. 내 임베디드 플랫폼은 Rabbit Semiconductor BL2600이며이 경우 RS232의 장치와 통신하고 있습니다. 장치에 명령을 전송하면 장치가 BL2600으로 응답을 보냅니다. 그러면 BL2600이 처리됩니다.임베디드 장치에서 견고한 RS232 직렬 통신 구성표를 만드는 이유는 무엇입니까?
내 문제는 내가 명령을 보내고 응답을 기다릴 때마다 문제가 발생한다는 것입니다. 그러나 올바른 지점에 중단 점을 설정하고 코드를 한 단계 씩 실행하면 종종 응답을 얻습니다. BL2600과 장치 사이에 컴퓨터를 두어 RS232 스트림을 들었을 때 (초기 문제를보고 난 후), 중단 점이 있건 없건 관계없이 응답이 전송되지만 BL2600은 버퍼에서 만 볼 수 있습니다 코드를 파싱 한 부분 바로 앞에서 멈추고 시작 비트를 찾으려고합니다. 나중에 전체 문자열을 읽었을 때 중단 점을 찾으면 찾지 못합니다.
그래서 내가 충분히 기다리지 않고있는 것처럼 들리므로 우스꽝스럽게 말하면 버퍼를 최대 1 초까지 검사 할 수있는 시간 초과를 설정했습니다 (38400의 전송 속도로 더 좋은 결과를 보여줍니다). 그 창문에서), 그리고 아직까지는 아무 것도 얻을 때까지 중단 점과 단일 단계. 다음은
내 코드의 중요한 일부입니다//clear the buffers
serCwrFlush();
while(serCwrUsed())
{
;
}
startwait = MS_TIMER;
while((serCrdUsed() > 1) && (device_timeout_check < 1000))
{
if (MS_TIMER < startwait)
{ // fix the rollover
device_timeout_check = MS_TIMER + (ULONG_MAX - startwait);
}
else
{ //set it like normal
device_timeout_check = MS_TIMER - startwait;
}
serCrdFlush();
}
serCputs("mpcal=d\r"); //This is what requests the response from the device
while(serCwrUsed())
{
;
}
startwait = MS_TIMER;
while((serCrdUsed() < 11) && (device_timeout_check < 1000))
{
if (MS_TIMER < startwait)
{ // fix the rollover
device_timeout_check = MS_TIMER + (ULONG_MAX - startwait);
}
else
{ //set it like normal
device_timeout_check = MS_TIMER - startwait;
}
}
//grab it
temp=serCpeek();
i=0;
//It expects a response like "H0V0M00.0 /r"
//So I am looking for the first character.
while((temp != 'H') && (i<100))
{
serCgetc(); //breakpoint works here
temp=serCpeek();
i++;
}
c=serCread(comp_cal_string,20, 20); //breakpoint doesn't work here
나는 바퀴를 발명하는 다시하고 느낌이 있고, 사람은 아마 나보다 먼저 이런 짓을했다고, 적어도 다른 플랫폼에, 그래서 데이터가 수신되기에 충분히 오래 지연되지만 데이터를 실제로 잡아낼만큼 빠르다.
오실로스코프로 신호를 보았습니까? 적절한 범위가 없으면 이런 일을 할 수 없습니다. UART 회선에 결함이 있으면 잘못된 입력을받을 수 있습니다. 코드에서 파고 들기 전에 실제 신호가 정상적으로 표시되는지 항상 확인하십시오. – Lundin