Integrated TFT controller in PIC MCUs

On 09/01/15 00:22, Dimiter_Popoff wrote:
> On 09.1.2015 г. 00:53, Wouter van Ooijen wrote:
>> Dimiter_Popoff schreef op 08-Jan-15 om 11:18 PM:
>>> On 08.1.2015 г. 23:25, David Brown wrote:
>>>> ...  (Just as "cpus should
>>>> have more than 16 core registers" is a good reason for disliking ARM's,
>>>> if that is your opinion.)
>>>
>>> Results of arithmetic calculations are not exactly what I would call an
>>> opinion.
>>> 16 registers - one of which being reserved for the PC - are too few for
>>> a load/store machine.
>>
>> 16 is a fact, but the rest is nothing but opinion.
>>
>>  > Clearly it will work but under equal conditions
>>> will be slower than if it had 32 registers, sometimes much slower.
>>
>> More registers can be slower too.
> 
> Yes, 32 is about the optimum I suppose. But I have not really analyzed
> that, what I have - and demonstrated by an example which you chose to
> ignore - is the comparison 32 vs. 16.

Certainly it is possible to pick examples where 32 registers is more
effective than 16 - but equally we can pick examples where 16 registers
is more efficient (such as context switching, or code with a lot of
small functions).  Examples are illustrative, but not proof of a general
rule.

