...The I2C state machine in this part has a locking condition, which is stated in the datasheet and errata for this part, but without and debugger and a scope it can be hard to determine if this is the issue.  I did verified that this is in fact a real issue with the latest firmware...

Mmm! thanks, yogotie, for figuring that out and reporting it, along with your change to fix it.  To bad we don't have a process by which to submit patches (or even a reliable way to get the current and historic firmware source).

Chris is the 4.2.2.2 firmware source posted?  I think what is on the download page is for 4.2.2.1.

I likes to keep up-to-date....

If you build your firmware, and make an 'interop assembly', you can expose an interface to your code to NetMF applications.  The firmware ultimately is C/C++ itself.  In this way it is conceptually similar to making a JNI

Beyond that, it will depend on what your existing code does (e.g. library/system dependencies).  Is it, say, purely mathematical (like signal processing), or systemic (like, some custom network protocol).  The former should be readily doable, because it's probably not coupled to any dependencies, and the latter could be a challenge because it is (ostensibly to the sockets api for example).

...

I found the .dfu in the thread. Thank you. Tried to flash it onto the board following the steps in the thread. I got the same result as stated above. I'm using version 3.0.0 of DFUSE. The thread asks for version 3.0.2 and 3.0.1. Could this be vital to how the program runs? 

...

OMG (sigh) yes I should have mentioned that, too; I forgot about the update tool version issue.  I know folks have had problems with the earlier version (and hence why Chris put a link to the working ones, because they are harder to find otherwise).  And I am apparently using 3.0.1 and 3.0.2 myself, according to the title bar text.

...

Thats a great idea. I can't find the Netduino 2 firmware in a .dfu format. I found the firmware .zip file here: http://www.netduino.com/downloads/. I don't know how to use the content however as there is no README file provided. Could anyone supply me with either a firmware in the .dfu format or steps on how to generate it from the resources in the .zip file? 

the arrangement of downloads here does leave a bit (lot) to be desired.  Anyway, to wit, the latest Netduino 2 firmware can be found via links in this thread:

http://forums.netdui...-v422-update-2/

give it a go.

and you are sane, your DFU flashing should take as long if not longer than you are experiencing in your erase.  On the plus side, if your erase activity seems sane, then you are probably past any hypothetical usb problems.  So flashing back your firmware, and maybe a sanity check with mfdeploy ping, then you'll be back at ground zero (which is better than where you are now, right?  which is ground negative x?)

...nor checked the d/s of that vintaged speech synthesis chip of yours - what exactly are you using for playback? You mentioned a synth and by that, do you mean Netduino PWMs or some actual external h/w not seen in the video?...

Mmm! that would be useful info.

General Instruments SP0256-AL2, and an LM386.  Its on the white breadboard, but I should have angled it forward to the camera.  I'm not a photographer at all.

Interfacing was straightforward, I used d0-d7 as an 8-bit parallel port, with d8,d9, d10 to connect to the latch and busy lines.

The output of the chip itself is PWM, which is sent through a passive lowpass filter before hitting the amp.  This is a stock datasheet circuit, so nothing really noteworthy there.

But your mention of the Netduino PWMs is interesting.  If I'm not yet exorcised of this diversion, I might try my hand at implementing a software version of the chip.  The chip's predecessor's datasheet seems pretty explicit about the digital filter's design, but we'll see.  I'll probably have to go native to do that, though.

Recently, while looking for some unneeded junk on ebay, I stumbled across a listing for an antique voice synthesiser chip, the SP0256.  It made me remember that I might have some on-hand, and I looked in my junkbox and Lo! and Behold! amongst decaying antistatic foam were a couple samples, replete with the odd-valued crystal it prefers.  So I thought I'd amuse myself for a couple hours and hook it up and reminisce the scarcely intelligible sounds from yesteryear

