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 64 board example from the range
.
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!
Here is some general info on Nucleo boards
https://www.st.com/en/evaluation-tools/ ... oards.html
Thanks.
Joe
Feature requests for messageport please
Feature requests for messageport please
Joe. CISSP, MSc.
Re: Feature requests for messageport please
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
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
Re: Feature requests for messageport please
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.
Joe
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.
Joe
Joe. CISSP, MSc.
Re: Feature requests for messageport please
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?
Corjan
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?
Corjan
Re: Feature requests for messageport please
Hi Corjan,
Rant away - 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 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 ) - 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 -
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
Rant away - 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 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 ) - 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() {
}
.
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.
Re: Feature requests for messageport please
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
I am definitely not building a multi serial micro serial concentrator
Joe
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
I am definitely not building a multi serial micro serial concentrator
Joe
Joe. CISSP, MSc.
Re: Feature requests for messageport please
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
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
Re: Feature requests for messageport please
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.
Re: Feature requests for messageport please
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
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
Re: Feature requests for messageport please
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.