Feature requests for messageport please

Let Sim Innovations know about your Air Manager experience and let us know about your dream feature addition

Moderators: russ, Ralph

Message
Author
User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Feature requests for messageport please

#1 Post by jph »

Hi @Corjan

Can I please request the following for messageport ?.

1. Increase in serial port speed options for the newer VCP boards which can easily handle greater than 1000000 baud (1Mb). Normal steps are 250k, 500k, 1Mb, 2Mb
This enables multiple dedicated I/O daughterboards to be connected to a master controller unit using messageport.

2. Selectable serial port parameter (Serial 1, USBSer1 etc) to pass to messageport and enabling more than 1 instance of messageport to be running. An Ideal use case would be for dual core processors like PICO which can each address it's own VCP / messageport and code.

3. Please can we add the following board types for messageport as they are ALL fully tested and 100% compatible with the new beta VCP modification, extremely powerful, feature rich and they are ideal modern replacements for NANO, UNO and MEGA type boards and even have the appropriate footprints / header / shield options as can be seen in the attached images (BUT FAR MORE I/Os available via other headers). The boards are available up to 450Mhz core speed with up to 2MB Flash and
up to 1.5MB SRAM. ALL fully supported by ST Micro themselves in the Arduino IDE. ST Micro are fully involved with the Arduino IDE Core support and have full help services and forums dedicated to Arduino core. Most of the products have a 10 year production guarantee of continuity.
In each range - 32 64 and 144 pin devices there are MANY board options to chose from in the IDE, but the master heading for the types is the same. They are all STM32 ST Micro and the type headings are Nucleo-32, Nucleo-64, Nucleo-144


The names of the units (covering that group range) I would suggest are (as these are also as they are in the IDE under these main headings)
STM32 Nucleo 32
STM32 Nucleo 64
STM32 Nucleo 144

Images of examples of an example board from each family,32,64 and 144 are below.
STM32 Nucleo 32 example (same footprint as nano)
STM32 Nucleo 32.png
.
STM32 Nucleo 64 board example from the range
Nucleo 64.jpg
.
STM32 Nucleo 144 board example - this one has a USB type 'C' Connector, 2MB flash and 786kb SRAM and around 100 gpio pins. It runs at 160Mhz. It costs 23 USD (less than half the price of a MEGA). Same boards in the Nucleo-144 range are available with Ethernet AND 2 USB on the same board and up to 450Mhz core speed!
144.jpg
Here is some general info on Nucleo boards
https://www.st.com/en/evaluation-tools/ ... oards.html
Thanks.
Joe
Joe. CISSP, MSc.

User avatar
Corjan
Posts: 2936
Joined: Thu Nov 19, 2015 9:04 am

Re: Feature requests for messageport please

#2 Post by Corjan »

Hi,


1. The way the code is structured right now this is quite impossible. Besides, for normal I/O like uses, the current baud rate is sufficient. If you want multiple boards, why not all connect them to AM seperately?

2. This will be added in AM 4.2

3. Will add those in AM 4.2.


Corjan

User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: Feature requests for messageport please

#3 Post by jph »

Thank you @Corjan

That is absolutely great news,

The main thing is having selectable com ports and being capable of calling multiple instances of messageport.

I am sure that will suffice at the current speed.
Just for info the reason for not connecting multiple boards is due to the 'daughter boards' not having their own USB link as they are controlled from a master board. The daughter boards handle the port expansion and buffering.

Many thanks, very much appreciated. :D

Joe
Joe. CISSP, MSc.

User avatar
Corjan
Posts: 2936
Joined: Thu Nov 19, 2015 9:04 am

Re: Feature requests for messageport please

#4 Post by Corjan »

Hi,


Personally, I never understand why you would want to use an embedded device as a middle man.
PC's have way more resources then any embedded system would have. Having the PC act like the master is more reliable in most cases.
Also creating another hub in the system only adds to the general complexity of the system.

Anyway, rant over :)

Just tinkered a bit. This is what you meant right?
image.png

Corjan

User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: Feature requests for messageport please

#5 Post by jph »

Hi Corjan,
Rant away :D - no worries, it is always interesting to consider other perspectives.
There are many reasons for having centralised devices- one huge one being to buffer I/O. I am absolutely NOT a fan of interfacing directly to a micro. Then there are systems such as the SISMO units in play - which I intend to interface to (some of them) - some are simply not worth interfacing to :lol: But hey, different strokes etc ;)

The serial port selection I am referring to is in the device (micro) end of the equation. I don't see an issue at the AM end as it already allows port selection from the pull down menu under device - add etc.

