Cortex M3/M4 with bootloader ROM

OK, that's another one on my list to investigate. Thanks!

Reply to
David Brown
Loading thread data ...

I haven't seen anything off-the-shelf for EZ Port. But it's not hard to make one - I'll probably first start with an FTDI module (these things are /really/ convenient). It would also not be hard to make a dedicated programming board that supports parallel programming of lots of devices.

USB is great for in-field programming, as you can plug it into pretty much any PC. But it is not good for production programming - you usually need more complex software, and it is often Windows-specific which means painfully slow attachment and enumeration, and typically means you can only handle one board at a time on one PC. (With Linux its a lot easier, but only if your programming software works on it.)

Reply to
David Brown

Got it. UM10360, chapter 32 has the LPC17xx bootloader documentation! The programming code is about 500 lines of python in our case.

-- mikko

Reply to
Mikko Syrjalahti

At least with the LPC11U37 (Cortex-M0) which I'm using, it is very easy: If there is no valid user code already flashed, the bootloader provides a mass storage interface for Windows, and you can just copy the firmware file to it for flashing it. No need for special software, like SAM-BA for Atmel devices, which in my experience didn't work reliable all the time, especially on Windows 7 64 bit systems. Enumerating and flashing is very fast (I can see the USB drive a second after connecting to the PC and flashing needs another 2-3 seconds), so no problem to do it for one device at a time, only.

If there was already a firmware flashed, you have to ground a pin during reset to start the mass storage part again. I guess the Cortex-M3 LPC17xx parts have the same feature.

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

That sounds like a nice way to handle flashing, so I'll look into this one. For in-field updates it would work very well - and it's not hard to connect a pin to ground for programming mode. It would be useless for production programming with Windows because it could not be sensibly automated or scaled, but unless the designers have done something /really/ weird it will work fine with Linux where these things can be automated well.

Reply to
David Brown

(LPC11U37 USB mass storage device)

Where do you expect problems

Oliver

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

When you plug a USB memory stick into windows, you get a few seconds pause, then Windows picks a drive letter for the new drive, and opens an explorer window for the device. If you are working manually, that's fine - you can just drag-and-drop the update file into this window. Then you select "safe eject" from the right-mouse menu for the drive.

But for automated parallel programming of multiple cards at a time, this cannot work - there is no person looking at windows, and doing drag-and-drop. For automated programming, you need to know which card corresponds to which "drive", you need to be able to see when they are attached, start and track the copy, and then unmount the drive - all without any windows popping up or user intervention. It is conceivable that this /can/ be done with Windows - but it would be a long, difficult and inelegant process.

Contrast this with Linux. Here I would set up a USB hub (or hubs, as necessary), and make some udev rules that triggered for new "drives" and gave the drive a dedicated name dependent on the USB hub slot. The udev rule would trigger a small script to mount the drive, copy over the program, record the details in a database, and unmount the drive. That's perhaps a couple of dozen lines of Python script, on a headless machine (a couple of LEDs on the board is all the interface needed) - scalable to as many parallel connections as we want.

Reply to
David Brown

not on any PC I work with or I help maintaining.

I don't know how fast the available "USB boot enabled" controllers are, but if programming is (nearly) as fast as I plug devices, why should I program more than one device at a time?

formatting link
should do this.

After all, I would prefer other USB classes, e.g. HID. But I can't tell you whether that's available in ROM on any device.

Oliver

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

Um, unless I'm missing something, that should be a pretty easy script even in Windows, or a C# program...

Hope that helps, Best Regards, Dave

Reply to
Dave Nadler

I guess it's been a long time since I plugged a USB stick into a windows machine - I use Linux for most of my work and play. No window opens automatically, but the drive letter does get picked from the next letter Windows thinks might be available. The utility you mentioned below could make this a bit more controlled and consistent.

Automated production programming often needs to handle things in parallel, even if the programming time is short. Keeping production costs down is all about getting more work done in fewer man-hours. So if you can attach a panel of 8 cards to your programming system at once, rather than individually, you reduce your costs.

