I have an idea, what if we put the larger stm chip in our roadmap. So today, no rlp but in few months we would have the larger chip with both, maybe even Wi-Fi if it fits.
Looking the votes, usb host will be in the next release instead of rlp. And who knows, we maybe able to squeeze rlp back in the future.
F427 gets my vote !!!
Why not the F429 with LCD support. Doesnât seem to be much price difference.
LCD support requires a LOT more RAM, because (for NETMF) then you need bitmaps, big framebuffers, etc. You would really need external RAM at that point.
I need the USB host to support 3D Connextion 3d mice, which is super critical for my project. I can live with no RLP.
Or as people have mentioned, dual firmwares. It will be a support problem, but eventually the market will decide the fate. You could have a firmware with USB host for the Cerbuino and RLP for the Cerb40II. Just an option. We need USB Host 
Much of a muchness I guess. I agree with @ Godefroi since the RAM requirement goes up the more likely you are to use graphics.
So I own several Pandas and a Panda2 but I donât own a Cerbuino, so canât really say if my actual preference would be a Panda3 or a Cerbuino. Personally my Cerbs and Cerb40 even get targeted for new projects as much if not more than the Pandas. So for me, the Arduino form factor is not important, and if I put forward a âgo-toâ device itâd be F427 based device, many IOs, uSD support on-board, power supply (doesnât need 5v/3v3 external), RTC, and networking options for those projects that need it.
Iâm using the Cerbuino and Cerb40 in my project, and I intent that the STM32s be the only uC family there, if I can help it. I also want to add the CC3200 when it comes out later this month.
I agree with @ RoSchmi about why RLP should stay. I believe deference should be given to RLP since it is an existing feature that has been a part of the Cerb line for awhile. (At least in lite form.). Anyone who has built their project using RLP will be frozen at the current release. Since this affects an SoM it is even more important to maintain stability by not remove existing features.
(I am glad this discussion is happening now because I was considering using RLP with the Cerb40.)
I think the better option is to move forward with the larger F427 and add USB host to it. I would also encourage the use of the built in Ethernet. It would be a great single chip solution. And it would fit nicely between the current Cerb40 and the g120.
When you say âbuilt-in ethernetâ do you mean using the built-in MAC with an external PHY?
Iâm not sure what advantages that would have over ENC28J60. Doing drivers for the built-in MAC is much more complex, and while you might gain a tiny bit of speed, youâd lose a bunch of I/O.
Cuno could share more light on this, his group uses the built-in MAC for the Mountaineer ethernet board.
@ andre.m - Yeah, but they have lots of external RAM and flash. Also, doesnât one of the G400 variants use an ENC28J60?
@ godefroi - >:)
Stink youâre right it would need the external PHY and layout is a pain. Darn, so close to perfect.
I still think the F427 with USB is the way to go.
While appealing at first, I donât quite see this as the easier way.
Iâm pretty sure that, if you create another board line along Cerb family, Cerb will be marked obsolete pretty soon after the release of F427/F429 firmware, and given the assumtion that F427/F429 firmware contains both USB host, RLP and maybe even WiFi, weâll face the same RAM shortage issues we have now with Cerberus â at an additional cost of the chip.
I still think two firmwares for Cerberus is a better way, because youâve done that before with ethernet/non-ethernet ones, so it is not something entirely new for you. Besides, ethernet variant was tricky because it required an ENC28 chip to be connected, while RLP vs. USB doesnât not impose such requirements. So thereâs no risk that somebody flashes the wrong firmware to brick (well, sort of ) the board.
What about a compromise? For example, ship USB firmware as default one, but leave a way to replace it with RLP one if somebody wants to. I admit RLP is not for newbies, so anyone wanting RLP probably has enough knowledge to reflash the chip properly. Then weâll still have RLP option, and, as a side-effect, my countless hours spent on polishing âRLP in Depthâ manual will not be wasted 
@ Simon from Vilnius -
[ol]STM32F405 ÂŁ5.93 GBP +VAT STM32F427 ÂŁ6.74 GBP +VAT
Itâs only small changes in 2 filesâŚ[/ol]
It never works that way.
For example, F427 doesnât come in LQFP64 package, so replacing F405 with F427 requires redesigning everything.
@ Simon from Vilnius - Iâm just saying from a firmware point of view itâs 2 very small file changesâŚ
It is, because now (alright, not now, manual is still ok until the next release) I have to overhaul it (and the templates) significantly to remove Cerberus; Hydra has stripped down version of RLP, so a big part of the manual isnât relevant, too. Worst of all, full RLP is now only available on expensive commercial options sourced directly from GHI, and the thing I certainly do not want to do is speed up anyoneâs job that he or she is paid for.
But these are the tears to cry in another thread, letâs stay on topic.
It never works that way either.
SImon, what do you mean by this? What is it you do want to do? Thanks.
I have some good news! We took few bytes from the networking buffers and we now have RLP and USB Host. We still need to test some more testing but there is a good chance you will get both! Crossing fingers
Oh good news ! But Iâm really quite drastic and I would get rid of TCP/IP on this board.
:whistle: