Low-Level Interface Magic

I’m very much still learning how .net mf and gadgeteer all work, but the control freak in me wonders what is happening underneath the hood… For example,

  1. if a board has multiple LEDs, like that of the Cerbuino Bee, how does Mainboard.SetDebugLED(true) know which led to map it to?

  2. It seems the connector is a standard… but for custom applications, can any pin’s alternate function be selected? For example, what code would change SPI port pins to be all digital inputs?

  3. Is the file flashed with Fez Config used only for bootloading the user application, or is it something that is always running (like an interpreter/BIOS)? (I was suprised to see that I didn’t need to re-flash the user application after doing a debug session, take that Microchip!)

  4. What kind of performance (code size & MB/sec) would adding the SD/FAT support give? For example, if the application requirements are well known, wouldn’t a custom SD/FAT driver with just the needed functionality yield smaller code size and faster thruput?

The LED called by SetDebugLED() is one that is defined by the mainboard’s driver. This will always be an LED built onto the mainboard, not an LED connected via a cable.

This mapping is handled by the mainboard and module drivers. If you’re using Gadgeteer, then you will only have access to pins as defined by the markings on the socket (ie. “X” and/or “S”). If you needed, you could bypass Gadgeteer and access other modes of the pin but that may mean a lot more work. If you haven’t seen it, the Gadgeteer socket/pin standard can be seen here:

There are actually two things you flash from FEZ Config. The bootloader (Tinyloader) is there to help get the other bits installed. The part I think you’re referring to is the second piece, the NETMF firmware. These are the core NETMF libraries that the applications that you build will be dependent upon. They are always there. However, your app will only execute the parts that it references.

Sorry, I can’t help you with #4.

Hey Snoop, welcome to the forum.

I’ll add a couple of other additional points above what Ian said.

  1. If your mainboard has multiple onboard LEDs that are under user control (ie excluding ones that are power indicators), the only one that is flashed when using SetDebugLED() is the one the mainboard definition describes. If you wanted to, you could redo a new mainboard definition and pulse a different user LED… but I’m not sure any of the GHI Gadgeteer boards have multiple user controllable LEDs do they ?

  2. SPI is a good (or bad, depends on your view :slight_smile: ) example of how sometimes you can’t just re-use pins as a different function. SPI being a bus means that you can have multiple SPI sockets (marked S) using the same set of SPI pins, and if you use a device on an S socket that shares the same SPI lines as a different S socket, you can’t use all the pins on that other socket, just the ones that aren’t connected to both sockets. In general though, you can use all IO pins on all sockets when you deviate a little away from the Gadgeteer model as you would when you use the extender module, breakout module, breadboard module, or g-plugs.

  3. These functions are actually built into the NETMF image that the hardware vendor provides, so there’s no way you the end-user can influence if those functions were to be simplified (unless you’re using a totally open port of NETMF for your processor, but then you no longer have access to any value-add the vendor may supply). In my view, complexities in file systems and file handling are always significantly better dealt with at the firmware level as is done in NETMF.

A side note for the community: thks is a good example on why the new offers are either 100% gadgeteer or pure nermf. Hybrids confuse new users unfortunately.

I think driver is to big a term here, it’s simpler to say that it’s an abstraction layer (assuming we’re talking to developers). The complexity of figuring out which pin is which on a particular mainboard has been abstracted away in a data structure that let’s you map what you see on the pcb to what’s in the software.

You know what I’ve never seen? A document or video about just what NETMF can and can’t do. What’s it good for and it’s place in the microcontroller industry. (Wish I knew how to make videos).

Thanks lots of great info!

Coming from the Arduino and Microchip world, I find the gadgeteer / netmf incredibly powerful, but perhaps abstracted at such a high level, that it’s confusing in terms of how I’m used to thinking about embedded code development. But that’s more of a paradigm shift on my old brain than a criticism of the platform.

So if I understand correctly, in the case of the Cerbuino bee gadgeteer, that hardware runs netmf firmware that’s been specifically ported by GHI. Is this port typically open-source? For example, if there was a pin on the STM32F405 device that was not connected, could I solder a wire to it and modifiy/build a custom GHI HAL to make that pin available in software (input/output)?

Also if only the portions of this firmware that are needed in my application are linked in at build time, does this mean that if my application code did nothing but sit in a while(1); loop, then the entire 1MB Flash would be empty, except for perhaps the TinyBootloader?

it is a shift, yes.

There’s no “typical”. There are ports available for STM32F4 processors, that are open. The GHI specific port for the STM32F4 in use on the Cerberus family of devices is not open. You could use a different firmware, or modify an existing open port if you wanted to. There are also many more processors and configurations that have NETMF ports that are supported by vendors and they won’t be open. Again, in most cases you won’t need to worry about this. Back to the Cerb family again, typically all GPIO pins the processor have are available in the Cerb firmware so soldering to the pin would be all you need - you can check the GHI.Pins reference to see what it exposes. There is also a calculation that talks about pin naming and cpu.pin definitions, where pin PA0 is cpu.pin 0, and generally the formula looks like (16X)+Y where X is 0 for PA? pins, 1 for PB? etc, and y is the numeric pin. (I think it’s 16 may be 32*, can’t be sure)

If you have a “do nothing” app, you get access to most of the resources as per the “resources” tab on your mainboard, which is:
User Available Flash  384 KB
User Available RAM  104 KB
So you’d have close to 380K of flash (not that it matters - you can’t use it except for a program) and most of your 104k RAM.

@ snoop911 - [quote]Also if only the portions of this firmware that are needed in my application are linked in at build time, does this mean that if my application code did nothing but sit in a while(1); loop, then the entire 1MB Flash would be empty, except for perhaps the TinyBootloader? [/quote]
The entire .netmf firmware sits in flash all the time. Even if your program doesn’t link to it, it still takes up the space. The values mentioned by Brett are the maximums for the CerbBee platform.

Well the port was started by another company that was open source (I think mountaineer), and GHI added their secret source (RLP et al) to it and made it commercially viable.