So i finally got things working with the Cerebuino Bee after upgrading the clr and life was good…but this was short lived.
I was able to upload and test a few programs just fine. on the forth try, where i uploaded a program to try and tinker with led1 (by trying to guess what the pin might be), the upload froze. After that, my system no longer is recognizing the Cerebuino.
-MF Deploy shows no connected device.
-if i unpug and plug back in the Cerebuino…windows says something to the effect 'One of the USB devices attached to this computer has malfunctioned and that it can’t recognize it"
-I tried reinstalling the the software GHI software/sdk to repair the installation (and which re-installs the usb drivers)…but that did not help either.
-I tried starting my system to no avail…
Interestingly, If i plug the FEZ Spider in, it is recognized, but if plug the Cerebuino in, it is not.
I’ve not seen this on mind but do occasionally get a hardware error that prevents deploymnet. Even powering on and off, reest button etc didn’t fix it. I redepolyed the firmware and config using MFDeploy (it took several goes as the H/W locked up) but it all seems fine now.
Did the same…erased and reloaded the firmware and now seems fine. something doesn’t feel right given that you’ve experienced the same issue also…but glad its working for now. lets hope this isn’t something we have to do often.
im trying to figure out the pin value for the leds, do u know what they are?..i think the docs may be in correct…the show the led above the input mini-usb connection as “configurable”, but the board list it as “pwr”. the led labeled “led1” seems like it might be the configurable one.
I’ve honestly not looked at it that closely yet. I’ve been (as you know since you help me out) concentrating on extending the device beyond the few modules I’ve bought. IfI get some time I’ll take a look and see if anything makes sense to me. Good luck and let me know how you get on.
I tried looping from 0 to 50, creating and reading from ports, to try and figure this out…
0-8 throws exception when trying to read
9 bricked the thing again and forced me to Erase/Reload firmware and clr.
This feels like it is more difficult than needs to be. documentation would be very helpful in this case i think.
Yes and yes. but in this case, i am just t trying to create a Microsoft.SPOT.Hardware.OutputPort for the configurable led on the board (so i’m not using GHI wrapper classes right now):
The difficulty i think we’re having is the labels on the board aren’t easily translatable into the ‘real’ pins your supposed to use. the schematics doesn’t seem to help much more either…on the other hand, im completely open to the possibility that i could simply be doing or interpreting something incorrectly here.
I think i figured out the issue. First Architect is right, the pin is 18. The reason it does not work for me however is because the FEZCerbuinoBee class already opens an OutputPort bound to that pin. i am guessing you can not initialize two different instances of a port bound to the same pin.
I came to this conclusion after creating my own Gadgeteer.Mainboard and implementing the bare minimum required abstract methods:
[quote]public class MyMainBoard : Gadgeteer.Mainboard
and in Program.generated.cs replace:
When i did this, i am able to deploy the same code that attempts to create an output port against pin 18 and toggle it on/off…it works.
if i switch back to using the .Gadgeteer.FEZCerbuinoBee() mainboard class, it does not.
So i think FEZCerbuinoBee is already creating that output port 18 and the framework doesn’t allow u to create another instance against the same pin.
does that sound reasonable? I guess we will chalk this up to “expected behavior”…
Yep, expected behaviour. The reason it’s there is to protect the uC and the device on the end of a pin. If you define it in your app somewhere as an input or output port, and then later try to define it again potentially differently, you could be in a situation where you damage something.