Reply to
David Brown

You are the second person to say that, so maybe you are right! I can certainly say that these things are a lot easier for /me/ to do in Linux, but perhaps that is just my lack of experience at such programming in Windows (it has been mainly application programming, guis, etc.).

Lets take an example that I /have/ tried on Windows. I had a card that had an FTDI USB serial chip on it. For programming, you connected that into a PC to download the code over the serial port. To avoid user interaction, the PC program polled the registry entry HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM key regularly - any change in that indicated a new serial port, and started programming.

This worked okay, and could probably have worked with more than one device at a time with a little effort, though I don't know in general how I would identify which port each card was on (imagine a set of test bench slots, with a USB cable from each going into a hub on the PC - you need to know which card slot corresponds to the serial port, so that you know which ones are finished and can be removed).

It is possible to build your own version of FTDI's drivers (changing the "inf" file) to make comms port numbers depend on the physical address rather than being assigned automatically. That would also solve the problem of continuously increasing comms port numbers. The application note contains the warning "Note that setting LocIds will radically alter the behaviour of the driver; please contact FTDI if you think you have to change LocIds." In particular, this will cause trouble for "normal" FTDI devices on the same machine.

This particular programming run was quite small, so we never got that far.

On Linux, I can set up a simple "udev" rule to identify FTDI devices on particular hub ports. The rule would give the device a clear, identifiable name based on the port, then start the script that handles the programming. There is no need to think about polling. There are no concerns about the effect on anything else - the same machine could be configured to have different types of software triggered on different hub ports. There is no need to think about supporting multiple cards in parallel - that is handled automatically by the udev system.

Perhaps there are easier ways to handle this in Windows - and I freely admit that much of the effort of getting the Windows version in place was because I had to find out about the registry keys involved. Someone more familiar with such programming could have done it faster. But I have no doubt that for me, such programming systems can be made faster, easier and more flexible with Linux.

Reply to
David Brown

Just curious - Which Linux distribution do you use?

I used Ubuntu for several years, but I'm not sure I want to follow Canonical in whatever path they want to take it.

Thinking of switching to Scientific Linux (Fedora) when I get back to "work and play." (Crunchbang Linux is also in the run.)

--
Roberto Waltman 

[ Please reply to the group, 
  return address is invalid ]
Reply to
Roberto Waltman

Cross posting to sci.electronics.design

What linux distros do techies like?

R.

Roberto Waltman wrote:

Reply to
Roberto Waltman

Being a vanilla sort of guy, I mostly use CentOS 6. I'm more of a KDE fan, though, so there are occasional curiosities that I haven't invested the time in fixing--for instance, clicking on a link in kmail doesn't open it correctly in Firefox.

I have an old P4 box that's running Kubuntu. The main thing I disliked about Ubuntu when I used it last is that it doesn't play nicely with the other children--if I set up disk partitions on cylinder boundaries for other OSes, and tell it to use the existing partitions, it nevertheless insists on futzing with the partition table to save a quarter of a cylinder. I like computers that do as they're bloody well told.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 USA 
+1 845 480 2058 

hobbs at electrooptical dot net 
http://electrooptical.net
Reply to
Phil Hobbs

Debian on my main machine (since 1999 or so).

kubuntu on my laptop, but I don't really like the way Ubuntu is going either...

--

John Devereux
Reply to
John Devereux

Genoo.

-- Grant Edwards grant.b.edwards Yow! ... If I had heart at failure right now, gmail.com I couldn't be a more fortunate man!!

Reply to
Grant Edwards

It's like the weather. Wait and it will be all different anyway. Just pick the one with the least overlap between what you need and what's busted.

If you're experienced with Ubuntu and like the way it works, why change anything at all? Don't fix it if it ain't broke.

Reply to
mike

On a sunny day (Tue, 08 Oct 2013 09:32:46 -0400) it happened Roberto Waltman wrote in :

