Home→Forums→MonoBrick EV3 Firmware→Only SensorPort.In1 works? (solved)
Tagged: sensors
- This topic has 6 replies, 2 voices, and was last updated 10 years, 10 months ago by Anders Søborg.
-
AuthorPosts
-
January 30, 2014 at 01:20 #3908
Rich ChampeauxParticipantI’ve been trying to get the sensors working and it seems like only SensorPort.In1 works. My robot needs three sensors: the IR, UltraSonic, and Color sensors.
I noticed a couple of days ago when I was only trying to get the IR sensor working that the app would hang forever when I tried to create the IR sensor. I discovered by luck that if I plugged it into port 1, it took a while to initialize, but it did work.
So today I was trying to get the UltraSonic and Color sensor working. What I’m seeing is that I can only get a sensor to initialize if it’s in port 1. In any other port, sensor constructor hangs forever. When in port 1, it takes a long time to initialize, but it does eventually initialize.
I’ve also noticed that the ultrasonic and color sensor flash every other second or so when my program is not running. However, they only do that if plugged into port 1 or port 2. When plugged into port 3 or port 4, they don’t flash.
I downloaded the latest firmware dll source code and compiled it because the one on the main monobrick web page is from December and doesn’t support the EV3 ultrasonic sensor.
January 30, 2014 at 09:12 #3909
Anders SøborgKeymasterHi Rich
This is a serious bug that I am trying to resolve at the moment. Hopefully I will have it fixed tonight or maybe tomorrow. However the error only applies for UART Sensor so Analog and I2C sensor work on all ports… We will upload a new DLL and Image within a few weeks with a bunch of fixes and new features…. to get the latest and greatest you should (as you have already done) compile your own from the github repository…
Anders
January 30, 2014 at 12:43 #3910
Rich ChampeauxParticipantAnders,
Thanks for the quick response.January 30, 2014 at 16:39 #3911
Rich ChampeauxParticipantI think I found the problem. I don’t really know the code, so I’m just tracing through and looking at how the Port number is used, but…
UARTSensor.InitUart() goes into a loop where it calls ClearPortChanged(), waits, and then reads the status and checks the status for the UartPortChanged bit.
GetStatus() is implemented as such:
private byte GetStatus()
{
return uartMemory.Read(UartStatusOffset, NumberOfSenosrPorts)[(int)port];
}And basically reads the status byte from memory location “UartStatusOffset+port”
However, ClearPortChanged() has a bug I think. Its implemented as:
private void ClearPortChanged()
{
SensorManager.Instance.ClearUartPortChanged(this.port);
uartMemory.Write (UartStatusOffset, new byte[] { (byte)(uartMemory.Read ((int)port, 1) [0] & ~UartPortChanged) });
this.uartMode = UARTMode.Mode0;
}The uartMemory.Write() call doesn’t look right. It reads one byte from memory location “port” (not “UartStatusOffset+port”, just “port”), clears the UartPortChanged bit in the byte, and then writes it to memory location “UartStatusOffset” (not “UartStatusOffset+port”)
So the first problem that I see, is that it is always writing one byte to memory location “UartStatusOffset” regardless of the port number (which means it always writes to the port 1 location). The second possible problem is that the value it reads before clearing the bit is from memory location “port”, not “UartStatusOffset+port” that it’s supposed to be writing to and that it reads from in GetStatus().
I hope this helps. I’m going to try it myself tonight.
- This reply was modified 10 years, 10 months ago by Rich Champeaux.
January 30, 2014 at 20:45 #3913
Anders SøborgKeymasterHi Rick
Thanks for the input – it turned out that you where right. The port number was missing from the write command.
The fix has been committed. I am so excited that help from the community can help the development of Firmware. Basically you should have had the honor of committing this yourself using a pull request (I hope you are ok with that).
I guess a new DLL should be uploaded….
Thanks a lot
Anders
January 31, 2014 at 12:59 #3916
Rich ChampeauxParticipantGreat, I’m glad I was of help. I’m new to the open source scene, so I don’t know all the etiquette and protocol and didn’t even think about the possibility of fixing it myself. I will have to read up on pull requests on github. Also, I found it only through code inspection and looking for inconsistencies, not because I knew what it was supposed to do.
However, what about the second issue I identified? It looks like you are trying to read a byte, clear a bit, and then write it back. However you are not reading and writing from the same place. You are reading from “port” and writing to “UartStatusOffset+port”
I would like to understand more about the lower level interactions with the devices. Where are you getting your information about how to communicate with the devices?
- This reply was modified 10 years, 10 months ago by Rich Champeaux.
February 5, 2014 at 09:51 #3934
Anders SøborgKeymasterHi Rich
Where are you getting your information about how to communicate with the devices?
For this part I looked in the source for the EV3 and the source for LeJos…
It looks like you are trying to read a byte, clear a bit, and then write it back. However you are not reading and writing from the same place. You are reading from “port” and writing to “UartStatusOffset+port”
I will have a look at this tonigh
Anders
-
AuthorPosts
You must be logged in to reply to this topic.
Follow