Infineon XMC1000, XMC4000

j.m.granville@gmail.com wrote:

>>And the errata sheets for current silicon describe problems I
>>don't want to deal with.
>
>You could ask Infineon what 'coming soon' really means, and when fixed silicon is due ?

I did so, seems to be difficult to get information.

>> MKE02Z is IMO a compatibility kludge. Who wants to use still the old
>> 9S08P peripherals, not even a fractional baud rate generator? 
>
> I have to agree that anyone supplying a 32 bit controller, they then decide to put 16 bit timers into (?!), needs their head read.

I guess they want to provide a painless path to more computing power
for 9S08P users. There are also Kinetis derivatives with better
peripherals.

Oliver
-- 
Oliver Betz, Munich http://oliverbetz.de/

On Saturday, November 16, 2013 9:44:17 AM UTC+13, Oliver Betz wrote:
> j.m...@gmail.com wrote:

> >You could ask Infineon what 'coming soon' really means, and when fixed silicon is due ?
> 
> I did so, seems to be difficult to get information.
> unich http://oliverbetz.de/

I found this earlier projection,  now ~11 months old
"Volume production is planned for Q4 2013"
so that looks to have slipped to Q1 2014, if they are still 'vague'.

Not the first time a vendor has slipped on a Micro roll out.

-jg

On 11/15/13, 1:14 PM, Simon Clubley wrote:
> On 2013-11-15, MK <mk@nospam.co.uk> wrote:
>> Thanks for the info Simon - I haven't got past data sheets with TI in 
>> the last year or more.
>>
>> Michael Kellett
> 
> You are welcome. This was for the version of StarterWare for the Beaglebone
> Black, BTW.
> 
> Here's a copy of the email I was sent by TI when I asked why I didn't
> receive the download link:
> 
> |Thank you for your inquiry submitted to Texas Instruments Semiconductor
> |Technical Support.  Due to export compliance and to help safeguard national
> |security, Texas Instruments must know to whom they are providing information.
> |This will only be necessary for your initial contact. Please use the link below
> |to complete the contact information:
> |
> |http://www-k.ext.ti.com/sc/technical-support/email-tech-support.asp
> |
> |The following is a link to TI's privacy policy:
> |http://www.ti.com/corp/docs/legal/privacy.htm
> 
> Note how the phone number, full postal address and email address are all
> mandatory. Since I do my embedded work as a hobby this means they want
> all my personal identification details, not some corporate identification
> (hence the home address reference in my last message).
> 
> Absolutely and totally insane when required in the context of some "export
> control", especially since what's been revealed over the last few months
> about the US's misuse of their capabilities and how completely innocent
> people are monitored just because they can be.
> 
> On the plus side, TI's TRM for the MCU on the Beaglebone Black is very
> detailed indeed. I wish all manuals were this detailed.
> 
> I wish the Allwinner MCUs came with this level of detailed documentation.
> 
> Simon.
> 

