Industrial Automation Hat open-drain output/LED write

[bakerhillpins]

I'd first like to make a suggestion to the moderators:
Might you make a new sub forum for each individual product/board such as the IAH I'm asking about? This would make viewing product information more intuitive and simple to find. It would also alleviate the need to use the search engine to filter to a single product. Which will be problematic because it requires the OP's to use consistent terms or acronyms. You could have a general section and/or individual wiring sections to discuss common application notes and such as well.

Ok, on to my question.
I see that to set/clear the Open-drain and LED outputs I need to use 2 different commands described by this enum:

I2C_MEM_RELAY_SET,
I2C_MEM_RELAY_CLR,

With each of these commands I send a 2 byte buffer, the first byte is the command # and the 2nd is the channel:

intBuff[0] = 0xff & command;
intBuff[1] = ch;

if (write(dev, intBuff, size + 1) != size + 1)

Between the 2 different digital output types there are 8 total outputs (4 of each). It appears from testing that these commands for Set/Clear only take a single channel at a time.

Is this correct?

If so:

• It seems unfortunate to have to perform 8 individual writes to set/clear the complete set of outputs. That equates to 2x as much data transmitted as would be necessary if it could be done as a list of channels after the command.
• We can read the state of the digital outputs in a single byte. Why not support Write the same way Read is performed? It seems that these particular commands might be a legacy implementation detail.

So I also ask:
Any chance that the commands could be updated to support multiple channels? Or better yet a new write command is created that supports digital output writes in a single byte?

Thanks
Bryan

 

[alexburcea]

Hi Brian,
Thank you for the forum suggestion, we will consider it.
The open drain and led can be set in 2 ways:
1) Turn on or off each channel individually as you describe
2) As a bitmap, writhing the same address we use for reading.
Let me know which driver need this "write all" feature and I will add it (python or megaind comman)

Alex.

 

[bakerhillpins]

Alex,

The c based megaind command line program is the code I'm referencing while writing my application. I'll give the bit-mapped address a try, thanks!

Currently I'm seeing odd results when I loop though all 8 outputs (setting/clearing) in succession. The results seem random. If I hit a break-point in between each write operation it works just fine.

Bryan

 

[bakerhillpins]

To follow up here:
Have a simple program that writes to each ODO/LED in succession (in a loop) using the Set/Clr commands. I call the routine 2x, once turning all outputs on, and once turning all outputs off. I'm running on a RPi 4 64-bit using C# .NET 7 in case it matters.

Running this results in random results both when the outputs are turned on and off. Insert a 1ms delay in between each write and it works fine. Remove that delay and the results are random again.

Is the firmware that's running on the IAH queuing up the commands and possibly executing them out of order or maybe the queue isn't protected from interrupts from the i2c bus? The C# System.Device.Gpio code is bare bones simple and appears to be appropriately pinning memory.

 

[alexburcea]

The microcontroller serve I2C requests on interrupt and update a RAM region. The IO responsible task is scanning that region each millisecond and execute the commands. I did not see why you will need to update led's and OD faster than 1ms. If you wish to set all in one command write on the address 0x00 lower nibble represents OD and higher the LED's. If you need to generate PWM on the OD outputs, this feature is available also (internally in the microcontroller).

 

[bakerhillpins]

The microcontroller serve I2C requests on interrupt and update a RAM region. The IO responsible task is scanning that region each millisecond and execute the commands.

Are you implying that the IAH can only handle i2c bus activity that is separated by 1ms or more of dead time? (I.e. less than 1kHz) It sounds like there is no command queue and thus the last command wins.

If there must be a delay, then how do we take advantage of the sample rate supported by the IAT as the specs of the 2 analog inputs are 1kHz each:

0-10V INPUTS:
· Sample rate: 1KHz.

4-20mA INPUTS:
· Sample rate: 1KHz.

I did not see why you will need to update led's and OD faster than 1ms. If you wish to set all in one command write on the address 0x00 lower nibble represents OD and higher the LED's. If you need to generate PWM on the OD outputs, this feature is available also (internally in the microcontroller).

At this point in time I'm simply writing code to test various functions and prove that I can manipulate the device as my application needs. Writing in quick succession isn't necessarily needed, it was just a simple test mock up after writing the basic manipulation methods.

However, a valid design pattern may be to update the HAT in a periodic manner from the Pi (say a background thread). Thus, this pattern would create bursts of write activity to the i2c bus for the IAH. These bursts may be for all the same class of I/O,. as we have discussed, or many different features (different commands). So this doesn't seem to be an out of the ordinary design pattern. I'd like to hear your thoughts about this?

Also - as there is no API documentation that I can locate (please provide a link if so), I was not aware that I could write to the digital outputs in a bit-mapped fashion, nor was I aware that there should be at least 1ms between commands to the IAT. I only have the knowledge that your command line application code provides me, nothing more.

 

[alexburcea]

Yes, for the led's and OD, there is no command que and you can not send commands faster than 1ms.
The I2C is not limited, just the update of the OD and LED's command execution is, so you can read and write without any delay.
Yes, the burst writes are ok as long does not set one led at a time but all of them as a bitmap. I was writes the OpenPLC driver for the card in that manner without any delays and everting works.

There is no API documentation except for the online help of the megaind command and the function prototypes for python library but what you need is more deep than that because you write a driver for the card. There are too few hours in a day for us to write that documentation and you are the only person that need it so I will answer any question you have. Hope you understand this.

 

[bakerhillpins]

Ok, I think I've got what I need for now. If I have anymore questions I'll let you know. Thanks.