By: David Hess (davidwhess.delete@this.gmail.com), March 8, 2013 11:37 am
Room: Moderated Discussions
Michael S (already5chosen.delete@this.yahoo.com) on March 8, 2013 6:25 am wrote:
> In my book, not having to deal with Microchip development tools is a
> huge plus for STMicro and NXP that outweigh just about any minuses.
> TI tools? Well I, personally, don't like them, but they are still far less strange than Microchip's.
You can get used to hanging if you hang long enough. :) I figure any change will mean learning a new development environment from practically scratch. It is just another cost.
> About combination of package/RAM/price: can you give me an example of 8-bitter in a package
> you like, with amount of memory you like, that can't be matched feature-for-feature with LQFP
> from either STMicro STM32 series or by TI Piccolo or Delfino series (well, those are not ARM-Cortex,
> but also small 32-bitters) while the later only x1.5 or so more expensive?
> Oh, and don't forget yet another small 32-bitter - Freescale Coldfire-based V1 and V2 series. It
> is still alive, too, and still has features that others don't have. Like on-chip Ethernet phy.
The ARM LQFP parts would pretty much mean designing and building a small module with support circuitry to duplicate functionality that is missing so it is not a clear win by itself. What I do not want is to upgrade while staying in the same place despite the allure of the Red Queen. If I went to that much trouble, and I am considering it, then the memory issue becomes irrelevant because I should be able to add lots or at least some directly accessed external memory to the module.
I am rather leery of upgrading to a 32 bit part that is not ARM and it is not something I have seriously considered.
> As to your other points, I don't quite understand a point about bit-oriented I/O.
> Do you mean bit-banging? IMHO, GPIO modules on both TI C28 and STM32
> are pretty well designed. What features you found are absent?
The missing feature with the older NXP ARM implementation was correct operation. I did not have to experience it myself but believe I recognized it when it was described. The work around was to add significant delays between I/O operations to get correct results at the pins or within the peripheral. I assume it has something to do with a clock domain crossing on the internal ARM peripheral bus even though the clock domains are coherent. Ultimately that is not a significant problem but it makes it difficult to trust NXP and other similarly designed ARM microcontrollers.
If I had the hardware on my bench, I would enjoy tracking that problem down to the last detail with an oscilloscope.
> About parity: we are in violent disagreement. But you already figured it out from the previous posts.
Eh. There is nothing wrong with disagreement and good things can come from some measure of chaos.
> In my book, not having to deal with Microchip development tools is a
> huge plus for STMicro and NXP that outweigh just about any minuses.
> TI tools? Well I, personally, don't like them, but they are still far less strange than Microchip's.
You can get used to hanging if you hang long enough. :) I figure any change will mean learning a new development environment from practically scratch. It is just another cost.
> About combination of package/RAM/price: can you give me an example of 8-bitter in a package
> you like, with amount of memory you like, that can't be matched feature-for-feature with LQFP
> from either STMicro STM32 series or by TI Piccolo or Delfino series (well, those are not ARM-Cortex,
> but also small 32-bitters) while the later only x1.5 or so more expensive?
> Oh, and don't forget yet another small 32-bitter - Freescale Coldfire-based V1 and V2 series. It
> is still alive, too, and still has features that others don't have. Like on-chip Ethernet phy.
The ARM LQFP parts would pretty much mean designing and building a small module with support circuitry to duplicate functionality that is missing so it is not a clear win by itself. What I do not want is to upgrade while staying in the same place despite the allure of the Red Queen. If I went to that much trouble, and I am considering it, then the memory issue becomes irrelevant because I should be able to add lots or at least some directly accessed external memory to the module.
I am rather leery of upgrading to a 32 bit part that is not ARM and it is not something I have seriously considered.
> As to your other points, I don't quite understand a point about bit-oriented I/O.
> Do you mean bit-banging? IMHO, GPIO modules on both TI C28 and STM32
> are pretty well designed. What features you found are absent?
The missing feature with the older NXP ARM implementation was correct operation. I did not have to experience it myself but believe I recognized it when it was described. The work around was to add significant delays between I/O operations to get correct results at the pins or within the peripheral. I assume it has something to do with a clock domain crossing on the internal ARM peripheral bus even though the clock domains are coherent. Ultimately that is not a significant problem but it makes it difficult to trust NXP and other similarly designed ARM microcontrollers.
If I had the hardware on my bench, I would enjoy tracking that problem down to the last detail with an oscilloscope.
> About parity: we are in violent disagreement. But you already figured it out from the previous posts.
Eh. There is nothing wrong with disagreement and good things can come from some measure of chaos.