(Regarding more than 32 general-purpose registers, I think the Itanium
is the only cpu I know of with 128 integer registers and 128 floating
point registers.  It needs more registers for its EPIC architecture, but
I don't think anyone would consider it an "optimum" design!)

> 
>> More registers => more bits in an instruction to specify a register =>
>> more to read from code mempry => slower
> 
> Not really. Load/store machines typically  have a fixed 32 bit
> instruction word; using that for only 16 registers is simply
> waste of space, you will have less information packed in the
> opcode thus you will need more opcodes to do the same job, thus
> having to do *more* memory fetches.

Many load/store machines have some sort of compressed or limited
instruction format for greater efficiency (especially of instruction
cache).  ARM has a couple of "thumb" modes, MIPs have an equivalent, and
on the PPC I have seen various schemes.

Even in the full 32-bit ARM set, the bits "saved" by having fewer
registers are used for the conditional execution bits and the barrel
shifter.

Every bit of space in the instruction set is important.  Using them to
support extra registers may be the best overall tradeoff in some cases,
but it is always a tradeoff.

> If you become familiar with the power architecture instruction set
> you will find very little room for performance improvement, the
> person who did it knew what he was doing really well.
> 

It's a nice architecture (apart from the backwards bit numbering!).  But
it is a very complex architecture - for smaller devices (say 200 MHz,
single core - microcontroller class cpus) a PPC core will be much
bigger, more difficult to design and work with, and take more power than
an ARM (or MIPS) core.  On bigger devices, caches, interconnects, buses
and the like dominate device size.


>> More registers => more data to save/restore on an interrupt or context
>> switch => higher interrupt latency and context switching overhead.
> 
> Not at all. You can always save/restore even just 1 register if you
> want to on a 32 register machine, what you *cannot* do on ARM is
> have more than 13 registers to use in an IRQ handler when you need
> them - so you will need *more* memory accesses in this case.

That makes no sense to me.

Many cpu implementations have some sort of bank switching or dedicated
registers reserved for interrupt usage - it is seldom a full set of
registers, but can be enough for very short interrupt routines.  Beyond
that, you must save other registers before using them - that applies
regardless of the number of registers you have.  And if your interrupt
function calls external code unknown to the compiler (or programmer),
you must save /all/ the registers.  Twice as many registers means twice
the time, space and bandwidth.


Don't forget that the way /you/ program using VPA sort-of-assembly is
very different from the way the great majority of embedded developers
write code.  A lot of what you see as "fact" here is the result of your
subjective experiences - there is no doubt that 32 registers suits your
way of programming far better than 16 registers would.  You have manual
control of all your registers, and track what needs to be saved in
different places, avoiding the need to save as many registers as a
compiler would.

> 
> And since the latency which matters is the IRQ latency (tasks get
> switched once in milliseconds, IRQ latencies may well have to be
> in the few uS range) - the time on save/restore all registers
> is negligible (e.g. 32 2.5nS cycles once per mS on a 400 MHz power
> core, or 0.008% of the time).
> 

The time needed to save and restore all registers may not be relevant in
a given application, but it is not irrelevant or negligible in all cases.

On Fri, 9 Jan 2015, David Brown wrote:

> For microcontrollers, such as the Cortex M devices, I think 16 registers
> is a good balance for a lot of typical code.

In Thumb2 you work directly with 8 GP registers, indirectly with few like 
PC and SP, and accessing the rest of the GPRs is different and/or has 
penalties.

Just trying to say that it is a moot point. And personally, I never 
understood the existence of Cortex-M - why cripple the ability to switch 
to native 32-bit mode, if most or all of the underlying logic is there?

On 09/01/15 02:21, Simon Clubley wrote:
> On 2015-01-08, David Brown <david.brown@hesbynett.no> wrote:
>>
>> One reason, which has already been mentioned, is simply popularity - 
>> since Cortex M3/M4 devices dominate the market that the PIC32 competes 
>> in, you get more tools, more testing, more familiarity, more developers 
>> and more existing code.
>>
> 
> OTOH, the PIC32MX also comes in PDIP variants so you can breadboard them.
> 
> The only ARM MCUs I know of in PDIP are the LPC810 (cute little MCU BTW)
> and the LPC1114FN28 (which is not available from Farnell UK and anyway
> only comes in 600 mil wide packaging). Neither of these have USB support.
> 

Of course different people have different needs.  All I have been saying
is that a person might have good reasons for not wanting to use a PIC32
- I am certainly not saying there are no good reasons why some people
might prefer them over alternatives.

>>
>> The chips themselves suffered from a number of major hardware issues 
>> when they came out - and from what I have heard from a user, they still 
>> do even after several years.  A key point is that the USB interface is 
>> limited to 12 Mbps (or at least, has severe bugs at 480 Mbps).  While 12 
>> Mbps is fine for many uses, this long-lasted problem shows a severe 
>> failure in development, testing and quality control that is very 
>> off-putting.
>>
> 
> You might be confusing the MX with the MZ here. The MX is designed for
> 12 Mbps only and the MZ is apparently 480 Mbps capable but is the one
> with the severe bugs. Someone posted a link to the MZ errata list a while
> back - it was one hell of a read when you looked at what simply didn't
> work. I don't know what the current situation is with the MZ however.

I don't think I am /confusing/ the families - I have merely been
ignoring the details!  Certainly complaints about the bugs in 480 Mbps
USB only apply to the devices with that hardware - complaints about the
development culture at Microchip are extrapolated from that.

(Based on a single post from a single user on another newsgroup, I
gather that there are still problems with 480 Mbps USB.  It would be
fair to interpret such third-hand anecdotes as "I don't know", however.)

> 
>>
>> I think the whole PIC32 system has been a terrible blow to the 
>> microcontroller world - it was done poorly, rushed to the market, had 
>> poor free versions of its tools (leading people to see it as a very slow 
>> cpu), and I believe it has greatly reduced the chance of MIPS being a 
>> serious player in the microcontroller market.  MIPS make a series of 
>> cores that are competitive or better than many of ARM's cores in terms 
>> of speed, features and mips per mW - and the microcontroller world would 
>> be a better place with more choice and competition.
>>
> 
> Do current versions of the MIPS ISA allow you to push a set of registers
> onto the stack in one instruction as you can with ARM or do you still have
> to push (and pop) them one after the other manually in your handlers ?

It's been a while since I looked at the details of MIPS - and I haven't
used their newer architectures at all.  So I can't help you on this one.

> 
> What's the code density for MIPS versus ARM like for the latest MIPS
> cores ?

My understanding - based on a few articles and some MIPS white papers -
is that it is at least competitive, and often better.  Google will give
you more information - but all I can say is that if the likes of NXP, TI
or Freescale put MIPS cores in some of their microcontrollers, they
should be in the same class as their ARM devices for price, performance,
features and power.  And then the competition would drive improvements
for both core suppliers.

> 
> The MIPS ISA in the PIC32MX seems a little too basic to me after been
> used to what the ARM ISA offers.
> 

I don't think the PIC32 uses the most appropriate MIPS core - but I
don't have the the details in my head.  Maybe I'll read up about MIPS
some more in the weekend.

On 09/01/15 09:22, pozz wrote:
> Il 08/01/2015 22:25, David Brown ha scritto:
>> On 08/01/15 16:07, pozz wrote:
>>> Il 08/01/2015 13:53, David Brown ha scritto:
>>>
>>>> Certainly MIPS is a nice architecture, especially their newer
>>>> microcontroller versions.  But there are many good reasons for not
>>>> picking Microchip PIC32 devices, even if you like the cpu core.
>>>
>>> I'm interested in those "good reasons for not picking Microchip PIC32
>>> devices"...
>>>
>>
>> Note - I haven't used PIC32 devices myself either, so don't take this as
>> more than opinion from someone who has read about them, talked about
>> them, considered them, but never tried them.  My comments may therefore
>> be inaccurate or outdated.  And if other posters with real experience
>> contradict me, they are probably right.
>> [...]
> 
> Nothing about TFT controller?
> 

Nope - I haven't needed a TFT controller, and can't say off-hand what
devices would do the job for you.  I can point you towards the Freescale
Kinetis K70 family as good Cortex M4 devices with support for LCD
displays, but that's the best I can do.

Vladimir Ivanov schreef op 09-Jan-15 om 10:54 AM:
>
> On Fri, 9 Jan 2015, David Brown wrote:
>
>> For microcontrollers, such as the Cortex M devices, I think 16 registers
>> is a good balance for a lot of typical code.
>
> In Thumb2 you work directly with 8 GP registers, indirectly with few
> like PC and SP, and accessing the rest of the GPRs is different and/or
> has penalties.
>
> Just trying to say that it is a moot point. And personally, I never
> understood the existence of Cortex-M - why cripple the ability to switch
> to native 32-bit mode, if most or all of the underlying logic is there?

To make small, cheap, low-power chips.

(to force all those obsolete 8-bit and 16-bit designs out of the market).

Wouter

On 09/01/15 10:54, Vladimir Ivanov wrote:
> 
> On Fri, 9 Jan 2015, David Brown wrote:
> 
>> For microcontrollers, such as the Cortex M devices, I think 16 registers
>> is a good balance for a lot of typical code.
> 
> In Thumb2 you work directly with 8 GP registers, indirectly with few
> like PC and SP, and accessing the rest of the GPRs is different and/or
> has penalties.

As far as I understand it, accessing the other registers means 32-bit
instructions rather than the short 16-bit instructions.  So accessing
them has penalties compared to accessing the faster registers, but not
compared to normal ARM 32-bit instructions.

> 
> Just trying to say that it is a moot point. And personally, I never
> understood the existence of Cortex-M - why cripple the ability to switch
> to native 32-bit mode, if most or all of the underlying logic is there?

My knowledge of the details is weak, but AFAIK the only thing you really
lose with Thumb2 compared to ARM instruction sets is the conditional
execution flags - with ARM, you can use the flags with most
instructions, while with Thumb2 you have the if-then-else construction.
 (You also lose the barrel shifter on some instructions, but that is not
going to affect much code.)

With the original Thumb, ARM kept the normal 32-bit ARM ISA as well
because for some types of code it could be significantly faster.  But
with Thumb2, there is almost no code for which the full 32-bit ARM
instructions would beat the Thumb2, taking into account the memory
bandwidth benefits of Thumb2.

David Brown <david.brown@hesbynett.no> writes:

> On 09/01/15 09:22, pozz wrote:
>> Il 08/01/2015 22:25, David Brown ha scritto:
>>> On 08/01/15 16:07, pozz wrote:
>>>> Il 08/01/2015 13:53, David Brown ha scritto:
>>>>
>>>>> Certainly MIPS is a nice architecture, especially their newer
>>>>> microcontroller versions.  But there are many good reasons for not
>>>>> picking Microchip PIC32 devices, even if you like the cpu core.
>>>>
>>>> I'm interested in those "good reasons for not picking Microchip PIC32
>>>> devices"...
>>>>
>>>
>>> Note - I haven't used PIC32 devices myself either, so don't take this as
>>> more than opinion from someone who has read about them, talked about
>>> them, considered them, but never tried them.  My comments may therefore
>>> be inaccurate or outdated.  And if other posters with real experience
>>> contradict me, they are probably right.
>>> [...]
>> 
>> Nothing about TFT controller?
>> 

STM32F429/439 has a TFT controller too, as do many of the NXP parts.

> Nope - I haven't needed a TFT controller, and can't say off-hand what
> devices would do the job for you.  I can point you towards the Freescale
> Kinetis K70 family as good Cortex M4 devices with support for LCD
> displays, but that's the best I can do.

AFAICT that one is also the only available part that can cache the
SDRAM.  Useful for more bloated systems (QT, uC linux say). All the
others seem to be ~5x slower executing from SDRAM than their internal
flash.

The upcoming cortex M7 should be good in this respect.



-- 

John Devereux

David Brown <david.brown@hesbynett.no> wrote:

> The chips themselves suffered from a number of major hardware issues 
> when they came out - and from what I have heard from a user, they still 
> do even after several years.  A key point is that the USB interface is 
> limited to 12 Mbps (or at least, has severe bugs at 480 Mbps).  While 12 
> Mbps is fine for many uses, this long-lasted problem shows a severe 
> failure in development, testing and quality control that is very 
> off-putting.

The high-speed USB interface of the PIC32MZ family is (AFAIK) fully 
functional, and doesn't have particularly significant errata. What 
happened was that when the chip was first released, Microchip 
completely botched the validation, and in the first couple of revisions 
of the errata sheet the peripheral was marked as not functional. The 
chip has significant other problems (esp. the ADC has been completely 
neutered) and I wouldn't particularly recommend it for anyone. The only 
thing it has going for it is that you can get 2MB flash and 512K RAM in 
a 64-pin package. Word is that Microchip are working on a redesign 
(PIC32MZA) due to be released some time this year.

For reference, here's the current PIC32MZ errata sheet:
<http://ww1.microchip.com/downloads/en/DeviceDoc/80000588G.pdf>

My personal opinion of the PIC32 chips is that they feel clumsy, 
outdated and bogged down by historical MIPS baggage. The MIPS4K core 
used in the PIC32MX series looks like a response to the ARM7TDMI, and 
the MIPS14K core used in the PIC32MZ has some features bolted on as a 
reaction to the Cortex-M3. ImgTec only recently released a 
microcontroller core with an optional floating-point unit, no doubt a 
reaction to the Cortex-M4F.

-a

On Fri, 9 Jan 2015, Wouter van Ooijen wrote:

> Vladimir Ivanov schreef op 09-Jan-15 om 10:54 AM:
>> 
>> On Fri, 9 Jan 2015, David Brown wrote:
>> 
>>> For microcontrollers, such as the Cortex M devices, I think 16 registers
>>> is a good balance for a lot of typical code.
>> 
>> In Thumb2 you work directly with 8 GP registers, indirectly with few
>> like PC and SP, and accessing the rest of the GPRs is different and/or
>> has penalties.
>> 
>> Just trying to say that it is a moot point. And personally, I never
>> understood the existence of Cortex-M - why cripple the ability to switch
>> to native 32-bit mode, if most or all of the underlying logic is there?
>
> To make small, cheap, low-power chips.
>
> (to force all those obsolete 8-bit and 16-bit designs out of the market).

That's missing the point completely.

On Fri, 9 Jan 2015, David Brown wrote:

> On 09/01/15 10:54, Vladimir Ivanov wrote:
>>
>> On Fri, 9 Jan 2015, David Brown wrote:
>>
>>> For microcontrollers, such as the Cortex M devices, I think 16 registers
>>> is a good balance for a lot of typical code.
>>
>> In Thumb2 you work directly with 8 GP registers, indirectly with few
>> like PC and SP, and accessing the rest of the GPRs is different and/or
>> has penalties.
>
> As far as I understand it, accessing the other registers means 32-bit
> instructions rather than the short 16-bit instructions.  So accessing
> them has penalties compared to accessing the faster registers, but not
> compared to normal ARM 32-bit instructions.

Yes, longer code sequences, and most likely very limited instruction 
forms. The latter leads to shuffling of data between the regular 8 GPRs 
and the other, "unregular" GPRs.

>> Just trying to say that it is a moot point. And personally, I never
>> understood the existence of Cortex-M - why cripple the ability to switch
>> to native 32-bit mode, if most or all of the underlying logic is there?
>
> My knowledge of the details is weak, but AFAIK the only thing you really
> lose with Thumb2 compared to ARM instruction sets is the conditional
> execution flags - with ARM, you can use the flags with most
> instructions, while with Thumb2 you have the if-then-else construction.
> (You also lose the barrel shifter on some instructions, but that is not
> going to affect much code.)

I am not Thumb2 expert, either. As a very strong personal (biased) 
opinion, I don't find it elegant at all. MIPS16e impressed me bit more 
with their EXTEND instruction.

What I am trying to communicate, is that the CPU core with all the blocks 
is there. Thumb2 is more or less a decoder, just like the ARM mode is. 
Same with MIPS32 and MIPS16e. Why would one cripple something by removing 
one of the decoders? The power savings are negligible.

ARM7TDMI was more balanced in that regard.

> With the original Thumb, ARM kept the normal 32-bit ARM ISA as well
> because for some types of code it could be significantly faster.  But
> with Thumb2, there is almost no code for which the full 32-bit ARM
> instructions would beat the Thumb2, taking into account the memory
> bandwidth benefits of Thumb2.

Any pointers to data showing this? Never heard of it so far, and does not 
reflect my experience.

Why'd they include ARM mode at all in the Cortex-A series? :-)