HI,
I would like you to offer me a little help here:
I downloaded binaries for STM32F4 Discovery board from Oberon and was able to load it
successfully to the board. When I used the MF Deploy to ping I got the reply … TinyClr indicating successful
deployment just like any other dot netmf board. However when I deploy code from Visual studio, Windows 7 (64bit) complains that
one of the usb devices malfunction. Subsequent pinging would not work unless I erased the chip
and reload the board with the binaries again using St Link utilities.
I already checked the wiki on modifying the discovery board but others say you could easily use the oberon
binaries without any modification.
Can you please help so that I can start using the dot netmf on my discovery board?
This was just posted on hackaday STM32F4 Discovery Board running .NET MicroFramework – SITE RELOACTED | Site Moved
@ Farsa - Great link! Thanks!
Thanks for your quick response its being really helpful
It takes some time to me to understand between the 2 USB drivers USB ST-LINK and USB For Evaluation, and find the right links to those driver updates…
How does a device with 192KB of RAM run the CLR? I thought it required 300KB.
Looking at this thread : Understanding .NET Micro Framework Architecture | Microsoft Learn
NETMF CLR is about 390KB when all the provided functionnalities are provided. I guess that probably it is not the case for the STM32F4DISCOVERY…
From Flash. Notice that the Cerb family has 300KB of free flash, 112KB of free RAM, out of the STM32F4’s 1MB of flash and 192KB of RAM. Presumbably, the 724KB of flash and 80KB of RAM are taken up by the CLR and booter, et.al.
The 300 KB are for the code, i.e. for Flash memory. Depending on what is linked in, the code size can be larger or (somewhat) smaller than this number.
For very simple devices and applications, 64 KB RAM can be sufficient. You can’t go much below that size though. From this perspective, 192 KB is almost pure luxury, at least as long as you don’t need to process images.
For a better understanding of our NETMF port’s memory map, you might be interested in this document:
http://www.mountaineer.org/app/download/6083569375/NETMF+for+STM32+-+Tour+d'Horizon.pdf?t=1339779332
That pdf is excellent for explaining thanks.
@ Cuno -
Not so sure in fact that 192KB is sufficient in my case. I make some tests with the Enthernet mountaineer board for several days, and I achieved to see the board returning unsufficient memory overflows !!!
My program deals with a couple of Web Pages that I parse to extract or insert fields when posting. Then, I have some of them that play with some kb of datas (for example, the page that deals with ‘Time Management’ params.
the problem is that if I use a spimple String.Split to seperate my several fields, I reproduce this amount of data twice in memory, which occurs in a “BOUM !” of memory !
I did not ecnoutered such problems with the Chipworkx of course, which is far far away in tems of RAM availability !
So, image processing in not the only case where 192KB of RAM is a lake ! Just parsing some Html pages can provide the same target ! And if we consider that Ethernet can also mean to embed a micro Web site,…Also it means having some MB of RAM under the feet !
@ Louis I wonder if some of your memory though is in leaked sockets or similar rather than just the size of text you’re parsing.
The real issue with many of these lower memory devices is being able to use the data smartly - it’s relatively easy to use a string of text in chunks rather than trying to process the whole string at once, but images are one of those situations where you get “big” data volumes, and processing them often needs to be done as a whole (if you were post-processing the image for example). As Gus has said, “think small” ! 
@ Brett -
It is effective that we can imagine to make some optimizations to any treatment we have to play with in such lower memory devices, and it would probably be very fun to do, but as far as I’m concerned,
I definitively think it will be dangerous to do so regarding to my needs, knowing that :
I have several threaded treatments that play together on parsing pages, logging datas and so on,…
I do not know exactly when they will have to share the memory needs during their execution,
At least, it is convinient to let 30 to 40% of free memory space when calibrating these memory needs,
So, my reflexion was more on the relationship between having a board with Ethernet capabilities, and be able to take profit of cool functionnalities together, such as DPWS, HTTP, DATALOGGING and so on…
In other cases instead, where treatments do no require so much memory, but more processing (such as managing I/O, I2C, UART and so on…), the STM32F4 is a good choice for me.