not sure, but ran into issue like this when experimenting earlier with tft display on mini breakout. I should probably go back Nd see if this was one of the pins I tried with cs or dc pins
are you sure you dont need to set the pin mode via pinmux and is your pin floating or what is connected?
I do believe you must export the GPIO pin to Sysfs before you can alter the pinmux. The pin is not floating but going to the Sparkfun Dual H Bridge block as AIN1. SparkFun Block for Intel® Edison - Dual H-Bridge - DEV-13043 - SparkFun Electronics
Also to note.. This behavior is observed even when the pin is floating on a mini breakout board.
I just heard back from Intel Support and they were able to reproduce the same issue last week. It has been reported as a possible bug and currently under review.
The timing coincides with the release of the Sparkfun Dual H-Bridge so I wouldn't be surprised if everyone with this module has a little trouble. A quarky work around I found last night was to run iwconfig after exporting GPIO 48. There will be a bit of a delay in the WiFi connection ( while something is polled/reset? ) but the connection was usable after the export thus allowing my development to move forward.
I have the same problem using GPIO 44 with a sketch (Edison + minibreakout board).
Starting the sketch, ssh connection gets lost because wifi is down.
A workaround is to restart wifi immediatedly after starting the sketch (i wrote a small script for this).
This happens also with Ubilinux and Archlinux, both use the Yocto kernel.
I don't know if I should re-post on my thread since it was marked answered but...
The problem described still exists in the 05-15 Yocto image and I'm not sure how to keep track of the issue to know if a resolution has been discovered. Will Intel post a response here or is there some webpage/code tracking system where I watch the issue?
I agree with you, a code tracking system could help to see opened issues on Edison and don't waste time with the same problems
For this problem (GPIO 48 - pin 7 on Arduino board), I found the issue was reported in a PDF (This can be done better)
There are some changes on the way that I think will address some of this.
More to the point of this issue: I show it as being fixed in the mainline, though it is after we made release 2 public. It should be available in the next release.
I hate just jumping on band wagon, but again it would be nice to know which things are fixed and how soon can we expect a drop that includes them.
Example SPI issues - Both delays in bytes as well as new issue with power management. Can we expect a drop soon that will address some of this, or should I punt for now and for example if I wish for TFT output, use a secondary processor like Teensy 3.1 (or LC)...
As others have mentioned, When we post something like a new bug, where there is a response like, it has been reported to developer. The thread is marked as answered. Instead it would be good if it was marked as some other state like, Pending or ... And it is later marked as Answered, when really the answer may come a lot later (fixed in release...). Obviously a better approach would be to have something like github issues like web site, where the issue is entered and there is status information, like, status , maybe some type of priority,... And then the forum messages, could be answered as this is now issue # xxx .
Yes, I agree. I don't think you're bandwagoning - it's a valid issue to me as well. I'm confident the work we are implementing right now is going to address a lot of what you are talking about. The unified installer is an example of one such pain point that the community requested to be solved, and that we are beginning to roll out post release 2. There are more on the way, but I can't be specific until a couple more approvals happen. I recognize your frustration and also the irony of me saying I can't be specific right now. I am confident it will be solved very soon.
The SPI latency stuff - again, I agree. This one I have been personally pushing on (I have even talked to a few of you one on one about it). I am also confident on this one getting fixed very soon, but I'm bound by the same problem of the previous paragraph (we need a couple more internal commitments before we can talk about it and/or commit to the public).
Don't worry about giving us honest feedback. There are lots of folks across multiple teams who watch these forums and enact plans to address issues. It helps the process more than you probably think it does.