Gus you guys deserve a huge attaboy for this as its not just a little bit faster, its the kind of faster that causes people like Jeremy Clarkson to come up with witty performance quotes involving Keira Knightley and honey. For example running my Calculating Digits of PI
Compiled with Debug (not run in interactive debug however)
Calculate 20 digits of PI
FEZ Cerberus - 4.5 sec
Calculate 200 digits of PI
FEZ Cerberus - 08:29
Compiled with Release
Calculate 20 digits of PI
FEZ Cerberus - 3.4 sec
Calculate 200 digits of PI
FEZ Cerberus - 06:32
To this (que Keira Knightley and the honey)
Compiled with Debug (not run in interactive debug however)
Calculate 20 digits of PI
FEZ Cerberus - 2.1 sec
Calculate 200 digits of PI
FEZ Cerberus - 03:53
Compiled with Release
Calculate 20 digits of PI
FEZ Cerberus - 1.6 sec
Calculate 200 digits of PI
FEZ Cerberus - 02:57
As for VS 2012 Iām starting to wonder if some folks from Apple and/or Google have infiltrated the VS development team (or worse Java freaks have infiltrated the VS Development team).
Unless it can be measured its not really an improvement, and I think we would all agree that the world is way to full of so called āimprovementsā which canāt be measured (mostly because they arenāt really improvements, just hype for crap). Nothing drives me wilder then people making claims that A is better then B, but then say you canāt measure why it is better (like folks making software development methodology claims and these guys claim to be āengineersā).
Start warming up the honey!!! That is very impressive as it would be like a 4x increase in speed from what it used to be (Iām assuming that is a 20 digit run, otherwise Iām going to need more honey as Keira is bring Scarlett along).
This might be a newb questionā¦ but if I want to keep running VS2010 for now on my development rig, is there any reason why I can install this new SDK on a different computer to get the firmware?
Would there be any problems deploying from 2010 to the updated Cerb?
I have the new SDK up and running, but Iām thinking the Debug vs Release problems that were keeping the speed down may not be completely resolvedā¦
I have interrupts on my Cerb40 on PA0 and PA1 that work fine when debugging in VS2010, but when I disconnect USB and run free the interrupts donāt fire at all when stimulated by the rotary encoder. I also tried manually shoring the pins, which didnāt work either. Tried with Glitch Filter on and off.
This is in a project that has a lot of other stuff going on (SPI, serial, SD)ā¦ but the encoder works 100% of the time while debugging, and never when not debugging. This also worked perfectly fine with the previous Cerb Firmware.
Code snippets below
static InterruptPort encPinA =
new InterruptPort(GHI.Hardware.FEZCerb.Pin.PA1, true,
Port.ResistorMode.PullUp,
Port.InterruptMode.InterruptEdgeBoth);
static InterruptPort encPinB =
new InterruptPort(GHI.Hardware.FEZCerb.Pin.PA0, true,
Port.ResistorMode.PullUp,
Port.InterruptMode.InterruptEdgeBoth);
public static void Main()
{
encPinA.OnInterrupt +=
new NativeEventHandler(encPinA_OnInterrupt);
encPinB.OnInterrupt +=
new NativeEventHandler(encPinB_OnInterrupt);
Thread.Sleep(Timeout.Infinite);
}
static void encPinA_OnInterrupt(uint port, uint state,
DateTime time)
{
if (_udpReady)
_wifiModule._SerialPort_Write("encPinA Interrupt");
if (encPinA.Read() == true)
{
// check channel B to see which way encoder is turning
if (encPinB.Read() == false)
{
_currentChannel++; // CW
}
else
{
_currentChannel--; // CCW
}
}
else // must be a high-to-low edge on channel A
{
// check channel B to see which way encoder is turning
if (encPinB.Read() == true)
{
_currentChannel++; // CW
}
else
{
_currentChannel--; // CCW
}
}
CheckSwitch(false);
}
static void encPinB_OnInterrupt(uint port, uint state,
DateTime time)
{
if (_udpReady)
_wifiModule._SerialPort_Write("encPinA Interrupt");
if (encPinB.Read() == true)
{
// check channel A to see which way encoder is turning
if (encPinA.Read() == true)
{
_currentChannel++; // CW
}
else
{
_currentChannel--; // CCW
}
}
// Look for a high-to-low on channel B
else
{
// check channel B to see which way encoder is turning
if (encPinA.Read() == false)
{
_currentChannel++; // CW
}
else
{
_currentChannel--; // CCW
}
}
CheckSwitch(false);
}
Your debugging versus the debug build of the firmware are unrelatedā¦
Step back and prove interrupts are firingā¦ do something simple like flash LED or increment counter in the interrupt handler and output it onto a display in a timer. I doubt GHI could make this big a change
Well, whatever it was Iāve made no hardware changes and no code changes other than updating the pin enumerations to the new FEZCerb class used in the new SDKā¦ the interrupts fire when Iām debugging, they do not when I disconnect the USB and restart the Cerb40 and let it run that way.
I am absolutely sure because I am monitoring wifi UDP messages from the Cerb on a terminal program on my computerā¦ all other messages come though, but none from the encoder interrupt handlers. And of course the handlers donāt perform the method call they are supposed to, which is why I started investigating this in the first place. To rule out a spotty encoder, I directly shorted the interrupt pins to ground.
Iām going to try installing the old SDK on my laptop and reverting the firmwareā¦ this was working fine on the old firmware the night before last.
I just reverted the firmware and it works perfectly now as before.
Iāve got some other stuff I need to get done today but Iāve been putting it off trying to figure this outā¦ Iāll try to get an example put together tomorrow.
Alrightā¦ hereās a head scratcher. I reverted my firmware after initially finding this problem, and everything worked great again as far as interrupts go. But I was having SD troubles, and needed the new firmware for that.
Switched over to new SDK, interrupt problems are back. I used my fancy new o-scope to take a look at these interrupt pins. When I was debugging through VS2010, the internal pull-ups on these pins work fine. 3.3V or 0V when grounded.
When I restarted the Cerb40 and let it run without VS Debug, the interrupt pins read under a volt at the highest, and of course 0 when grounded. For some reason the internal pull-ups no longer work right. Everything else (music, SD, PWMs, etc) worked though.
Of course this is a pretty complex project with a music module, sd module, and pretty much every other pin of the Cerb being used for PWMs, interrupts, etc. Running a more basic program the problem was not seen.
So I found a fix though. If I declare those interrupt pins after Iāve initialized the music module and mounted the SD, the interrupts work as expected both in debug and when running normally.
Sooooo what did I learn? I dunno reallyā¦ but my project is working now.
