Tutorials on electronics

Support for Arduino in combination with Air Manager and Air Player

Moderators: russ, Ralph

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

Re: Tutorials on electronics

#21 Post by Corjan »

Haha, it made me think of the one :)

Image


Corjan

JackZ
Posts: 2262
Joined: Mon Feb 22, 2016 1:02 pm

Re: Tutorials on electronics

#22 Post by JackZ »

@Corjan
I know that part of the problem is that the Arduino has a limited memory and it’s almost impossible to accommodate all the electronic items that could be hooked to such a card in a single « one fits all » flashed AM firmware.

Two ideas there:
Create TWO versions of the Arduino AM flash software with two sets of devices that could be hooked up. One should choose which version should be installed depending on the type of devices to be hooked with.
By this I mean that « usually » steppers are not mixed with displays for example, so what could be envisioned would be to have a « rotating hardware output » (ie steppers or micro motor) version of the Arduino flash (with some additional features such as acceleration for the X27 ) and multiplexers
And another version for a more wide range of selected displays (ranging from MAX to OLEDs and SPI displays) including some multiplexers

Of course the ability to use MessagePort should still be there for advanced users (or less frequently used items) and for both versions the basic interfaces such as switch/dials/buttons should still be present (as well for compatibility), but having two different versions would eventually leave some room for improvements and more displays, as not everybody is able to correctly use MP for it’s usage.

A poll could be a good starting point to know what kind of electronic devices could/should be added to the list, without being limited by the flash memory space available on the cards. In terms of Arduino programming, using memory size as the limiting factor for expansion of AM hardware interfacing capabilities is a reality, but some clever workaround is doable without being overly complicated. And this method of having two versions of the flash code would widen the range of hardware interfacing available with standard API (non message port)
My 10 cents.

Jacques
My YouTube Chanel on the A320 (Real SOPs by an Airline Pilot IRL):
https://www.youtube.com/playlist?list=P ... 0Q6SBASRqJ

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

Re: Tutorials on electronics

#23 Post by Corjan »

Hi,


Having two versions would only be confusing I feel like.

For now, the most common hardware is already supported by the Arduino.
In time, I think I have to leave the Arduino Uno and Nano behind, in a way that they won't support newer hardware.


For now, the TM1637 is the most requested (and will be included in AM 4.1). We don't get many questions for other hardware,

Corjan

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

Re: Tutorials on electronics

#24 Post by Corjan »

Hi,


Also, I don't wanne go into the rabbit hole that is extension boards.

A Raspberry Pico is probably almost as expensive as an extension board and is way more flexible.
Not to speak of the configuration complexity introduced when adding something like that.


For more tailor made hardware, message port should be used,

Corjan

JackZ
Posts: 2262
Joined: Mon Feb 22, 2016 1:02 pm

Re: Tutorials on electronics

#25 Post by JackZ »

@CorjanI agree with the extension boards problem. Too many variants to be able to cope with them.

Message port is a whole other problem, and I had (and still have) numerous problems to make it work, the board is not always detected by AM, the workflow with MP is really cumbersome (start the IDE, flash the Arduino, exit the IDE, start AM, wait for the board to be recognized (or not), test the software, shutdown AM, fire the IDE, etc...).

if eventually dropping the support of Uno and Nano solves your memory problem while allowing to use more devices, that’s fine with me.
But the Nano is still interesting by itself due to its small form factor which could be an issue in some cockpits. The number of pins available is still limited so complex or multiple devices would anyways be pin limited.
The addition of common multiplexers would be a nice addition

The message Port system is at the moment not reliable enough to be used easily ATM. The faulty catch and release of USB ports between AM and the Arduino IDE prevents a smooth workflow as far as my experience goes.

Jacques
My YouTube Chanel on the A320 (Real SOPs by an Airline Pilot IRL):
https://www.youtube.com/playlist?list=P ... 0Q6SBASRqJ

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

Re: Tutorials on electronics

#26 Post by Corjan »

Hi,


The message port itself works fine (it uses exactly the same system as the pin mode, only with different messages).

But programming for an embedded platform requires more care. You have to deal with more things then on a desktop system.
That is probably the issue.


I'm not saying we are dropping the Nano or Uno, just that new features won't be available on those platforms,

Corjan

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

Re: Tutorials on electronics

#27 Post by jph »

Hello Chaps, - and @Corjan - please read through as I hope it explains - IMHO - the relative lack of take-up of Message Port that I believe can be - fairly easily - fixed !
I don't know where to start here really as I can see many valid points in these discussions.
So can only offer my thoughts.
I agree with Jacques on specific versions of images for certain features - such as - for well tried and tested add on boards. - such as the PWM board I linked to, or the ADC input MUX - 16 bit etc etc. HOWEVER, I also fully understand Corjan's views with regards to user requirement's and, suggested features. Sometimes though, it is a matter of - 'build it and they will come' .. Indeed, it could be a major addition to the attraction of AM to potential cockpit builders. Some one perusing the features of AM may well be a new customer BECAUSE a certain option is supported.
As an example - take the previously mentioned PCA9685 16 channel 12 bit hardware PWM board.. originally provided as an add on board by Adafruit. WELL tried and tested and isnt going anywhere.

