Only SensorPort.In1 works? (solved)

HomeForumsMonoBrick EV3 FirmwareOnly SensorPort.In1 works? (solved)

Tagged: 

This topic contains 6 replies, has 2 voices, and was last updated by Author Image Anders Søborg 3 years, 6 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #3908
    Author Image
    Rich Champeaux
    Participant

    I’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.

    #3909
    Author Image
    Anders Søborg
    Key Master

    Hi 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

    #3910
    Author Image
    Rich Champeaux
    Participant

    Anders,
    Thanks for the quick response.

    #3911
    Author Image
    Rich Champeaux
    Participant

    I 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.

    #3913
    Author Image
    Anders Søborg
    Key Master

    Hi 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

    #3916
    Author Image
    Rich Champeaux
    Participant

    Great, 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?

    #3934
    Author Image
    Anders Søborg
    Key Master

    Hi 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

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

Posted in

Make a donation