NetBurner Community Forum

Nope no launch this weekend...
On Friday night I connected a battery backwards and cooked my guidance servos....
(My electronics survived just fine.. the servos let out the magic smoke...)
I now have spares and the next launch is on Feb -2.

Paul

Look in the platform include directory for intcdefs.h I'd use thoose macros on this platform.

Paul

I Don't know how much.... Depends on if I'm selling a few of the 10 I built or if we decide to produce somethign like this... My cost to produce the 10 prototypes was about $125 each with zero pprofit... As far as using in a HPR, I'll let you know on Monday this is flying in a 3 motor gimballed rock...

I have a small board based off of the Netburner MOD5213 it has Invensense MPU6000 IMU, A 3 axis magantometer HMC5883L A sensitive altimeter (MS5611-01BA03), RS 485, A socket for an XBee telemetry radio, Output drive for 8 RC servos, A 16M byte log storage chip 4 Timer inputs that can read an RC reci...

putchar is standard I/O just like all the other I/O. Disregard my ISR level questions if you are not using external IRQ pins.... Calling ANY I/O that calls RTOS functions from inside an ISR can break things... so remove the putchar and add the interrupt counters and see what happens... What platform...

What platform /CPU is this for...
I'll point you to a working external interrupt example for that platform...

Several problems here: 1)First you can not do io like putchar from an interrupt... Hunt down the programmers manual section on interrupts it tells what functions are and are not ok... 2)The external interrupts have to be at their native priority... IE IRQ3 has to be 3. The register interface looks l...

If no tasks are pending on the semaphore, it does no harm.

However from a code maintenance standpoint I see it as a bad idea, because in the future you may never be sure
no tasks are pending..

If you look at the ADC driver...
and the freescale manual, you should be able to not enable the two DAC channes in the example A/D code.
This should do what you want....

To be 100% DHCP compliant one is supposed to add a random boot time delay of 0 to 10 seconds to the DHCP discover message... When we did this people complained about the long boot delay... When we ported to the SBL2E we did not include this delay... It would be pretty easy to add..... I would expect...