NXP I/O Handler
jmg
Posts: 15,175
There may be some marketing lessons here, for P2 support.
(Certainly NXP's push on this is far more marketing than engineering.)
"The new LPC11E37H and LPC11U37H microcontrollers allow developers to address late design changes to their system. The two devices include an "I/O Handler" peripheral that offers designers the flexibility to add incremental peripheral functionality at any point during the design cycle."
and libraries are
http://www.lpcware.com/content/project/ioh/ioh-libraries
Sounds good, rather prop-like ? - but then you find of the 14 devices in the LPC11U3xH family only one has the "I/O Handler"
That single device is also quite a bit more expensive than a variant without the "I/O Handler"
NXP are vague on just what the "I/O Handler" is coded in, but they do say 2K of RAM for I/O Code max, and then give some library examples
"I/O Handler" has 21 i/o pins it can directly access, so is Prop COG like in that area of use.
I/O Handler I2S : emulate an I2S master Two channels with 16-bit per channel are supported.
Code size of the software library : 1 kB
I/O Handler UART : emulates one additional full-duplex UART.
7 or 8 data bits, no parity, and 1 or 2 stop bits up to 115200 baud.
RXD signal is available on three I/O Handler pins (IOH_6, IOH_16, IOH_20),
TXD and CTS are available on all 21 I/O Handler pins.
The code size of the software library : 1.2 kB also consumes Counter/timer module CT16B1
I/O Handler DALI : DALI, 1.5kb Code, also consumes Counter/timer module CT16B1
I/O Handler I2C : 1.5kB Code, also consumes Counter/timer module CT16B1 300kb/s @ 48MHz
(hmm... could not quite make 400KHz standard ? )
From a Marketing angle, the supply of 'Linkable' libraries removes the need for novices to know anything about the I/O Handler. In P2 this would be managed something like PASM Modules, with C wrappers.
From an engineering angle, there seems little info on how to PGM the I/O Handler yourself, and those code sizes sound a little large, and it is clear pretty much only ONE library can fit into the 2k code footprint, even without time-share issues.
On a part already starved of peripherals, adding just one, rather ordinary and costly peripheral looks more of a miss than a hit ?
SW Core ?
Something like an 8051 included as an IO handler would make sense, as NXP already know how to make those, but the code size numbers sound bloated for 8051, and 300KHz i2c at 48Mhz is a rather slow 8051....
Perhaps this is a time-sliced M0, or a M0 subset ?
(Certainly NXP's push on this is far more marketing than engineering.)
"The new LPC11E37H and LPC11U37H microcontrollers allow developers to address late design changes to their system. The two devices include an "I/O Handler" peripheral that offers designers the flexibility to add incremental peripheral functionality at any point during the design cycle."
and libraries are
http://www.lpcware.com/content/project/ioh/ioh-libraries
Sounds good, rather prop-like ? - but then you find of the 14 devices in the LPC11U3xH family only one has the "I/O Handler"
That single device is also quite a bit more expensive than a variant without the "I/O Handler"
NXP are vague on just what the "I/O Handler" is coded in, but they do say 2K of RAM for I/O Code max, and then give some library examples
"I/O Handler" has 21 i/o pins it can directly access, so is Prop COG like in that area of use.
I/O Handler I2S : emulate an I2S master Two channels with 16-bit per channel are supported.
Code size of the software library : 1 kB
I/O Handler UART : emulates one additional full-duplex UART.
7 or 8 data bits, no parity, and 1 or 2 stop bits up to 115200 baud.
RXD signal is available on three I/O Handler pins (IOH_6, IOH_16, IOH_20),
TXD and CTS are available on all 21 I/O Handler pins.
The code size of the software library : 1.2 kB also consumes Counter/timer module CT16B1
I/O Handler DALI : DALI, 1.5kb Code, also consumes Counter/timer module CT16B1
I/O Handler I2C : 1.5kB Code, also consumes Counter/timer module CT16B1 300kb/s @ 48MHz
(hmm... could not quite make 400KHz standard ? )
From a Marketing angle, the supply of 'Linkable' libraries removes the need for novices to know anything about the I/O Handler. In P2 this would be managed something like PASM Modules, with C wrappers.
From an engineering angle, there seems little info on how to PGM the I/O Handler yourself, and those code sizes sound a little large, and it is clear pretty much only ONE library can fit into the 2k code footprint, even without time-share issues.
On a part already starved of peripherals, adding just one, rather ordinary and costly peripheral looks more of a miss than a hit ?
SW Core ?
Something like an 8051 included as an IO handler would make sense, as NXP already know how to make those, but the code size numbers sound bloated for 8051, and 300KHz i2c at 48Mhz is a rather slow 8051....
Perhaps this is a time-sliced M0, or a M0 subset ?