Edit: Scroll down to my latest posts to get the latest version.

Since it is time to share it, even though it is far from perfect, time for a topic.

Ever wondered which platform you should take for a project? Only to find out that the mbed platform main page has extremely limitted filtering abilities? Want to know which platforms support CAN and have an RTC on board? Or you want to use the new low-power timer, but you would like to know which boards besides the Gecko boards support it? (Hint: not many). The solution is here :P

https://developer.mbed.org/media/uploads/Sissors/supported_NnZtQEm.htm

The RAM/ROM sizes and core type are not sortable/filterable, but all others columns are (click on the column header). Also at left top you have a search box, if you only want to see LPC devices for example.

Some background and other notes:

This is all automatically generated using a python script from the mbed source code, see for the python code: https://github.com/Sissors/mbed/tree/master/workspace_tools/data_scrape. Now this is my first time using python, javascript, html and css (hopefully also last time css, seriously what a horrible abomination that is), so it won't exactly be nice code. Especially the html since that is also generated code.

The good part: Since this is automatically generated from the mbed source code, no one can cheat (to be fair, it is not perfect, I believe the RZ A1H has a wrong RAM size extracted, it uses a completely different memory structure, making it a bit a pain in the ass). Some Nucleo boards have CAN, yet it shows for all no CAN in the table. Why? Because none of them have it enabled within the mbed code. The NRF51822 boards have 16k RAM, yet show 6k. Because that is the actual usable amount of RAM by the user.

And last but not least: Also https://developer.mbed.org/users/sarahmarshy/ helped with writing the python code (she can actually write p

This is great. I noticed a couple things that you are probably still working on. The K64F and Arch PRO have ethernet but are not listed. (the Arch Max has it, but I don't know if the libraries support it yet) It would also be nice to see which parts support USB.

Thanks for creating this and making it available.

Grrr stupid bugs :P.

In my defense, it is because of the source code, see; https://developer.mbed.org/users/mbed_official/code/mbed-src/file/61103edf8a92/targets/hal/TARGET_Freescale/TARGET_KPSDK_MCUS/TARGET_MCU_K64F/TARGET_FRDM/device.h. Ethernet is happily set as not available. But I think there is an ethernet part in the mbed lib, and in the EthernetInterface lib, and only the LPC ones use the part in the mbed library. Or something like that.

So missed those, also for other, please report bugs if you find them, it is work in progress, but I am not aware of all bugs probably :).

I will then probably looking at doing USBDevice and EthernetInterface seperate, and directly linked to their respective libraries. Similar to the current extraction of values this won't be perfect: I will for example simply use this file: https://developer.mbed.org/users/mbed_official/code/USBDevice/file/f3cad7e6984e/USBDevice/USBEndpoints.h, and see if one of the defined match the list of macros set for the target.

For USBHost I think I might as well skip it, they have obviously deprecated the official usbhost library and you are better of using: https://developer.mbed.org/users/va009039/code/F401RE-USBHost/

And then you already run in the next issue: If you scroll to the right in: https://developer.mbed.org/users/mbed_official/code/EthernetInterface/file/2fc406e2553f/EthernetInterface.h, you see it is set to compile for all Nucleo F4xx targets, which sadly will not work for part of them.

Nice table.I hope that gets integrated into the platform page.

