Infineon XMC1000, XMC4000

Hello All,

the Infineon ARM Cortex derivatives (XMC4000 CM4, XMC1000 CM0) look very interesting. Advanced peripherals, good value for the money.

Is anybody actually working with them and wants to tell something about what to observe?

TIA,

Oliver

--
Oliver Betz, Munich 
despammed.com is broken, use Reply-To:
Reply to
Oliver Betz
Loading thread data ...

You should observe the request to accept an incredible restrictive licence even when downloading the datasheet. For anything you tell in public, _you_ are required to prove that the fact was public know before or you may be sued.

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de 

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt 
 Click to see the full signature
Reply to
Uwe Bonnes

Yes, Nice parts, but XMC1xxx still showing 'coming soon' on the status lines. They seem to be a long time hitting final release.

Meanwhile, there is also Cypress PSoC4, and Nuvoton, and Freescale MKE02Z all seem to be more available.

-jg

Reply to
j.m.granville
[...]

I agree that it is extremly annoying, but although I'm not a lawyer, I'm pretty sure that this is a paper tiger.

Oliver

--
Oliver Betz, Munich 
despammed.com is broken, use Reply-To:
Reply to
Oliver Betz

Correct. And the errata sheets for current silicon describe problems I don't want to deal with.

PSoC4 analog functions are somewhat disappointing, a PGA would be very useful for me (currently I'm using an external chip for this). No low pin count packages.

Nuvoton also lacks LPC packages, besides this it's oscillator stability isn't good enough. Well, as long as Infineon doesn't get their oscillator temperature compensation working (read: documented), it's not better.

MKE02Z is IMO a compatibility kludge. Who wants to use still the old

9S08P peripherals, not even a fractional baud rate generator? Well, I had less porting effort, because I have a siginificant 9S08 code base. No LPC packages.

Oliver

--
Oliver Betz, Munich 
despammed.com is broken, use Reply-To:
Reply to
Oliver Betz

The legal nonsense that Infineon try to apply before you read a data sheet may or may not have an real force but mainly it tells you about the attitude of the supplier. I don't get this nonsense from NXP or ST or TI or Freescale or SL - why should I bother with Infineon if they start out by chucking legal bricks at me ?

Michael Kellett

Reply to
MK

I agree with you about NXP/ST/Freescale (I don't use SiLabs) but I don't agree with including TI in that list.

If you try to download the example bare metal source kit from TI (called StarterWare) you have to go through export control procedures. That's insane for some example code which other vendors freely provide their versions of on their own website. :-(

You have to wait several days for a download link to be emailed to you and when it doesn't arrive and you contact TI, they want your full contact details (including full home address and telephone number) in order to establish that it's ok to download some sample code. :-(

I've no wish to be subjected to full export control checking and stamping over my privacy just for some example code which can be created anyway (with enough time) using the information publicly available on TI's website. :-(

Simon.

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

Thanks for the info Simon - I haven't got past data sheets with TI in the last year or more.

Michael Kellett

Reply to
MK

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: | |

formatting link
| |The following is a link to TI's privacy policy: |
formatting link

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.

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

You could ask Infineon what 'coming soon' really means, and when fixed silicon is due ?

I have to agree that anyone supplying a 32 bit controller, they then decide to put 16 bit timers into (?!), needs their head read.

-jg

Reply to
j.m.granville

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

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/
Reply to
Oliver Betz

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

Reply to
j.m.granville

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.

Reply to
Richard Damon

responding to

formatting link
, Jochen wrote: Hi all,

That chat is really interesting but I don´t see your problems to be honest.

Asking for experiences of Infineon´s ARM Cortex devices and ending up in a chat about normal/standard disclaimer topics is strange. Of course they put in this disclaimer, but you´ll find those limitation with nearly every vendor of semis and they are forced to do so ? see Richard Damon comment.

Coming to the real think ? the families of M0 & M4 is already available and Infineon is offering samples, development kits and their IDE tool since a long time.

We got a small kit during the trade show and we ordered several via our local Distributor and I have to say, that our results met our expectations so far. Also I like their set up of Dave ? quite useful to get started.

Why don´t you contact them directly and raise your concerns to them ? I guess they would like to get the feedback directly and will solve that

c u

Jochen

Reply to
Jochen

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
Reply to
Simon Clubley

Hardware crypto acceleration?

-a

Reply to
Anders.Montonen

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
Reply to
Simon Clubley

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.).

Reply to
David Brown

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 ()

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

Reply to
Anders.Montonen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.