After the fun of a buzzy 'Hello' had worn off, I found myself inspired to do a particular Doors song, but one thing about this chip is that you have to manually specify a sequence of phoneme variants called 'allophones'.  This is a bit time consuming, and so drains the fun, but by now I was doomed because improvement obsession had set in, and so I wasted several days implementing a text-to-speech algorithm for it (don't be too impressed, this is derivative from some research done in the 70s, and some concrete code done in years hence).

Anyway, I thought I'd share for your amusement if you're bored.  (well, I can't really promise this will truly cure that, but I did try!):

While a trivial pursuit, there were some useful things I did learn that I want to share:

1)  C#/NetMF is not great at constant data, like for tables of...  'stuff'

  By 'not great' I mean 'horrible'.  The text2speech uses about 2000 rules, consisting of 4 parts:  three patterns and a phoneme sequence to emit for the match.  This is the sort of stuff that in C, etc, you declare something like:

[color=#4b0082;][font="'courier new', courier, monospace;"]   struct thingy { const char* first; const char* second; const char* third; const char* fourth; };[/color][/font]

[color=#4b0082;][font="'courier new', courier, monospace;"]   static const _rules[] = { "l1", "m1", "r1", "f1" }, { "l2", "m2", "r2", "f2" }, };[/color][/font]

and when you did that, the linker would have the sense to put it all in ROM, thereby consuming no RAM.  Because it is read-only; what do you need it in RAM for? (on some processors you need to add some compiler-specific qualifiers, or some linker magikry, but that is not pertinent here).

  On netmf, apparently 'const' and 'readonly' are neither, and netmf will take such a naively constructed array and blithely instantiate it in RAM.  Goodbye RAM, we'll miss you.  And miss it, I did, because I consumed it all (about 105k available to user programs on the NP2) and had none with which to run my program.  This was when I had a little over 300 rules that were derived from the US Navy research.

  So in eagerness I cut a few, and it sounded like crap, but it ran, a little, with about 20K RAM.

So 'caveat programmer' on tables of data, I'll describe how I coped and with what results after explaining a few more things....

2)  Netmf apps need more than about 15K RAM

  If you go below this, the system will become unstable.  You will need to furiously litter your code with

[color=#000080;][font="'courier new', courier, monospace;"]   Debug.GC(true);[/color][/font]

[font="'courier new', courier, monospace;"][font="arial, helvetica, sans-serif;"]  just to keep it alive.  You'll see memory allocations fail on the debugger output, and your program will run for a little while, but things will come to an end soon enough.[/font][/font]

Nothing to say here other than realize that you will need to help netmf out by not getting to rammy with your impls, and that a [color=#000080;][font="'courier new', courier, monospace;"]GC(true)[/color][/font] now and then is most effectacious.

3)  An array (i.e. []) of something will cost you RAM

  all the const and readonly in the world apparently will not help you, there will be a RAM based array of references.  Hmm!
 

4)  Too many initializers makes your metadataprocessor mad

  A companion to the RAM consumption problem is a build tool called the 'MetaDataProcessor'.  It evidently processes the data that is meta, but it doesn't like it if you have too much.  It will give you abstruse error messages (one of which I do not have a sample at the ready just now, alas), so like you just cut a few.  Like when you have too many notes in your music score.  Well, you coded them, and it's not like you're just typing them in to keep the blood flowing to your fingers on a cold winter's eve, they're important!

I found that the count of items is important, and the type drastically even more so.  Which leads to the next point...

5)  NetMF is pretty good at [color=rgb(0,0,128);][font="'courier new', courier, monospace;"]string[/color][/font]s

  strings, which in dotnet and other recent languages of the javainian persuasion, are immutable, and the runtime seems to have some sense in that regard.  So, if you declare a string constant, it's value actually will be stored in the Flash, and not come into RAM until you fiddle with it......

So, OK, this last bit is call

What I Did To Cram 2000 Structs Of Read Only Data Into My App And Only Waste 25k Of RAM,

or alternatively

thank Goodness My Processor Is Fast And Doesn't Have Better Things To Do.

I'll spare you the details of the 5 or so experiments I did before this final one -- you've been kind (or bored!) enough to read this far.  Ultimately, I:

*  flattened my jagged array into single array

  and a secondary array of offsets to the starts of sections, and then manually treated it as an array-of-arrays in code.

  This helped a little with the RAM usage; a small gain, but a gain nonetheless.

*  transcoded my binary fields into text fields

  this was surprisingly helpful, because evidently metadataprocessor gets really miffed at initializers for binary fields.  way more so than for text fields.  Hmmm.  I'm going to have to look at this metadataprocessor someday.  Anyway, this made is possible to even compile with a reasonable-sized rule set.  I find it rather puts a damper on your fun if you can't compile, but maybe that's just me....

*  flattened my structs into a string

  this was a much more tedious, because I was effectively encoding the struct into a delimited format, and scootching the character set to avoid the field delimiter.

  this was the big win by far.  ultimately it was what made it possible to include the total rule set, and still have a healthy bit of RAM left over for the app.  Mind you, in a sane world the RAM cost would be zero.  Thats a '0' with infinitely many '0' after it.  So I'm still a little disappointed (and some of my crypto code is as well because I need tables for my S-boxes etc and compiles fail sporadically because of it but that's a separate rant), but this project was for fun so whatevs.

