OK ! I coughed, now I’m suffocating !
I’ve seen some posts on that effectively… GCC alone will be sufficient as well ?
I also heard about a free version of KEIL, but limited in some functions…Would it be enough or the NETMF is in these limitations ?
Yes GCC should be enough to build. If you want to debug then you will probably need a nicer IDE. My favorite is CrossWorks for ARM:
Here is the thread I was talking about
http://www.tinyclr.com/forum/topic?id=10015
The free version of Keil MDK is codesize-limited; it won’t be able to compile the firmware, which is too big.
NET MF 4.2 doesn’t support recent enough GCC versions to be able to compile the STM32F4 port (the STM32F4 is a new Cortext-M4 processor).
NET MF 4.3 supports newer versions of GCC, so you’ll have to get the FEZ Cerberus port into a 4.3 build tree (which will take some modifications, mentioned by Architect).
Personally, I think the moment you can afford to buy MDK, you should. It produces extremely high-quality code, has great Eclipse integration, and it’s the industry-standard tool for Cortex-M development. GCC code is also generally considered less optimal than MDK code (though I don’t want to start a flamewar, and I acknowledge that GCC code is getting much, much better).
@ jay -
That is effectively what I was seeing on this thread : http://netmf.codeplex.com/workitem/1346
I have in my contact cards, someone in ST Micro France…I will try to negociate a price with him if I can…
Both NicolasG and I have built 4.2 using the same version of GCC that was used for 4.3. NicolasG has submitted a codeshare which contains the required patch to build the Cerberus 4.2 firmware with GCC.
@ taylorza - Thanks also to yu,
But your version is also based on 12MHz oscillator…If it is the source of my problem, it wont help…I’m going to try with Jay compilation and telle back…
@ jay - Just tried the package.
Tinybooter deployment is OK with ST-LINLK, but I have the same problem installing the driver : not found, even with all the GHI provided one !
Here are the VID and PID that feedback : VID_8087 & PID_0024…
If I can not install the USB Driver correctly, I wont be able to deploy the other Hex files…
That is easy enough to change and you can then just build it yourself using GCC. If you follow the steps provided it is easy to get the build going.
Back in post #14 Jay explained what needs to change to support the slower clock
http://www.tinyclr.com/forum/topic?id=10574&page=2#msg105957
Yeah, that happened to me, too. You need to force install the GHI WinUSB driver as I mentioned – what happens when you try to update the driver in Windows Device Manager? You may have to unplug the device and plug it back in once you update the driver.
@ jay -
Cool, now it is in ! Let me try a tuto for FEZ…
Awesome! I’m glad it worked. Should be smooth sailing from here on out!
@ jay - OK
I can reproduce my output leds blinking, but for everything else, I understand better now where is the problem in changing the firmware for a given board : the platform_selector is the heart of everything !
As my board is based on Discovery, many Pins are not facing between the Disco and the Cerb, so I defintely need to purchase a suffocating licence for RVDS or KEIL MDK if I want to do somehting with the capabilities of the Cerberus Modules (ENC28, SD and so on) and my based board !
Bouh !!! It should be so simple if for one given processor, there was one and only one selector…
You shouldn’t have to change the firmware at all. But you do need to understand the .NET ecosystem a little better, I think.
The firmware you’ve loaded on your board exposes (and abstracts) GPIO and peripherals (PWM, SPI, UART, etc). NETMF allows users to user a serial port in their design without having to actually understand how it works, or how to configure the STM32F4’s serial peripheral.
Gadgeteer modules (the ENC28 and SD card modules you’ve mentioned, for example) abstract the hardware one step further. They abstract entire hardware modules, which may be comprised of several pins, and multiple types of communication peripherals.
For example, the ENC28 module uses an SPI interface (with a clock pin, a MISO pin, and a MOSI pin) which includes a chip select line as well. The chip also uses an interrupt pin which it can use to tell the host processor that data is available. It also has a WOL pin (wake on lan) which (I assume) can be used to signal/wake up the processor on a WOL packet.
That’s a lot of pins to remember! Gadgeteer abstracts the ENC28 module by assigning a port type. When you create a new instance of the ENC28 module (by dragging it into the Program designer window, or by hard-coding it and adding a reference), the argument you pass to the constructor is the Gadgeteer port number.
If you want to be able to use Gadgeteer modules, you have three options:
[ol]Use exactly the same pinmapping between the module and the FEZ Cerberus when designing your board. This allows you to run your existing Cerberus code without making any code changes.
Modify the Gadgeteer module code and add a second constructor (or whatever) which initializes the Gadgeteer module with hard-coded pin/port values)
Create a new Gadgeteer motherboard (it’s really not that hard) which uses the proper pin definitions for everything. [/ol]
Obviously, you’ve already designed your board, so option 1 is out. Maybe option 2 would be best?
The source code for the gadgeteer modules is available here: http://gadgeteer.codeplex.com/
Download it, and add each module that you want to use to your project. Make sure to add references to each module in your main project. Then, modify each module’s code to add an additional constructor.
It’s sort of tedious – that’s why it’s always easiest to match the pinouts of the Gadgeteer motherboards!
@ jay -
In solution 3, that I’m starting, you mean that I only need to modify the FEZCerberus_42.cs Class and it will apply the new socket mappings ?
So no need to modify the platform_selector, and I can continue with the Discovery firmware ?
If yes to these points, It’s amazing to have learn about you !
Yeah, you shouldn’t need to modify the firmware. Gadgeteer is entirely written in C# – there is no native code to mess around with. You basically just need to tell those gadgeteer modules which pins/peripherals on the chip belong to which “sockets” – since your board you made doesn’t actually have any real sockets, you’ll just have to fake them. Create a fictitious “Socket 1” that is an S type (or whatever) for your ENC28 module, and define the pins for that socket, etc.
Does that make any sense?
I would start out by snagging the FEZ Cerberus Gadgeteer code from http://gadgeteer.codeplex.com/, and then just adapt it to your design. It sounds like you’ve got a good handle on what’s going on! Good luck!
@ GUS,
My Mainboard MSI is now OK, buit somehting is strange. However I replaced all FEZCerberus string in all the solution and properties, the Installer continue to name all the installer files as FEZCerberus…
Any Idea on where it is going to search for the name to apply to the MSI ?
@ LouisCpro - Have you changed the strings in common.wxi ?
@ Justin -
Yes, a CTRL-H made as in the procedure…and when I search for FEZCerberus in the entire solution : nothing returns 
Did you create an now Main Board using the template or copy and rename the Cerb?
I created my Scorpion driver from the template without issue…