wx8266, activity on Prop P0

OK, so I got my wx8266 board and have started playing with it, running through the tutorials and sample code.

But I am noticing activity on P0 of the prop (I have led's on 0-7 for another project) even though the WX is using P8 & P9.

Specifically, I am running the val_from_micro example. It works fine. No problems. But my LED on P0 is blinking every time there is serial comms to the WX module.

I don't see anything in the sample code why this should be. Is there something hidden within the wifi drivers?

I need this to NOT happen as it will conflict with my pre-existing use of P0-P7.

Any ideas?

Brian

Comments

  • 5 Comments sorted by Date Added Votes
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,024
    edited August 18 Vote Up0Vote Down
    Maybe noise if the pin isn't configured as an output. Try a pull-up or pull-down resistor on P0, and see if it helps. If not, please post your code.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Code is the val_from_micro sample tutorial. I only changed the pins from the default 30/31 to 8/9.

    My pin 1 (port 0) goes to another chip and also to an LED through a resistor so I can monitor data to that chip.

    But come to think of it, when running the demo code, I am not driving the other circuit so the outputs are not being set or direction register. It may be noise in that case. I'll have to test later after work.

    Brian
  • OK. I've tried setting direction registers and setting the pin low. No joy.

    I also pulled the pin low with a 220 ohm resistor. The pin is being driven.

    And, I even disconnected the pins from my other circuit so they were truly isolated except for the status LED's

    Also, at least pin 3 (port 2) is also being driven low as I already had a 220 ohm pull up resistor on that line (for the other circuit) and the led is off. However I can override this with a high() command.

    Time to dive into the wifi library. This seems a bug to me. I would think the only pins that should be driven are the two given to the wifi_start command.

    Brian
  • ermmm... yeah. The problem seems to be in the wifi library.

    In nearly every function, there are calls to functions simpletermSuspend() and simpletermResume().

    Within these functions, Suspend turns on a pin and Resume turns it off.

    The pin number is held in the global variable wifi_comSelectPin.

    There is only one function where this variable is given a value, and that is in wifi_Stop(), where it is given the value 0.

    However, this Stop function is never called from anything that I can see, so that leaves wifi_comSelectPin undefined (and hence 0). It's only call I can find is in libwifi.c where it is in code that is commented out.

    As to the purpose of toggling this pin, I can only guess it was to act as a status led. It does not seem to be necessary. Probably there for development purposes.

    Now to figure out how to edit the library to test my theory.

    Brian
  • Confirmed. I simply commented out the code in the wifi library that sets "wifi_comSelectPin" and my troubles are gone.

    Am am not versed yet on how to submit changes to the code, so if someone else cares to do it, please feel free. For now I am happy to have my own personal 'fork'.

    Brian
Sign In or Register to comment.