https://www.adafruit.com/product/815

and Using with Arduino / Library
https://learn.adafruit.com/16-channel-p ... it-library
As can be seen by my previous post on this board, you can get them for less than 3 euro plus postage.
The PICO, for example, cannot provide that functionality in such a simple way. I do not ever see a pico ever being a better option than this board. - such as -
https://www.aliexpress.com/item/3275375 ... 4c4dJmKn6z
Which is the exact same functionality and library etc as listed above per the adafruit unit.
Remember this is a full 16 channel hardware PWM via a single I2C output. It is a send and forget unit. Amazing. Not only as a fully 16 channel HARDWARE PWM servo controller, but also as a full 16 channel HARDWARE dimmable LED controller (both at 12 bits).. with full Arduino support. Even the most basic UNO can run a huge amount of these. Also you can add an I2C mux if needed to run other devices, but, not usually needed as the address of the devices are selectable.
Issues also come with the use of something like an adafruit library for commercial purposes - such as if AM wanted to include it in a specific image.. can be hugely complex in the area of IP with use of GNU/GPL etc..
IF there was an issue, then the code would have to be bit banged by AM using the 'wire.h' etc.
Anyway, I can see issues.

So what is the answer ?

Well, I think the holistic view is fairly simple in concept, but not so easy in practice.
It is, I believe, for the users to create an arduino sketch and sample code for AM Lua that uses these devices and that includes full examples etc - OVER MESSAGE PORT !.
That way, the devices and - working examples / code / support etc - can legitimately be advertised as 'available' to the community. Hence helping both AM for sales and new users who may well turn to another product for hardware, and also massively helping users of AM and expanding their options for hardware interfacing.
Using the board I listed above, with appropriate sketch / lua examples, then it can clearly be shown that the ability to drive a cockpit load of servos, or LEDS (fully dimmable etc) is easily available....

Now the BIG issue I see. -And please, anyone out there using Messageport tell me if I am on the wrong track here ?

There is, as far as I see, a big problem with message port. Not in it's technicality as such, but in the way it is seen by Arduino users. It is using concepts such as 'struct' etc that are simply not really used with Arduino hobby programmers in 99.9% of cases. Hence very little info - at the level of most of us (well certainly ME!) fully understands. I understand and learn, in most cases, by seeing specific, targeted examples.
A true C++ programmer like Corjan probably sees the use of the struct etc as absolutely normal. But to me, it is not - FOR ARDUINO USERS .
I don't think I am alone here ?? possibly I am :? .
Yes, we can get the most basic examples to work from the limited description on the AM wiki. But after that, there is nothing to really reference to in terms of Arduino.
I have also had connection issues, but have found it is usually down to overloading the buffer with too many calls. But, again I see this as a lack of info.

What I think would move AM on in leaps and bounds is to add real world examples to the message port library. Several!. Ones that include most aspects of the Arduino end of the code in the respect of breaking down the RX and TX of the make up of the 'struct'. This is how the vast majority of proficient Arduino programmers learn - by real world example(S) and experimentation
I am sure if that was done with MP then it's use would expand exponentially with other devices. These could ALL be listed as 'available' with AM - even if user supported.

If you are interested Corjan, I am sure the guys can come up with a few examples of hardware that real world example code that they would like to see that would help them understand and also have a reference for .
This, with MP, would be the key to it's use and understanding - and expansion and potentially super community addition to AM for all.

Sometimes @Corjan the guru guys like you are so way above us 'minions' ;) :) that it is hard to 'come down' to our level. Mostly, it is just some clear real world examples that we need and from those we learn and produce others. I certainly have a few suggestions for examples - not total solution - simply examples - to learn from.

Joe.
Joe. CISSP, MSc.

User avatar
Keith Baxter
Posts: 4674
Joined: Wed Dec 20, 2017 11:00 am
Location: Botswana

Re: Tutorials on electronics

#28 Post by Keith Baxter »

Hi,

Thanks to all for their contribution. It is appreciated.

The purpose was to see if there is appetite from some of us. It looks like it has revived some thought.

I have never used MP before so that is going to be an interesting challenge. But if it can be done and save pins and wire, I am cool with it.
I have hope it will be made easier for the majority in time.


Keith
AMD RYZEN 9 5950X CPU, Corsair H80I cooler, ASUS TUF GAMING B550-PLUS AMD Ryzen Mother Board,  32Gb ram Corsair Vengeance 3000Mh, MSI GTX960 4G graphics card 

Post Reply