From last time, I am still working on interfacing an RFID reader module and FEZ Cobra. I’m on the part of making the FEZ Cobra read the reader module, but after all initializations, Cobra says, “waiting for debug commands” after executing the clear tag buffer command.
do {
UART.Write(clrtagbuf, 0, clrtagbuf.Length);
Thread.Sleep(650);
read_count = UART.Read(rx_data, 0, rx_data.Length);
if (ByteArrayCompare(rec_clrbuf, rx_data))
{
Debug.Print("Cleared tag buffer");
lcd.ShowMessage("Cleared tag buffer");
}
else
{
Debug.Print("Tag buffer not cleared");
lcd.ShowMessage("Tag buffer not cleared");
}
Thread.Sleep(650);
for (int x = 0; x < read_count; x++)
{
Debug.Print("Tag Clear Byte:" + rx_data[x]);
lcd.ShowMessage("Tag Clear Byte " + x + ": " + rx_data[x].ToString());
Thread.Sleep(100);
}
UART.Write(readmult, 0, readmult.Length);
Thread.Sleep(200);
read_count = UART.Read(rx_data, 0, rx_data.Length);
for (int x = 0; x < read_count; x++)
{
Debug.Print("Readmult Byte:" + rx_data[x]);
lcd.ShowMessage("Readmult Byte received:" + x + ": " + rx_data[x].ToString("X"));
Thread.Sleep(500);
}
UART.Write(gettagdata, 0, gettagdata.Length);
Thread.Sleep(650);
read_count = UART.Read(rx_data, 0, rx_data.Length);
for (int x = 0; x < read_count; x++)
{
Debug.Print("Received from Read Byte:" +x + rx_data[x]);
lcd.ShowMessage("Received from Read Byte" + x + ": " + rx_data[x].ToString("X"));
Thread.Sleep(500);
}
}while (!(read_count==0));
UART.Close();
In addition to that, at first, I did debugging… and since I have to disconnect FEZ on my computer (my computer powers up FEZ in turn powers up M6e but needs more than an 1A of current to read, probably the reason why it stops after clearing buffer), I used M63 devkit to power up FEZ, but still it shows the same. I did re-deploy the program, however, it still gives the same output.
Can you confirm, your code proceeds PAST this point and then says “waiting for debug”?
if (ByteArrayCompare(rec_clrbuf, rx_data))
{
Debug.Print("Cleared tag buffer");
lcd.ShowMessage("Cleared tag buffer");
}
That’s really strange, I think that means you have an unhandled exception that’s crashing the CLR. It’s highly possible that your problem is power related since you are talking about 1A (which I am sorry, I didn’t fully understand what you meant in that last post).
Having timing dependancies in UART code, as demonstrated by the inclusion of Sleep statements, usually leads to problems.
If the data comes in a manner you do not expect, as it usually does, you will have problems.
Debug.Print statements are very slow when connected to a debugger. This will mess with your timing assumptions.
I don’t get how thread.sleep solves this? i feel that thread.sleep is at best, unnecessary delays in your code and at worst, can lead to some serious bugs.
i presume you are doing this because there is stuff you believe is happening or needs to happen in the background before continuing on. you would only do this if there is some asynchronous work going on in another thread that your current thread has a dependency on…the problem is, it’s buggy and guessing game. threads don’t guarantee that they will finish in N ms, but your thread that sleep calls are presuming that to be the case. in otherwords, there is notguarantee that the work you are intending to wait on will be complete before the thread that is sleeping resumes.
the better design would be to either span a thread yourself which will run the work asynchronously that you are trying to wait on and use thread signaling or thread.join to know for sure when the work is complete and you can continue on. Or find some way to definitively determine when your code is ready to continue (i.e. some ready flag of some kind maybe, either in your code or perhaps an attribute of the thing you are dependent on)…whatever it is, it will be better and safer than thread.sleep i feel
@ ISuck@ starcraft, Mike’s point was that the original code had a lot of thread.sleep in there, and it indicated an implied timing requirement between issuing commands and reading responses. But then a whole heap of debug.prints were interspersed, so the timing specific nature of the original code would not actually reflect the timing that would be experienced because of all the huge string actions that go on in debug.print.
thread.sleep isn’t ultra accurate, agreed, but it is a way to get a somewhat accurate timing gap when a device requires it, but if the timing requirements are ultra precise then debug.print will have a huge impact on this
OK I concede, we’ll just call it “simple”, will that suffice? No Very to over-emphasise ?