The issue of "export control" is real. The US government has classified
certain technologies (like higher end computer chips, and boards using
them) as dangerous to be freely exported, and thus the questions. (and
the level of technology needed to reach this point isn't that high). The
key factor in making this determination is would it make it easier to
make some type of munitions, and with the restriction not just available
to anyone (i.e, do the non-US controlled manufactures make this type of
part or not) TI asks for the info because if they don't, they are
subject to significant sanctions.

On 2013-11-15, Richard Damon <Richard@Damon-Family.org> wrote:
>
> The issue of "export control" is real. The US government has classified
> certain technologies (like higher end computer chips, and boards using
> them) as dangerous to be freely exported, and thus the questions. (and
> the level of technology needed to reach this point isn't that high). The
> key factor in making this determination is would it make it easier to
> make some type of munitions, and with the restriction not just available
> to anyone (i.e, do the non-US controlled manufactures make this type of
> part or not) TI asks for the info because if they don't, they are
> subject to significant sanctions.

Oh, I totally agree the issue of export control is real and I fully support
the use of export controls when the items in question justify it.

However, it seems really strange to place a _very_ detailed Technical
Reference Manual on the TI website for unrestricted download and then
apply export control to a piece of example software which just allows
you to get up to speed more quickly on the material already publicly
available in the TRM.

The real blocker on being able to use the MCU in your own projects is
access to the knowledge contained in the TRM, not the convenience factor
of having access to some example code.

Blocking access to the example source code without blocking access to
the TRM doesn't achieve anything in the long term so it just gives the
illusion of having done something without actually achieving a real goal.

If TI wanted to do export control in a meaningful way, they would also
block access to the TRM. However, I suspect that would just damage their
MCU business because people would probably just switch to products from
vendors which didn't have such restrictions.

It's also hard to understand how anything to do with a commodity MCU
based around the widely available Cortex-A8 architecture could ever be
considered eligible for export control.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

> It's also hard to understand how anything to do with a commodity MCU
> based around the widely available Cortex-A8 architecture could ever be
> considered eligible for export control.

Hardware crypto acceleration?

-a

On 2013-11-19, Anders.Montonen@kapsi.spam.stop.fi.invalid <Anders.Montonen@kapsi.spam.stop.fi.invalid> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
>
>> It's also hard to understand how anything to do with a commodity MCU
>> based around the widely available Cortex-A8 architecture could ever be
>> considered eligible for export control.
>
> Hardware crypto acceleration?
>

15 years ago that _may_ have been a viable answer but not today as it
seems to be becoming a standard feature on today's MCUs.

As a aside, there's a very serious question (in light of recent revelations)
about if hardware crypto support can still be trusted. I know I'm going to
steer clear of it from now on if at all possible.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 19/11/13 13:46, Simon Clubley wrote:
> On 2013-11-19, Anders.Montonen@kapsi.spam.stop.fi.invalid <Anders.Montonen@kapsi.spam.stop.fi.invalid> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
>>
>>> It's also hard to understand how anything to do with a commodity MCU
>>> based around the widely available Cortex-A8 architecture could ever be
>>> considered eligible for export control.
>>
>> Hardware crypto acceleration?
>>
> 
> 15 years ago that _may_ have been a viable answer but not today as it
> seems to be becoming a standard feature on today's MCUs.
> 
> As a aside, there's a very serious question (in light of recent revelations)
> about if hardware crypto support can still be trusted. I know I'm going to
> steer clear of it from now on if at all possible.
> 
> Simon.
> 

Hardware cryptographic accelerators are fine to trust - they just carry
out certain mathematical operations faster than the cpu would do.  It is
the algorithms, the implementation of them, and the parameters involved
that need extra paranoia.  Some standard algorithms such as RSA, AES and
3-DES are fine, and any implementation (whether it uses a hardware
accelerator or not) should be simple enough to make any backdoors stand
out in the source code.  (Things like differential power analysis, cache
timing attacks, etc., are always very difficult to control.)

For other algorithms such as elliptical curve cryptography, the maths
appears sound but the parameters used are questionable (especially where
the NSA or NIST has been involved), and the some of the PRNG generators
are highly suspicious.

If you are paranoid enough, then you should be wary of hardware RNG's
and PRNG's - these can have hidden backdoors to make predictable
sequences.  Always try to mix in some real entropy (delays in timers,
keypresses, resistor thermal noise, etc.).

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
> On 2013-11-19, Anders.Montonen@kapsi.spam.stop.fi.invalid <Anders.Montonen@kapsi.spam.stop.fi.invalid> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
>>
>>> It's also hard to understand how anything to do with a commodity MCU
>>> based around the widely available Cortex-A8 architecture could ever be
>>> considered eligible for export control.
>> Hardware crypto acceleration?
> 15 years ago that _may_ have been a viable answer but not today as it
> seems to be becoming a standard feature on today's MCUs.

AFAIK, some algorithms are still under export control in the US, at 
least with sufficient key length. Restrictions do seem to be looser, eg. 
Microchip's application libraries contains only stub implementations of 
the crypto functions, and you used to have to order them separately. Now 
it seems you can just download them, but the download page still carries 
a notice about export control (<http://tinyurl.com/nfp9wfd>)

> As a aside, there's a very serious question (in light of recent 
> revelations) about if hardware crypto support can still be trusted. I 
> know I'm going to steer clear of it from now on if at all possible.

Even without the snooping hoopla, a well-known software implementation 
is probably safer than unknown hardware. Now it's just impossible to 
discriminate honest hardware bugs from malicious interference.

-a