It would it be helpful to have a column that lists the actual processor type (and vendor). It is often clear what processortype is used from the board/platform name (eg nucleo's), but some boards use a fancy name that provides no info at all (eg Dipcortex, Seeduino, Xadow, mBuino, Redbear, Wallbot). Many of these boards dont even mention the type in the brief description on the platform page.

Update: Similar issue to Ethernet can also happen with USB, although currently it might not be a problem yet. See: https://developer.mbed.org/users/mbed_official/code/USBDevice/file/f3cad7e6984e/USBDevice/USBEndpoints.h, someone could for example also add for the Freescale ones simply #ifdef TARGET_Freescale. And then my code would see the KL05 as having USB. So something I need to think about if I would add it and hope no one does it, or not add it at all. Or a better solution if someone has it :P.

@Wim, that would be nice indeed. Then it could also be included in the targets.py file for more data, for example if a target has USB peripheral.

Regarding the actual processor type and vendor, the irritating part is that it is not standardized. The information is there, but can be anywhere. For example the mbuino:

class OC_MBUINO(LPC11U24):
    def __init__(self):
        LPC11U24.__init__(self)
        self.core = "Cortex-M0"
        self.extra_labels = ['NXP', 'LPC11UXX']
        self.macros = ['TARGET_LPC11U24']
        self.supported_toolchains = ["ARM", "uARM", "GCC_ARM", "IAR"]
        self.default_toolchain = "uARM"

This makes it a child-class of the LPC11u24, and in the extra labels it says it is from NXP. Now most (maybe all), put the first extra label as the vendor, but there is nothing preventing them from putting the second label as the vendor.

Another one with a fancy name:

class MAXWSNENV(Target):
    def __init__(self):
        Target.__init__(self)
        self.core = "Cortex-M3"
        self.extra_labels = ['Maxim', 'MAX32610']
        self.macros = ['__SYSTEM_HFX=24000000']
        self.supported_toolchains = ["GCC_ARM", "IAR", "ARM"]
        self.default_toolchain = "ARM"

Here it is not a child class, but is the name of the actual MCU the second extra label.

Something to explore is getting it from the exporters, since they need the actual MCU name. It also has the vendor name, but I already saw that NXP for starters is being irritating with having "NXP (Founded by Philips)" as vendor name for many :P. (Problem is it takes too much space in tables).

Hi Eric, great work! What about PWM? Maybe external interrupt supported on all GPIO pins? 5V compatible I/O, but that is more hardware than software related.

I removed PWM since every one of them should have PWM (only LPC812 lacked it, but they added it here now also). Problem with interrupt capabilities is that it is close to impossible to extract, since it is only checked when the interrupt is set. And then there are also targets like the LPC11u24 which can set it on every pin, but can only set a limitted amount. Or the F401 who can set it on every pin, as long as not another pin on a different port but with the same number has it set.

5V gpio has simply the issue that this is nowhere defined in the source code. Would be a nice one if it is added in the python code for a platform somewhere though.

Good work.... But someone has to advice the chip vendors to stop strangling the community by not providing enough support to the board that they claim mbed compatible.

Perhaps the vendors should need to complete a form before their products can be added to the Platforms page. The form can have the columns of Erik's table, and checks need to be placed for every item to indicate 'implemented' and 'tested'. Maybe even "Sample code" available (per feature).

Vendor
Platform-name
ARM Core
Flash (kB)
RAM (kB)

Feature           mbed Library available and tested      Sample code     Notes and limitations
PORTINOUT         YES                                    YES                                              
ANALOGIN          YES
ANALOGOUT         NO
SERIAL_FC
SERIAL_ASYNCH
I2CSLAVE
I2C_ASYNCH
SPISLAVE
SPI_ASYNCH
CAN
RTC
ETHERNET
LOCALFILESYSTEM
SLEEP
LOWPOWERTIMER
...

That might help the vendors to complete the libraries before release, and helps us to make a choice.

I would like to get as much as possible directly from the source code, since that makes sure it is correct. But it would indeed be nice if they would need to fill in a standard table about the target to make the platform page better searchable/filterable.

I haven't had much time to work on it further (and didn't feel like it), but just looked a bit at getting the MCU behind the target, and I can now extract it from the uvision exporter (within reason, there seem to be kinda different naming conventions going on there too). Since enough do not support uvision exporter I will also need to add more, but it is a start. This is the output (it just exports to text now):

LPC11U24 is LPC11U14/201
Not found for OC_MBUINO
Not found for LPC11U35_401
Not found for LPC11U35_501
Not found for XADOW_M0
Not found for ARCH_GPRS
LPC11U68 is LPC11U68
LPC1114 is LPC1114/102
LPC1347 is LPC1347
LPC1549 is LPC1549
LPC1768 is LPC1768
ARCH_PRO is LPC1768
UBLOX_C027 is LPC1768
Not found for LPC2368
Not found for LPC2460
LPC812 is LPC812M101
Not found for LPC824
Not found for SSCI824
LPC4088 is LPC4088
LPC4088_DM is LPC4088_DM
LPC4337 is LPC4337
LPC11U37H_401 is LPC11U37/401
KL05Z is MKL05Z32xxx4
KL25Z is MKL25Z128xxx4
KL43Z is MKL43Z256xxx4
KL46Z is MKL46Z256xxx4
K20D50M is MK20DN128xxx5
TEENSY3_1 is MK20DX256xxx7
K22F is MK22FN512xxx12
K64F is MK64FN1M0xxx12
NUCLEO_F030R8 is STM32F030R8
NUCLEO_F070RB is STM32F070RB
NUCLEO_F072RB is STM32F072RB
NUCLEO_F091RC is STM32F072RB
NUCLEO_F103RB is STM32F103RB
NUCLEO_F302R8 is STM32F302RC
NUCLEO_F303RE is STM32F303RE
NUCLEO_F334R8 is STM32F334R8
NUCLEO_F401RE is STM32F401RC
NUCLEO_F411RE is STM32F401RC
NUCLEO_L053R8 is STM32L053R8
NUCLEO_L152RE is STM32L152RD
DISCO_F334C8 is STM32F334C8
ARCH_MAX is STM32F407VG
DISCO_L053C8 is STM32L053C8
MTS_MDOT_F405RG is STM32F405RG
Not found for MTS_MDOT_F411RE
Not found for MTS_DRAGONFLY_F411RE
NRF51822 is nRF51xxx
NRF51_DK is nRF51xxx
NRF51_DONGLE is nRF51xxx
ARCH_BLE is nRF51822_xxAA
SEEED_TINY_BLE is nRF51822_xxAA
HRM1017 is nRF51xxx
RBLAB_NRF51822 is nRF51xxx
Not found for RBLAB_BLENANO
Not found for WALLBOT_BLE
DELTA_DFCM_NNN40 is nRF51xxx
Not found for RZ_A1H
MAXWSNENV is MAX32610
MAX32600MBED is MAX32600
Not found for EFM32GG_STK3700
Not found for EFM32LG_STK3600
Not found for EFM32WG_STK3800
Not found for EFM32ZG_STK3200
Not found for EFM32HG_STK3400
Not found for WIZWIKI_W7500