It is on the micro end - the messageport lib.
For example, on a specific device I may have 'Serial', 'Serial3' or 'USBSer1'
Messageport lib is, at the moment, fixed to 'serial'

It would be beneficial to be able to NOT have this fixed. Obviously it could default to 'serial', but have the option to pass the port to messageport when it is instanced.
It would be that way anyway - as far as my head will work today (migraine :cry: ) - with multiple instancing of the messageport object as it would need to have the port passed at the time the messageport is declared.

so, something like -

Code: Select all

SiMessagePort* messagePort(Serial);
SiMessagePort* messagePort1(Serial3);

//then under
void setup() {

messagePort  = new SiMessagePort(SI_MESSAGE_PORT_DEVICE_RPI_PICO, SI_MESSAGE_PORT_CHANNEL_A, mp_1_callback);
messagePort1 = new SiMessagePort(SI_MESSAGE_PORT_DEVICE_RPI_PICO, SI_MESSAGE_PORT_CHANNEL_B, mp_2_callback); 
}

void mp_1_callback() {
}

void mp_2_callback() {
}

It would actually be under setup() and setup(1) for the cores - but that is academic.
.
AM would then take care of itself as it would see the two ports and allow selection as normal.

Apologies again - I have a really bad migraine forgive any typos.
Joe
Joe. CISSP, MSc.

User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: Feature requests for messageport please

#6 Post by jph »

Hi @Corjan
Just to clarify - I am NOT intending to run multiple micros into a central micro :) - I mentioned it 'could' be done, but that is not my intention.
My 'centralisation' if we call it that, is to run a single central microprocessor for each main cockpit sub-section - pedestal - Overhead, MIP and Throttle/flight controls - pico most likely (almost certainly in fact) - as a central driver and master for the SISMO daughterboards initially - they are I believe - I2C linked to the main Ethernet boards but I haven't bothered putting the logic analyser on them yet - well, mainly as I just updated my logic analyser to a 400Ms/s unit and haven't yet fitted the update sdram -and eventually for my own I/O boards which will not have their own processors, well, apart from the nice core logic in the SX1509 units. It is mainly - per cockpit subsystem - one central processor (dual core, multi com port) that is linked to the main I/O subsystems via SPI and I2C. There is also a master controller I need to make which acts as a protocol converter from multiple serial messageports to single Ethernet via - in that case - probably a Nucleo board - to drive the SISMO Ethernet Mainboards. These will all be replaced with my own boards at a later stage - which are all I2C and SPI subsystems from the main dual core processor.
Just so you don't believe I am 'completely' crazy :lol:
I am definitely not building a multi serial micro serial concentrator :D
Joe
Joe. CISSP, MSc.

User avatar
Corjan
Posts: 2936
Joined: Thu Nov 19, 2015 9:04 am

Re: Feature requests for messageport please

#7 Post by Corjan »

Hi,


Nucleo boards have been added in code, they will be part of official AM 4.2 release.
Will not persue the multiple Message port thing, it is a bit of an edge case, and having one message port should suffice in most cases.


Corjan

User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: Feature requests for messageport please

#8 Post by jph »

Corjan wrote: Thu Dec 22, 2022 12:17 pm Hi,


Nucleo boards have been added in code, they will be part of official AM 4.2 release.
Will not persue the multiple Message port thing, it is a bit of an edge case, and having one message port should suffice in most cases.


Corjan
Hi Corjan
So multiple instances of messageport are not possible? (and it is not possible to pass the serial port in use to messageport at the time of initisalisation ?)

Joe
Joe. CISSP, MSc.

User avatar
Corjan
Posts: 2936
Joined: Thu Nov 19, 2015 9:04 am

Re: Feature requests for messageport please

#9 Post by Corjan »

Hi,


You could easily do that if you start hacking the existing library sw.

But since this will probably be a breaking API change, I don't think it is worth making it official


Corjan

User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: Feature requests for messageport please

#10 Post by jph »

Corjan wrote: Thu Dec 22, 2022 1:50 pm Hi,


You could easily do that if you start hacking the existing library sw.

But since this will probably be a breaking API change, I don't think it is worth making it official


Corjan
Hi, thanks for the reply. That is all I requested that you initially agreed to.
The ability to pass the serial port in use.
As it would be optional, it would not - as far as I can see, 'break' the api as surely it would default to 'serial' with no extra parameter.?
By the look of the layout of the existing lib it is purely the fixed serial port that stops multiple instances - or, to be more accurate - already allows multiple instances to be called but always defaults to 'serial' hence one call is overridden by the other due to the inability to define a serial port and always using the default.
Thanks
Joe
Joe. CISSP, MSc.

Post Reply