I had to look up what it was, and right there on the wiki page is code.

http://en.wikipedia.org/wiki/XTEA

what is it you are looking for?

I know of no software that does this, so the short answer is no.

The long answer depends on what you mean by 'handle bit torrenting files'  

Can it copy the files and leave them encrypted? yes.

Can it decrypt the files from a stream?  probably, if you write the code.

Can it coordinate multiple port connections to optimize bit torrent throughput? probably not.

Can it generate keys and encrypt outgoing files on the fly? Maybe (but see previous restriction), how is your STM32 Assembly language and ability to generate your own firmware (do you have access to an expensive toolchain, I have not seen anything about building the current firmware any other way)? The chip can do it, can you?

Bottom line; not something the device is likely to do well, if at all.

So yesterday, I needed to hook up my robot in a new way, including using a USB hub. The only power supply I found near the device that fit was 12V and I thought "what the heck, it has a regulator inside right?"  Wrong, 1 second power light was on, next it was out, for good.

Simple fix, $60 and order another one.

I'm lazy, I hate typing more than I have to. As a result, I have adapted a method that avoids having to add 'static' to every function and variable, and follows the Arduino model a little closer. I insert the following code in just about every project I start.

I hope this prevents some carpel tunnel syndrome for someone;

namespace Junk2
{
    public class Program
    {
        bool instanceDone = false;
        DateTime lastTick;
        EncodedMotor M0;

        public static void Main()
        {
            var p = new Program();
            p.Setup();
            while (!p.instanceDone)
                p.Loop();
        }

        void Setup()
        {
            // do initialize things here

            // pwm, phA, phB, reversed
            M0 = new EncodedMotor(PWMChannels.PWM_PIN_D5, Pins.GPIO_PIN_D9, Pins.GPIO_PIN_D10, true);
 
            lastTick = DateTime.Now;
        }

        void Loop()
        {
            DateTime thisTick = DateTime.Now;
            TimeSpan dt = thisTick - lastTick;

            //.... more stuff

            Thread.Sleep(1000 / 20); // update N times per sec
            lastTick = thisTick;
        }
    }
}

I have never been real clear on the serial port thing with the Netduino. I had some discussion earlier, that probably explained it, but I was a total newb at the time, so I jumped to ethernet since it was the quickest way to get what I wanted working (MQTT type messaging).

I am led to believe that the USB serial port is used for deploying and debugging, and therefore you can not mix your serial traffic on that port if it is in use by visual studio.  The proposed solution I believe was to use an FTDI serial cable attached to com2 on the Netduino, and tell visual studio to use that. Then USB com1 is freed up for your serial traffic.

Is this also your understanding, and how you went about it?  I need to come back to this someday. As it is, when I need to demo something I usually just use an arduino because of this. http://www.spiked3.com/?p=1731

Verified.  Same issue using bitconverter.tostring(). Have to reflash.
 
my quick workaround is;
 

const string hexChars = "0123456789ABCDEF";
static string BugWorkAroundToString(byte[] buf)
{
   string s = "0x";
            
   foreach (byte b in buf)
   {
       s += hexChars[b >> 4];
       s += hexChars[b & 0x0F];
   }
   return s;
}

The biggest difference is one is the time now, the other is the time when the interrupt occurred (or closer to it), and the two are not related.

For starters, an interrupt in a managed framework is not the same as an interrupt on a raw device.

Rather than look at MachineTime Ticks, look at the value of the DateTime timestamp argument passed to you.

But that is for future reference, it is not causing the errors you see.

I suspect you are just driving interrupts faster than the framework can handle.  As far as I know, the Netduino is NOT a good device for reading high speed signals, unless there was something added that I missed.

Even if your code is not doing anything for the interrupt, again, it is NOT like interrupts on an Arduino. It IS doing a lot of stuff under the covers. For one, it is passing you a timestamp. You can be sure that has to go through memory allocation at a minimum. Memory fragmented? Maybe the garbage collector HAD to run.  Then it gets placed in an event Queue, that might need to be expanded .... more memory management. Then it calls your code, that does nothing ... but the stack needs to be cleaned up, and unreferenced objects garbage collected.

Managed code is a different way of doing things. It has many advantages, and a few disadvantages.

Good find! Something to try and keep in mind.

His registerValues  is exactly the same as data , since they are both created the same way. I suspect it is left over unused testing code.

The main function, does not loop. It simply Sleeps 1/2 second and ends, I guess to give time for the i2c transaction to complete?. I am unsure what the device you are using does when the i2c line closes.

I have always had to use an i2c kickstart in my code;

            // required i2c kick
            OutputPort p = new OutputPort(Pins.GPIO_PIN_SDA, true); p.Write(false); p.Dispose();

     I2CDevice.Configuration c = new I2CDevice.Configuration(0x53, 400);
     Byte[] POWER_CTL = new Byte[] {0x2D, 0x08};
     I2CDevice a = new I2CDevice(c);
     a.Execute(new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(POWER_CTL) }, 100);

Is there anything that can be done to reduce the multiple reboots that occur when debugging?

My netduino sometimes reboots 12-15 times before the debugger load symbol tables and begins debugging.

Then there are those rare occasions (1 in 50?) that it works with just one reboot.

I generally have control and can force some sort of orderly shutdown if that helps start the next session, I just have no idea what it would be to do that.

So, My first netduino completely quit talking to the robot.  So I was trying to hook it up to the desktop PC when I had the 12v incident and totally fried it.