Not sure there is such thing as a 'techie'. I started with Linux in 1998 with SLS Linux, (Soft Landing Systems). that no longer exists. Then Slackware, was enlighting, as it had a documentation on a techie level I could read and understand.

Then tried RatHead, that sucks, they are in if for the money and use incompatibility (at that time libc) as 'customer binding'. Then Suse, that was nice until 7.6 ?? or something until it got bought out and taken over and went RatHead's way. Then I used grml

formatting link
as it was simple and worked, but last time I looked it changed into some live CD that you cannot install. Then I went Debian (and grml is Debian based so not any big surprises and changes), and still use that. The Ubuntu you mention is also Debian based, I have it on a PC and a laptop. On the same PC and laptop I run now by default (multi boot) Slackware. I do not recommend Slackware as it has its own quirks, not all soft has been ported, and updates are sometimes very hard to do even if you have a lot of experience, and the 32 / 64 bit problems come into play too. but I use it every day, call me die-hard. Then there are my Raspberry Pis that run Debian on ARM processor, and are a pleasure to 'upgrade', everything works, but that is also due to the good work of the Raspberry foundation?

So, anyways, Debian is the only distro I have ever financially supported, and maybe the cleanest most stable and best maintained. Canonical is in it for the dollars so do not know where that goes, but to start on new hardware it is cool, as everything works, they have decent support.

A 'techie' will likely run wine emulator and LTspice... some more programs that need windows emulator.

So maybe stick with some form of Debian for now? Buy a good book on Unix, get to learn the commands, the file structure, the X server, do not get fooled by all that mousing that is done in window managers to copy-cat sort of a MS desktop. Imitating idiots does not bring you anything useful. The command line, scripting, xterm is the user interface. Do not be afraid to be root, just think before you hit enter.... I once dropped a full harddisk, oh well. gone... So make backups, then if you screw up simply restore everything, get your work back from your backups and be happy.

Reply to
Jan Panteltje

Always a risk - you are going to get some very non-technical replies from there!

I use Ubuntu a little a number of years ago, but I also didn't like some of Canonical's moves (or Unity), so I quickly dropped it.

Mostly I use Mint on desktops and laptops, which gives you most of the advantages of Debian and Ubuntu (i.e., compatibility with these systems) without the disadvantages of Ubuntu (no secret deals sending your data to Amazon, no "we know best and you don't need to know" attitude to development), along with easy support for useful stuff that Debian doesn't like (such "evils" as binary graphics drivers or media codecs).

I have Fedora on my wok PC, but it is getting out of date - and I think I will move it over to Mint rather than update the Fedora.

For servers or other small or headless systems, I use Debian stable. This is perhaps a matter of habit - I have used it on servers for over ten years. But I've seen no reason to change that habit.

For a workstation, there are a few things to consider. One of them is compatibility with software and guides. Typically, binary-only software is either in "rpm" format for Redhat-style systems, "deb" format for Ubuntu-style systems (being more popular than the parent Debian distro), or system-independent binaries. The same applies to recipes and guides. Usually it is possible to get everything working on alternative systems, but you may need to do some "translation" of things like additional packages to be installed. So if you know up-front that you want to run software with particular requirements, that will make your choice easier. If you want to run FPGA design tools, then Redhat systems (such as RHEL, Scientific Linux, CentOS, and perhaps Fedora) will be easiest. If you want to build embedded Linux systems, then most recipes are given for Ubuntu and related distros.

For some software there is /no/ good distribution. If you want to build Android for embedded systems, then you can't do it using a modern distribution - the requirements are so weird and specific, such as requiring an old version of make and particular versions of Java that are no longer distributed by Oracle (but available on the net, of course). I find VirtualBox comes in very handy for such cases.

If you've got the time, you can try out different systems - there is no monetary cost (except for things like RHEL where you pay for the support and services - if you need these, then RHEL will be good value for money).

Reply to
David Brown

Mostly CentOS 6 but I have Linux Mint on my laptop. Mint is Ubuntu with the traditional desktop.

--
Chisolm 
Republic of Texas
Reply to
Joe Chisolm

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.