How about adding the javascript file from http://www.kryogenix.org/code/browser/sorttable/ to the page? It looks like it should allow sorting by name, core or memory size with minimal extra work.

edit If you did use that library it would probably be a good idea to enable to stable sort option in the code ( http://www.kryogenix.org/code/browser/sorttable/#stablesort ) so that you could say sort by RAM and then by core and get a list of parts with that core in memory size order.

I am currently using listjs (http://www.listjs.com/), which can also sort. Indeed sorting on RAM/flash and possibly core is on the todo list. Ideally you would be able to filter on core, but then I need to think of a way how you select which cores you want to filter for.

@Eric, you probably noticed some inconsistencies or errors in the nucleo list.

NUCLEO_F091RC is STM32F072RB

NUCLEO_F302R8 is STM32F302RC

NUCLEO_F401RE is STM32F401RC

NUCLEO_F411RE is STM32F401RC

NUCLEO_L152RE is STM32L152RD

Maybe it's wrong in the sourcecode..

Thanks for actually checking it Wim, since I had only done quick glance over it and missed it.

Issue is what you say, the extraction is correct, this is what is in the exporter templates. Th top one is clearly a copy paste error by someone, but it really says it (verified it manually). I guess the others are similar enough that it is fine for compiling, but tbh I don't understand the reason behind it.

And just to make sure I wasn't randomly copying the wrong field (just took one which seemed to make sense), I actually exported it from the online compiler (I am in a lazy mood, so thats really a large task atm for me :P). Result:

So thats the issue: It is hard to get it correct if they put for some reason the wrong MCU in the exporter files. Maybe the other exporters are different :).

Actually, some platforms were removed, I don't know why: - y5 LPC11U35 mbug - y5 nRF51822 mbug

Hello Eric, I think this table is really useful. Any chance to get an updated version with latest target and latest code base?

If I don't forget I'll run it in the weekend again.

Your wish, is my command:

https://developer.mbed.org/media/uploads/Sissors/supported_NnZtQEm.htm

I made a new version since I suddenly had an idea where to get CPU speeds from (RTOS):

/media/uploads/Sissors/supported_AyVLg1y.htm

I don't know yet if I should keep it though, since it is a bit limitted, this is because:

1. Quite some simply don't have RTOS support, so they are missing.

2. Quite some RTOS defines are simply stupid. For example the ARCH_PRO is not defined, because the RTOS defines are set for TARGET_LPC1768 while the ARCH_PRO only has TARGET_LPC176X defined. (Technically also belongs to 1, but there are multiple of these and it is just stupid

3. That RH-AZ was completely ported with its own RTOS files, and they kept the clock speed on the default 12MHz, pretty sure it does not run at 12MHz.

Is there anyway for this to be a sticky? Or have a permanent place in the wiki? Or something along those lines? This is just too useful for it to be missed by users.

The cookbook is considered redundant by mbed staff (no idea why, since it isn't), and edit rights on the main page have been removed, so it cannot be placed there (at least by a humble user). Initially they were actually quite enthousiastic about this themselves, and the possibilities of integrating it on the platform page (which would be really useful imo).

On their request I made a pull request on the github for it, one of their interns helped on it, and then it went really quiet. So in the end I removed the pull request, reverted a few things, and sometimes I do a bit of work on it. Especially with the new classes that are only available on Silicon Labs devices I think this, and especially properly integrated in the platform pages, could really help people. But lets face it, they don't care about regular mbed anymore.

Then what do they care about?

mbed OS I think.

Erik ,we do care. I recall that PR, I find it useful we just did not agree how to be integrated. We shall talk to Sam and Brian to see what we can do here.

The mbed OS is the focus as it should solve many issues we/you/others experienced either with mbed, or other "frameworks".

Removing a post that was off topic.