But I always did wonder why it behaved differently (and usually worse) than the newer netduino lab board I had (same model).

Then todays story on clone ftdi chips getting bricked intentionally by driver updates - hmmm, things are starting to make more sense. Why it behaved poorly, why it stopped working.

With my luck though the newer will die in a day or 2

yeah, linux is taking over the desktop too, haven't you heard?

It was given thought, and that scenario was not included. Netduino targets .Net developers. You aren't one of those? It was not intended for you, move along.

Although it is not very hard for a beginner to pick up one of the best of all time languages with a zillion samples on the internet. Some are just too smart for that.

Thinking you can just add .Net support into an IDE designed for non .Net is exposing how little you really understand the technology. I suggest he integrates JAVA first.

I started to reply. But then I thought I would re-read the question.  Which is;

"Are there any ideas that would work similar to a database other than a simple text file?"

and to that, my answer is no.  

I have ideas how I would handle database transactions, with store and forward guaranteed message concepts, involving simple text files, but you asked for something else. That gave me the impression you already know how to do it with simple text files, and I really can not add.

For other readers, who  may not know how to use simple text files; identify how you can make a db transaction atomic - ie self contained.

Look into things like diff files for ideas and mold the idea to fit your data - I have no real idea what your data looks like, so I can only suggest starting points.

Once it is atomic, write it to a separate disk file on the SD card.

A different thread, reads ALL files on the SD card one at a time and attempt the transaction with server/database/both. When confirmation is received that the database transaction successfully completed, the file should be erased from the SD card.  This method will survive system and network failures.  If you need to prevent accidental double updates, include a sequence number. If it has already been used indicate a previous transaction succeeded.

Just some wild guesses.

You create a new Led port in main, then eventually fall through to a infinite wait (never exit). The object reference may never be garbage collected.

In your loop you create another Led port (same pins), over and over, never disposing of it, although I guess it might self dispose in the 250ms wait, but in any case this is bad practice.  Allocate it once, in main, and refer to the same object everywhere.

You also allocate a buffer, the size of bytes to be read whenever bytes are available, then read that amount. It is probably safe to assume that a single read will do the trick in that case, no need to 'while (serial.BytesToRead > 0)'

Your comment

Any followup on this?  Jrc903 indicates he saw where the programs ran under 4.1, but martijn says they never could run.

I can say for a fact it dies on 4.3 (10042 Bad protocol option). 

I am wondering, is the UDP Multicast only used for anonymous discovery?  Is there a way to bypass that and get dpws functionality?

Does the gadgeteer implement dpws?

And you need to use a separate serial usb cable/converter. Other than that, all the program does echo back any characters it receives.

There are a few spots in the code that bug me.  Why does he allocate a byte array of 1 byte?  just declare a byte, then use Serial readByte() and writeByte methods instead of read() and write().

I especially would not do a new byte every time I entered that delegate - very inefficient.

I have never seen any mention of it. Nor is there any indication for support from within vs I can see.

I had one just quit working, right around the time the driver was released that bricked clone chips.

I thought they replaced that driver now, but in any case, I otherwise destroyed that one (power incident) so I just go another one and it is still fine.  If it used to work, and no longer does, keep this in mind as a possibility.

Otherwise, the normal troubleshooting routines; hold down the reset while attaching to USB, should show up as something else (not netduino) in device manager.  Use mf deploy to update the firmware, should now show as 'netduino' in device manager.  I find every once and while the firmware goes MIA, and I have to reflash occasionally. 

When you say "I can deploy the Blinky program, but  ..."

How do you mean deploy?  If you deploy by right clicking on the project and selecting deploy this does not start the program. It simply downloads it to the device. Press the onboard reset button and it should run.

On the other hand, you can deploy AND start the program by pressing F5 (as long as the project is selected as the startup project).

Otherwise your code looks fine and should work.

You had my curiosity peaked so I tried your program (on 4.3.1).

It ran as expected .... but

I will say it acted weird(er) than other programs. I don't know if you triggered some bug with a variable name or what, but there is a big delay when it starts (4-5 seconds).

I have 2 N2+ now, and they work differently as far as debugging, how many times they reboot when starting. The newest one consistently usb disconnects 3 times, then starts loading symbol tables. The previous one was a random number how many disconnects/reconnects it goes through.  The moral is I doubt if there is consistency among units at the moment.

I'll contrast this with the Galileo which feels rock solid as far as debugging (which also uses the ethernet connection not USB). 

I'm thinking I'm going to need to add stuff to the firmware myself, although it is way out of my comfort zone I don't know what else to try.

Is there any updated info I missed about a current procedure to do this?

I see the notes on doing it for 4.2.X in the wiki, step one is obtain some compiler that has been retired, so obviously that is out of date.

Curious how you tried 5v and 3.3v?   I have a 3.3v 9dof stick that will only work when the analyser is attached and powered on.

https://www.sparkfun.../products/10724

It has pullups built in as well.

Ok, I apologize for my lack of hardware knowledge. I had recently been told by 'an i2c expert' that the i2c clock & data was at 3.3 or 5v.  I've since learned to not trust an expert. I was confused / misled.

My problem appears to be that if the analyser is attached it MUST be powered.  But part of me also wonders about ground loops, and maybe that is the issue.  I sure wish us software types were not forced into hardware, there is a reason I avoided it for 60 years.