Then, I punished my STM32F4 by making it depersist the encoded rule on-the-fly every time it was needed.  Which really is a lot.  And speech is slow to emit, and so there's time abounding to translate text into speech, and so you can keep it quite fluid if you have a worker thread that emits speech sequences from a queue, separate from your text-to-speech translation process

Oh!  That reminds me that there is one other thing I learned in all this:

*  Event Notifications Come In On a High(est!) Priority Thread

  To make the demo, I added an [font="'courier new', courier, monospace;"][color=rgb(0,0,128);]InterruptPort[/color][/font] to execute one of my test sequences.  Click the button, and text to speech something fun, and out comes sound.  EasyPeasy.  But, my speech came out sllooowwww, for a couple seconds, and then picked up the normal pace.  Well, the reason why is that the button event handler gets invoked on a thread executing at priority 4 (highest), and my speech rendering worker thread was running on priority 2 (normal).  So, my text-to-speech was running in a higher-priority thread than my output-to-synthesiser worker thread, and so was taking time away feeding the synth.  Actually, I am impressed that the synthesizer thread was not starved out-right, so kudos to the scheduler implementer, but nonetheless the text to speech needed to be at or less than the priority of the output.  The interrupt handler had nowhere to go but down, and anyway I felt dirty fiddling with it's priority since it was not my thread, and so I made yet another queue for text to speech work.

Oh, there were two last things I learned that are worth mentioning:

*  arrays cost

  For fun I tried setting all my rules to null.  guess what?  I still used 25k.  So that ram usage seems to be for the array of object references, and it WILL be in RAM.  No ROMming for you!

*  netmf uses utf8

  hahaha I was worried that encoding as a string would incur a UCS16 penalty, but it does seem that netmf uses UT8 for at least it's const string literals.  Hollow victory, though, because once its rom-able, the space is less an issue.  Still, interesting fact to note.

Anyway, there it is.  I have spent a little more time than I should have on this, and now that I have posted, perhaps I can dismantle my breadboard and move on with more useful things!....

no it's straigtforward.  Its definitely klunky, but mostly straigtforward.  And it should take a little while to flash, subject to what you are flashing.

I would go back and check my assumptions:

*  is the DFU valid?  not only valid as a dfu, but when you built it, does it have what you think it does.

*  did you first erase the device?  with the stdfu tester?

