IConverter replacement with IOM

I'm a little confused. IOM is not a new framework. It pre-dates modules in ti.sdo.io (e.g. IConverter).

Todd

Maybe I had my terminology incorrect. With the GIO / IOM / Driver interface superseding IDriver / IConverter / Transformer, is there a replacement for the IConverter concept. GIO contains most (all) of the functionality of IDriver, is there something simmilar for IConverter? Is it suggested / possible to create virtual devices which can perform this function?

IDriver/IConverter/Transformer superseded GIO/IOM. However GIO/IOM is still supported and based on customer feedback we recommended using it instead the ti.sdo.io modules in IPC.

What exact functionality are you asking about?

Todd

I was looking for the replacement for IConverter. IConverter provided a slick interface for converting one stream into another. For example, I have an I2C driver which can access generic devices on the bus. A converter would be nice for converting a high level task, such as reading temperatures, into a set of I2C driver commands. From a task perspective, I can issue one buffer with enough space for the number of system temperatures, and the converter sends back the buffer, even though it may have modified the command going down to the I2C driver.

Another example would be the layers of Ethernet. The lowest level driver handles the MAC and raw Ethernet interface. On top of that are converters which handle the other needed protocols: ICMP, IP, UDP, IGMP, etc...

You can use the name in the GIO_create to stack also.

Todd

Is there an example showing that?

I see in the BIOS cdoc the reference to the ability to stack, and that the dev module helps manage that, but how is that intervening code inserted in that stack? The dev module docs didn't mention it.

Is it as simple as:

dev.create("/uart" ...);

dev.create("/bcd2ascii"...);

GIO_create("/bcd2ascii/uart"...);

The IDriver and IConverter interfaces were much easier to understand along with their documentation in respect to stacking.

Any help here before I go and start attempting to reverse engineer what stacking support there is?

Yes. What you have listed is correct:

Is it as simple as:

dev.create("/uart" ...);

dev.create("/bcd2ascii"...);

GIO_create("/bcd2ascii/uart"...);

Todd

OK. Now how does the bdc2ascii driver / converter hand off data to the uart driver? Is that also as simple as calling the mCallcackFxn in the bcd2ascii mdSubmitChan function? And then the IOM framework automatically calls the mdSubmitChan function for the uart driver?

Thanks

Yes. The stacking driver needs to call the underlying driver via the interface functions.

So the stacking driver needs to open a channel to the underlying driver? Or does the IOM framework do that for you?

In a standard driver, the data flow is: mdSubmitChan -> ISR -> CallbackFxn

With the stack, how does that flow happen?

mdSubmitChan(stack) -> CallbackFxn -> IOM Code -> mdSubmitChan(driver) -> ISR -> CallbackFxn

Or

Stack driver opens a channel to the underlying driver (How does it know which one to open a channel to?) and then:

mdSubmitChan(stack) -> mdSubmitChan(driver) -> ISR -> CallbackFxn

I feel like we are talking past eachother a bit here. Hopefully this clears up what I am asking.

The stacking driver has to call into the lower level driver's interface functions. So the stacking submit call's the lower level driver's submit.

norton256 said:

mdSubmitChan(stack) -> mdSubmitChan(driver) -> ISR -> CallbackFxn

OK. Now how does the stacking driver know which root driver's function to call? Is a stacked driver hard coded to use a particular lower level driver? Does a stacked driver use the GIO interface to open a channel on a particular lower level driver?

Thanks. I think I have enough detail to move forward with.