I just discovered .Net MF - Have some general questions

Hello

Im new here.

I discovered .Net MF for 2 days and I have some general questions I still couldnt find answers to.

  1. If I well understand .NetMF supports natively a list of development boards.
    If I use an unsupported chip I have to port it with the Portal Kit.
    Imagine a use chip, lets say the STM32F4 (which is used on several boards and is natively integrated into .net MF 4.3), my own board and my own pinout configuration, do I have to use the portal kit (since the pinout configuration has changed compared to the supported dev boards)???

  2. I took a quick look at the portal kit (Delta) for .Net MF 4.2 for the ST32F4 chip and it looks like (well I may be wrong) that only 1 (of three available) I2C buses are available for .Net MF.
    In comparison, all 3 SPI buses seem to be accessible to .Net MF.
    Im wrong??? Why that limitation?

I will explain you my needs.

  • 3 independent I2C lines
  • TCP/IP Stack and Wifi support
  • 2-3 SPI lines
  • USB client

The G120 would have been a good option, even if its only a M3 and not a M4 like the STM32F4.It has a lot of memory Ram/ROM (needed for the TCP/IP stack) and GHI’s premium libraries that supports WIFI chips.
But it only has 1 I2C lines available. :-/
I could use an I2C Switch, but I fear to have a bandwidth bottleneck, so I prefer to avoid it.

So another set of questions:
3. Do you plan in the near future to sell a module like the G120 (small size module, Ram chip, Flash chip) based on a STM32F4 chip and that has 3 I2C lines available?
(Well have to check if this memory module doesnt use the pins used for the I2C buses)

  1. Do you plan to sell STM32F4 chips with preloaded .NetMF and GHI’s premium libraries (for the Wifi support)?

Thank you!

Welcome to the forum!

  1. Yes!

  2. You can’t select a particular bus for I2C in managed code. Have you tried to put all your I2C device on the same bus?

  3. and 4. for GHI

You can add drivers for the other I2C channels using RLP or through register access. You can do this on Cerb-family (STM32) or on G120. Of course G120 will give you much more options. M3 to M4 will only make difference if you do a lot of floating point calculations.

For reasons above, and most users need only one I2C, there is no current plans on adding support for multiple I2C masters.

I am assuming you already know I2C master can connect to multiple I2C slaves on the same wires and you need 3 masters for some very special needs.

Finally, when you say “USB Client”, you mean you want to use it for purposes other than debugging? If so then G120 is a much better option for you. Same if you need WiFi, G120.

Welcome to the community.

Thanks you for your quick answer.

I wilI need to drive ~40 I2C LED drivers (TLC59116, max 1MHz I2C) among other I2C chips (spread over 3 PCBs) and because of the addresses limitation I could only put max 14 TLC59116 on the same bus.
The solution would have been to use an I2C multiplexer/switch, but I fear that there would be a bandwidth bottleneck, especially since the multiplexers/switches are limited to I2C 400kHz.

I cant test now, Im still in the PCB design phase, I still havent a working PCB.
Theoretically I need less than 100Kbit/s data in the worst case, but since I havent used so many I2C chip on a single bus, I wanted to be sure that it would work and therefore use 3 independent buses. But maybe it will work with one.
Regarding the USB port, its for purposes other than debugging. A client software will run on a PC, and send some data over USB to the .Net MF application on the ARM chip. The next step would be to replace the usb connection by a Wifi one.

Ok then I will probably choose the G120. I initially wanted to design my own board with an STM32F4 QFP package but since it may probably require to write a portal kit even with Net MF 4.3, I abandon this idea (I have not enough knowledge about microcontroller programming. Im a Java/.Net developer).

Thank you

For that many LEDs you may need to implement your own native I2C drivers to gain speed.