*  did you select the 'verify' option, so the that it will read back what you wrote? (this is particularly useful to make sure you didn't forget to first erase)

Lastly (and I should have mentioned it firstly), try to flash the official firmware to verify your understanding of the flashing tool.  Then, if you have problems, you can be fairly confident that something is awry with the dfu itself (or with the contents therein).

ziggurat29,

 

Thanks.  And yes, I checked that it IS set.

 

The reset vector points (ignoring the LSB) to a single C-function (within which, everthing's a branch).  I'm trying to crawl before walking.  But I'm missing somthing simple/fundamental.

Oh OK perhaps I mis-read something; are you having a problem?  I thought you were just asking about why some folks mention the bit, and others don't.  Otherwise it looks like you're well on your way to fame and fortune.

...Quite unsurpricingly but at the same time fascinating when you think of it and really ask your self "but why exactly?". I guess its a force of nature really. What we did was creating a histogram which is pretty much the Fourier transform, basically saying that any signal (stochastical or otherwise) can be broken down to a number (possibly infinite as in the case of square waves) of sinusoidals. In our case, I guess the "sinusoidals" were stochastical signals, simultainiously strectching in all possible directions but projected onto a vector in a six dimensional universe - the dice ;-)...

Fascinating point indeed; I never thought of a histogram as a Fourier transform, but then I'm an engineer rather than a mathematician...  Of course the histogram shows only the magnitude, so I suspect the randomness gets squeezed into the (not-depicted) phase component of the transform.

Some interesting reading on the NIST's standards for RNG;

http://csrc.nist.gov...800-22rev1a.pdf

(gasp!) Christmas came early this year!  Thanks, I actually needed a reviewed and accepted entropy measurement methodology recently -- I don't know why I didn't think of going to NIST at the time....

Well let us know how your noise generate works, and most importantly, how it's sequences test out.  Cutlass' zener mention makes me wonder if you could use a 3v zener and an appropriate amp and feed it into an a/d pin and get an acceptable similar noise result.  Then again I suspect part of all this circuitry is that the components (zener/transistor) aren't designed to be noisy, they're designed to be quiet, and so the gains needed might cause the amps to saturate on non-random ambient signals picked up, but maybe my concerns in that regard are unfounded.

it has to be set or it will be a quick trip to Abort land.

And by all means check that it is.  I was setting up building the firmware with Yagarto et al back around Dec/Jan.  Many times the linked output would NOT have this bit set.  This seemed to be particularly happen in the case of structs with function pointers to assembly functions (like interrupt vectors often are!).  I typically dealt with it my modding the source to explictly state that it was a thumb function.  If you care, you can find some deets in the wiki article I posted, or you can do as I did and wait for it to crash, and fix as you go.  At any rate, you may have a much better go of it than I did since you'll be in control of your source, and I imagine you'll mostly be doing C, and will only have a couple cases where you might be exposed.

haha, nice; actually, using  zener noise is another common hardware RNG source, so maybe you can save even more parts!

Another pedantic point while I'm apparently on some kind of roll is that what we call zeners out of convention, usually actually work more by avalanche effect, which is what the O.P.'s circuit is doing, ha!

Lastly, simply converging on a 50/50 distribution (or any flat distribution) is not a good measure of randomness.  You can imagine the degenerate case of a counter -- it will average 50% above the middle value, and 50% below the middle, and with equal distribution of all values in between, but a ramp function is surely not random.  Establishing randomness quality is fairly difficult, and a lot of science has gone into devising tests.  And so many crappy generators over the years, its the stuff of fable...

http://xkcd.com/221/

OK I imagine yall are probably tired of hearing from me on the matter haha, and my crypto perspective...

I second bi qin's suggestion of taking an actual look at the waveform.  I want to add this from my recent experience if it's  useful:

*  I was needing a ds1307, and put it on the special sda/scl lines.  what could be simpler, right?  well it didn't work

*  I fiddled with it for quite a while but miraculously my scope arrived later that day.  guess what -- no output whatsoever.  hmm.

*  I flashed my NP2 with firmware 4.2.1.2, and guess what?  worked perfectly.

*  I flashed back to 4.2.2.1, and it failed.  Hmm

Ultimately in my case, I had to hook my device to the a4/a5 and bitbang i2c (I have an in-between shield that does not pass through the newer pins), which also worked fine for me, and so I haven't gotten back to looking at the firmware issue.

so, do look at the waveform -- it might not be you.

 I would even argue the mentioned entity is but a commonly used metaphor for the dice themselves.

well discussions on the topic of the mentioned entity can certainly generate a lot of noise, but I don't know if there's enough entropy in that source, haha,  but now we are truly off topic!  haha

I have used it long terms without problems if all systems are running correctly.

By that bold statement (haha, bold font that is) I mean that I have run a netduino connected to, and communicating with, a server on the Internet, for over a week time, without apparent errors.

However, I have personally has this bad experience (which is different from yours, but nonetheless here it is):

*  if my daemon, running on the server on the Internet, is taken down.  E.g. to update the binary, whatever

*  then the netduino will properly detect that it has disconnected

*  my code will loop around in a retry loop to re-establish connection (after a brief sleep)

*  and at the 'connect' call, the thread will hang.  forever.  even if the daemon is brought up later.  so I wind up having to implement a watchdog also, but at least only the one thread is hanged.

Things that do work correctly for me are:

*  netduino ethernet cable unplugged, connection lost, retry connection repeatedly, plug back in, recovers connectivity to server

*  take down whole server on Internet, netduino detects lost connection, retries, recovers

So from my viewpoint, in my case, it seems that somewhere deep in the firmware the 'connection refused' state (when the port is not listening) is causing woes, but the various other problems related to 'host not reachable' are OK.  Moreover, the problems seems to manifest itself when it has once successfully connected, rather than when it has never successfully connected at all.

Anyway, I know my problem is different than yours -- yours is interesting -- but I wanted to let you know what did and did not work for me since thats what you last asked.

of course it should be straightforward to connect a serial eeprom to either the spi or i2c bus, or bitbang if you have to and you have some time.

While I haven't done it on the np2, I certainly have on other processors, and I have done other i2c things on np2, so I'm confident it will work fine.

Now I'm curious, I have a device laying around somewhere, maybe I'll hook it up and try, but I'm sure you can get it going yourself, too.

...

The objective of this project is to create a RNG that anyone can build. The ultimate user for this are researchers who want a true RGN rather and a PRNG.

and more practically, it's critically important for folks doing crypto.

...From a philosophical perspective, I personally don't think that we can ever observe true randomness due to the Heisenberg principle of uncertainty. It would be like trying to have a camera take photographs of itself 

oh yes, and indeed for that very reason.

http://en.wikipedia....umber_generator

remember, much to Einstein's chagrin, alas, God does indeed play dice.  And in this this application, we're keeping tally of the rolls.

(but I do like the visual of the camera taking a photo of itself)

OK fine.

http://www.mouser.co...KYHK4Hup7sWXRu9

quantity 1, $13.29

http://www.mouser.co...KYHK5GPPWWCIYmz

quantity 1, $12.78

13.29 - 12.78 = 0.51

ok,thanks for your good opinions ziggurat29,i will upgrade it to STM32F417,but would you buy it if it needs at least $150?

Hmm.  Well, how much was it with a 407?  haha.

OK, I think the real question is:  'what is the value of the 417 versus the 407', and I think there are two answers to that, one from the customer side, and one from the vendor side.

From the customer side I would pay $5-7 more for a board with a 417 that also had firmware support.  I might consider it even without firmware support if it was pitched effectively that such could happen somehow at sometime, rather than my having to buy an new board to get it.

From a vendor side, I would ask 'how much market am I alienating by not supporting a feature, and how much market share can I gain touting this as a differentiating capability relative to my (many) competitors, regardless of whether anyone actually uses it or not'.  Because, as we've establish, the cost to the vendor of the feature per board is smaller than the cost of your power jack.

Selling hardware is hard - I guess that's partly why its called hardware?  no?  Well, anyway, much like anything else, you are competing and you want to convince people your ice cubes are colder than anyone else's...

@hanzibal, yes you are right, basically, the hardware RNG described is (ostensibly) using quantum phenomenon to generate true random numbers because of avalanche breakdown, wilt self-destruction limited by the resistor to the high voltage, and amplified to a signal the chip can sample and use.

The STM chips use a similar analog technique; they aren't explicit about what it is, but I don't think it's avalanche based.

The 12V is possibly OK instead of the 20.  The higher voltage is desirable because it makes more noise, but really since you probably don't want to use the random numbers directly from the generator anyway, its likely OK, since I imagine you are going to do what is traditional and suck a long sequence of them in to seed into a CPRNG like blum blum shub or something like that.  If 12v is enough to get you some random noise, but with color that you can diminish sucking more in, then that's probably better than fighting the voltage problem.

Alternatively, if your really want the voltage, you could try making a simple charge pump with some discretes and a free PWM pin if you've got one.

Well I may have to join you in that effort; I need to do the same thing as my project goes beyond the lovingly-hand-deployed-by-the-author pilot phase.

I did a little work on an STDFU-based deployment, this work was really for flashing the netduino firmware, but as I mentioned that approach can also deploy the app.  Details here, as well as functioning source:

http://forums.netdui...ributors/page-3

this is an incomplete project from UI and usability, but the important bits of flashing firmware work correctly.

I also did a mostly unrelated thing -- it had to do with assigning the MAC address to a board as a manufacturing step -- but I mention it because it is a desktop app that uses the same assemblies the MFDeploy does.  It might give you some ideas on the firmware deployment.  Then again, quite possibly not, but you can decide if its of any use:

http://forums.netdui...el-and-barcode/

Personally, as I mentioned, I find it handy to deploy both the (netduino) firmware version with which QA tested my application, along with my applicationitself, but I can appreciate the MFDeploy approach.  Plus, there's always the network settings which are easier to do via MFDeploy.  Oh, and plus you don't have to hold down the button.  Which may not be so accessible when its in a box.

Lastly, another of my long pending mini-projects is to replace tiny booter with a mechanism to permit over-the-air updates.  I did a little work testing dynamically loading netmf assemblies.  The technique works, but it is a bust for me as a methodology because all the code is then in RAM.  If curious, it's described here:

http://forums.netdui...pdate-possible/

However, I am pretty sure I can make a tinybooter replacement to do it.  Tinybooter is meaningful on other netmf things, but it doesn't do much on netduino.  I built a firmware image with no tinybooter and it ran just fine.  The only thing I know of that the tinyclr does do is allow setting of stuff in the config sector.  And it can, it just doesn't.  So there's 48k of code space available for something fun, like checking SD for an update image, flashing it, and rebooting.

Anyway, this is one of my ponderously long posts, and I apologize for that, but as Blaise Pascal once wrote 'I apologize that this is long, but I lacked the time to make it short'.  Ha!

truthfully, for the logging I described, I would forgo the filesystem altogether, and just have a fixed allocation of blocks, each containing a header with a generation number, and use the ancient 'ping pong' approach on the last block; i.e. using two blocks, and alternating which one for each write (incrementing the generation number).  You'll never lose more than your last record due to power outage.

For the databas-y stuff, the logic in, say, sqlite, already presumes a linear array of blocks for filesystem and transaction log, so it should be easy(ish!) to port to some non-file-but-nonetheless-sane-api storage.

As it seems to have been a trend today in my posts, I can't find time for firmware modding, but when I do I will!  At this rate, practically, it may be August2013...

hi,ziggurat29,the stm32F40X and the stm32F41X almost the same,if you use the .net micro framework for them,many funtions are not available...

not sure what that means, I rebrained one of my NP2 with a  F415 and it works quite well.  But yes you need firmware support to expose the crypto to the user.  But you weren't talking about firmware right?  And I got the 415 for 50c more than a 405 in unit quantities at mouser.  Since this is not a user-serviceable part, why not put on the better one?

While I'm on the sandbox, its also pity that the hardware RNG is not exposed since all the chips have that (and coincidentally someone was just today trying to manually make a noise source to implement a hardware RNG), but that is a firmware issue and admittedly not germane to your original post.

...stm32F439 the price is too height and not released to the market yet,i think not that many people are going to use it for production befor the price drop~~

is it not out yet?  anyway, yes it is a higher end one, so I retract that suggestion (unless you want the higher end stuff).  I was merely coveting the better crypto modes.

Now, if they just would make one that had:

*  on-chip secure storage of keys (e.g. write-only, and preferably metal-over sensitive bits)

*  RSA acceleration

then the world would truly be a better place.  Until then please do consider splurging on the 50 c for a 417 to make it nice for the people.  or at least the cryppies.

MFDeploy is supposed to be able to.  I personally have yet to get it to really work, though.  Rather than re-typing, deets here:

http://forums.netdui...oading-my-code/

On the other hand, all the mfdeploy stuff you can write your own app around, so maybe you get get it to work programatically.  I've been meaning to try, but I am swamped.

Lastly, you can make a DFU for your app and do it like a firmware update.  I do do this.  Moreover, I combine the firmware image with my app image into one DFU, and that serves as the master copy.  Side benefit being that I am deploying with a known version of the firmware with which we have tested.  You'd think newer versions would have less bugs but not always!

in a slightly different direction -- the STM32F has a hardware RNG on-chip.  The world will thank you for a firmware mod supporting it if you can swing it.  I'll do it myself eventually, but I can't seem to get back to firmware modding just now....