Xmega handheld programmer

Go To Last Post
73 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

anyone knows if exist an handheld programmer that support xmega.
I'm using the atxmega32a4u and I need something that can be used in the field without pc. Something like this: http://www.kanda.com/Handheld-AVR-Programmers.121.html

Thanks 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This following seems to do what you want:

 

http://www.equinox-tech.com/prod...

 

It's rather expensive compared to other AVR programmers, though.

 

- S

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

savino wrote:

Something like this: http://www.kanda.com/Handheld-AVR-Programmers.121.html

 

It might be worth an email to Kanda to see if they can support the xMega. I've always found their tech support really helpful.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's rather expensive

Particularly compare to the $15 units which Mr Henning supplied to the members here a few years ago. wink

 

Unfortunately it doesn't do Xmega.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, finding one for xmegas is the problem.  I will still pay some "real money" to someone to write a keyfob programer application.  Should be relatively easy for someone who has the time to tweak some of the code already out there into a standalone unit.

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And hardware.

Olimex's AVR-ISP-MK2 is OSHW (in Eagle).

Olimex has AVR ISP that have on-board storage but these don't do PDI.

If one doesn't want to build, distribute, support, and sell then the creator of Olimex might be interested in making (and etc.) your design.

www.olimex.com

https://www.olimex.com/Products/AVR/Programmers/AVR-ISP-MK2/open-source-hardware

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well Tom I have the time but I'm getting lazy in my old age! I have a product which uses the Xmega E5 but the approval process takes for ever, did EMI/EMC in May, next round of tests seem to be schedules for February some time then I may still have do do further test (K$) before approval, so far 2 years!!

 

If and when I get approvals I will need such a programmer myself, up to now I have been using the above mentioned programmer by Mike Henning (I have 3 of them) with Mega devices for programming on the bench (around 1,000 a year) and it will be a pain to use a computer to do the same with the Xmegas.

 

Our dear DocJC designed a Xmega programmer which could be put to good use for a keyfob programmer with some work and I did encourage him to work on a keyfob but he seems to think that being a doctor and saving lives is more important, where do his priorities lie anyway? wink

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe he just needs a little more bribery 8)  I can throw in assembly services to mass produce the things and I would think the things would sell easily.

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys.

 

Bend my arm...

 

My PDI programmer worked with the initial version of Xmega chips.

The second round of chips was released and there was a problem with my programmer.

I put it on the back bench for a while.  But not until I'd lost lots of sleep over it...

 

When I finally dusted off the project again the error, a "dumb, stupid, trivial, idiotic" mistake, was easily found.

I've made my share of those over the years.

 

John wanted a chip verify function added, and I've never gotten around to doing so.

There were a few other suggestions, but that was the biggest one, code wise, IIRC.

 

The secondary issue is that it was all put together piece by piece over a number of months, (actually years, now).

It started off as a "let's see if I can do this" project, not with any specific list of design criteria.

There is no consistency between how the different modules work.

 

I did learn a lot doing the project.

I did find several errors in the data sheets.

I did learn some more about binary data transfer to a PC, (using Visual Basic), and about decoding hex files.

etc.

 

Anyway, it would now be much easier to go re-do the project from a clean sheet of paper.

But I just don't have the time to do so.

 

To make a stand alone key-fob programmer would require:

Adding memory, presumably an SD card, or FRAM?

There is a Bascom SD card library, (similar to FATS ?), but I've never used it.

I am sure there is another learning curve there.

When I used an SD card on a ZBasic project in the past I just used it as a non-formatted linear memory.

 

Add the Chip verify feature.

 

Redo the PCB.  It was my first PCB with Rimu instead of ExpressPCB.

 

Write a manual.

 

Test it with some other Xmegas, to make sure it works properly with all of them.

It has never been tested with the Xmegas that include the USB module.

 

Note that the present design uses a Mega168 and a FTDI USB-to-Serial chip.

Again, Bascom has a add on USB library, but I've never purchased or used it.

In theory, I guess, one could use a Mega with USB and eliminate the FTDI chip.

 

I'll have to give it all some more thought.

Clearly the "hard part" is done.

The remaining items are small sub-components to turn it into a Key-Fob programmer.

It is just a matter of time...

 

It has been my main Xmega programmer for the last year or two, once I found the bug that let me use it on the XmegaE5's.

 

JC

 

 

 

 

Last Edited: Sat. Nov 29, 2014 - 06:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

H Jay,

 

In a nutshell, my needs are for a keyfob programer to support my xmega products in the field.   I would load them and send them to field techs who would return them to me when done.  The 'front end' for loading them does not have to be pretty since I'm the only one who would ever do it.  My current project uses the 384C3s, so at least that much storage is needed, and I also use a few smaller xmegas. too.  I was thinking of paying a fee to cover the cost of development, and licensing for strictly my own use.  I would also kick in assembly services for maybe the first couple hundred units in case you wanted to market them.  I would think they would be popular, I use the North Pole Engineering units for regular megas, and they are really handy not just for field use but production programing as well.  I have not been able to get NPE to add PDI capability.

 

Thanks!

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Tom,  the "Bribe" certainly helps to bump it up the list.

 

Even so, it won't happen real soon, as some more development work and testing on the new features has to get done.

 

I'll have to see what it would take to add downloading "raw" pages of data to a non-formatted SD card, and then be able to read them back for programming.

 

Also, do you and John feel that the ability to program the EEPROM is required for your current needs?

 

I assume a simple LED interface or two is OK for the end user doing the chip updates?

 

You would have the PC interface to work with when "loading" the device, and there would not be any LCD for instructions, messages, etc., for the end user, as it currently stands.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, I'm thinking just a single push button and a two-color led.  This is what the NPE units have and the led blinks green/yellow/red to show what is going on.  For my purposes it would have to program the eeprom and also set the fuses and lock bits.

 

Sending you a pm with another small detail 8)

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you need to program the devices in the field with PDI or could they have a bootloader already installed in them?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I am looking for such a device for my site work.

There are 2 methods that I can think off.

1) Bootloaders - This you still need to carry a laptop unless there is a handheld that can store you firmware

2) Using the PDI - Same need the laptop be present.

 

Currently I had found that E-lab Computers UPP1-X can support ATxmega.

 

http://www.e-lab.de/programmer/u...

 

Just need to know anyone out there try this?

 

Regards

ChawCS 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm locked in to using PDI, all the other i/o is usually tied up.

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes. My design too.

I am using ATxmega64A3U, but the hardware design with PDI.

 

Currently I am using ATAVRISP2 to program.

But need to work with a laptop, and sometime the cable that link to the PCB board cause problem.

 

CS

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes. My design too.

I am using ATxmega64A3U, but the hardware design with PDI.

 

Currently I am using ATAVRISP2 to program.

But need to work with a laptop, and sometime the cable that link to the PCB board cause problem.

 

CS

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike Henning's keyfob programmer uses AS4 to load the code into the programmer as a STK500, now of course with AS6 that's all down the drain as the programmer doesn't respond like a real STK500.

 

So your interface (DocJC) should be used as you can maintain it rather than rely on Atmel volatile IDE.

 

And of course PDI is all one gets with the smaller Xmegas.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have never used a keyfob programmer.    I do not know Mr Henning.

 

AS6 asks a few questions of the "STK500" to verify that it is talking to a real Atmel STK500.

 

Your "clone" just has to give the same answers as a real STK500.     Then AS6 will treat it as genuine.

 

I guess that AS6 is a bit fussier than AS4 when it comes to the "security questions".

Ask Mr Henning nicely and I am sure that he will update his keyfob firmware for you.

 

The only difficult part of a keyfob programmer is designing the pcb and enclosure.

The hardware is nothing more than an MCU, a Flash Memory chip and a GO button.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ask Mr Henning nicely

I don't think he is still interested, he made maybe 100 for the company he was working for at the time from memory and he asked here if anyone wanted one (looooong thread somewhere 2007+ https://www.avrfreaks.net/forum/t... ).

 

I think I got all the spare bits he had when I blew up one of them, some of the bits were no longer available so his circuit would need some redoing for newer parts.

 

It would be possible to modify the unit I guess to support Xmegas so if he reads this thread (is he still around here??) , but he was in Cincinnati Ohio so maybe the doc can pay him a "visit".....

 

One of my "neighbours" posted about a Xmega upgrade to the programmer earlier this year, don't know if he got anywhere https://www.avrfreaks.net/comment... may send him and email for an update.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Sun. Nov 30, 2014 - 08:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

The only difficult part of a keyfob programmer is designing the pcb and enclosure.

The hardware is nothing more than an MCU, a Flash Memory chip and a GO button.

 

I'd give the hardware a crack if people are interested in making a new version.  The software would be the more challenging (time consuming) for me.

 

Steve

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve,

I am interested in the hardware.

I think the PCB and casing a small part of this project.

Just need more time doing the firmware and communication with the microprocessor.

 

I had in mind to make one with PDI and bootloader.

Then we dont need to bring the laptop (it is true that now the laptop is light but still big).

 

If interest to share the hardware and schematic can email to me at

chaw@smartmrt.com

 

Thanks

CS

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Err... I don't have anything to share. (yet?)

Just saying if folks here are considering rolling a new keyfob field programmer, have the firmware under control but no hardware, then I'll throw my hat into the ring to whip up a design for that.

 

Steve.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I was also thinking. 

1) That is a keyfob that work like a programmer.

2) A keyfob that work with a bootloader.

 

This way we will dont worry about the customer know our code, and dont need to carry a labtop when programming on site.

 

Anyone out there got any idea doing this device?

 

CS

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone out there got any idea doing this device?

Yes, I am evaluating this project.

But it is a slow process, and I don't have much time to spend on it, which makes it take even longer.

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Will Dean Camera's Buttload do the job?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean's program came out long before the Xmega chips were released.

 

I don't recall hearing of an update to the program which included the PDI protocol.

 

Dean's LUFA software does support PDI programming, and there are a number of LUFA based PDI programmer projects on the web.

 

I don't recall seeing any of these having been modified to act as stand alone programmers, although it would be a great starting point, as the core part of the program is already written and debugged.

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got buttload up and running... its good! Bit bigger than a keyfob though.

 

Hardware wise I was thinking something along the lines of the Xmega128A1 Xplained board.  The Rev2 board I have has a 90USB1287 as the board controller.  Dean has developed some code for this which makes it appear as an ISP to AVRstudio (maybe only V.4) and provide the PDI programming of the main 128A1 chip. It can also act as a USB-UART bridge in a different mode. The Xplained board even has a Data Flash chip too. (I believe both the 128A1 and the board controller can access this.)

 

So most of the system is there. I don't imagine it would be all that big a deal to modify/extend the firmware, though this board is possibly outdated. (I believe most of the latest Xplained boards use a 32UC3B as the board controller now but I'm not sure what firmware is available.  It may also belong to Atmel.)

 

Looking like a universal keyfob-pod. Standard ISP, Field (computer-less) ISP and/or Bootloader, USB-Serial bridge, decorative keyring. (Gotta have an RGB LED on it for sure! yes)

 

I just want 1.

Merry Xmas!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And after a little bit more thought, the 90USB1287 supports USB-OTG I believe, so you could add capability to connect in a memory card with options to use that instead of internal memory or transfer new target firmware to the internal memory.

 

I better go to bed. I'm in danger of feature creep.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

schtevo wrote:
I got buttload up and running... its good! Bit bigger than a keyfob though.
Yeah, but you can pin it on your shirt.  smiley

 

The nice thing about the Butterfly is it was designed to run on the coin cell on the back of the board.  It would run for years on that cell assuming it sleeps almost all the time.  I liked the joystick and LCD glass too.

 

The limitation of the Butterfly for me is the 16k Mega they put on it.  16k cramps my style big time.  I used to remove that chip and put on one with more program flash. 

 

Apparently Atmel doesn't make any Xmega boards for battery operation.  The a3bu Xplained board has dataflash, but you would need to supply your own battery.  Actually it does have a small battery on board but it's just to demonstrate battery backup for RTC.

Last Edited: Mon. Dec 15, 2014 - 11:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A keyfob programmer doesn't really need a battery, (not for me, anyway) although I have seen some that did have a small internal battery and could program a 'cold' board.  "Back feeding" a lot of my target boards would overload a keyfob's coin cell because it would be trying to power the board's lcd backlight, among other things.

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Letting the Programmer obtain its power from the target board simplifies the power supply design somewhat.

 

One still has to think about the possibility of it being plugged into a target board, which is trying to power the Programmer, while the programmer is plugged into a PC.

 

The Programmer needs to be able to be plugged into a PC in order to load the program into the Programmer, which it is to then eventually, independently, load into the target board.

 

BUT, if it is possible to "screw it up", someone will, and clearly it would be possible to have the Programmer plugged into a PC and a Target board simultaneously.

 

Even dual schottky diodes are a bit problematic, as even their low voltage drop is significant at these voltages.

I also recall seeing a smart power selector chip, but those cost $ and take up board space.

We'll have to give it some more thought.

 

JC

Last Edited: Tue. Dec 16, 2014 - 05:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simple! The keyfob should NOT provide power but get it's power from the target. FULL STOP.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do agree that the keyfob should not provide power.

Where it power should get from?

 

If as docJC mention that if it is plug to the target and PC.

Where should the power from? PC or target?

If last time RS232 still fine, mostly RS232 dont provide the power.

Now we should be using USB which came with 5V.

CS

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where it power should get from?

From the same place as it will get it's power AFTER being programmed.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The programmee's VCC?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tpappano wrote:
A keyfob programmer doesn't really need a battery, (not for me, anyway) ...

DocJC wrote:
One still has to think about the possibility of it being plugged into a target board, which is trying to power the Programmer, while the programmer is plugged into a PC.
There are some AVR fob-"like" programmers that use a USB isolator :

www.olimex.com

https://www.olimex.com/Products/AVR/Programmers/AVR-ISP500-ISO/

USB STK500v2 compatible AVR programmer with 6 pin and 10 pin ICSP connector support and 1000VDC isolation

VERY handy for low voltage AC (off-line) that will or likely kill; some are connected to greater voltages that will kill (via third-hand recountings).

Handy even for extra low voltage; 12Vdc automobile (car, light truck), 24Vdc (bus, semi-tractor, medium truck), 48Vdc (nominal) (some data centers).

One might "like" their laptop; B&B Electronics has a USB isolator for laptops.

USB isolator ICs exist.

 

Batteries -

Rechargeables/secondaries usually don't cover the industrial temperature range; some primaries will.

In lieu of a battery, can usually LDO/SMPS/etc the available power to 5Vdc on a common barrel connection.

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Dec 16, 2014 - 08:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use of a battery may well be limited by the choice of key-fob enclosure. The 1 I've used in the past accepts an A123 (12V lighter type). http://www.jaycar.com.au/productView.asp?ID=HB5605  Others I'm aware of take coin cells.

 

I reckon battery supply with VTG to set level translators (ISP MkII style) would be the go. So not USB bus powered. (Unless you wanted to charge the internal battery via USB - that would be nice!) Although the ability to back feed the target board would be nice too. I just finished a design that permits this. Though I think its a bit problematic to do in a general sense as others have already mentioned.

 

Is isolated USB really necessary? I don't believe the standard ISPs are. Yes/No?

 

If feature creep prevails, how do you all feel about this enclosure? - http://www.hammondmfg.com/1455v1B.jpg

Bigger than a keyfob so can fit more stuff but still tiny at 60x45x25mm or even 80x45x25mm and this would allow some sort of Li+ or LiPO battery that could be charged off USB. This could permit target powering.

 

Steve

Last Edited: Tue. Dec 16, 2014 - 10:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

schtevo wrote:
Is isolated USB really necessary?
No; USB isolation is not minimal essential.

schtevo wrote:
I don't believe the standard ISPs are.
True; a USB isolator can be external.

schtevo wrote:
If feature creep prevails, how do you all feel about this enclosure?
Looks rugged and that's good.

schtevo wrote:
Bigger than a keyfob ...
fyi, this :

AAA Fob Enclosure

http://www.newageenclosures.com/cart.php?m=product_detail&p=138&c=11

is a recent arrival at a major US distributor.

Its PCB is small so no incentive for feature creep wink

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Darn Atmel.

 

All of the initial Xmegas had 1, 2 or 4 kBytes of EEPROM.

 

The two smallest XmegaE5 uC's have 0.5 kBytes of EEPROM.

 

The original variable for the EEPROM memory size was an integer. (Long before the E5's came on the market)

 

I can't even count the number of places this surprising ripples through the PC's and the programmer's code.

 

Now I have to go purchase an Xmega8E5 chip, and put it on a board, so I can test changes made for burning and verifying small Xmega EEPROMs!

 

The next unanticipated hurdle, (although to be fair the above is just a plain old bug...), is that I don't think the SD card library will fit in the M168 with the other code.

So, I'll have to look at the 328 as well.

 

Redoing this on a clean start would certainly shrink the size of the spaghetti code, but there aren't enough hours in the day for that.

 

Oh well, step at a time.

 

The "To Do" list for the project keeps seeming to grow, not shrink!

 

"Key Fob" sized in my mind means a tad bit smaller than an STK500!

(Miniaturization isn't my strong point.)

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I like that New Age enclosure. Don't like the very small PCB size. Reminds me of an old style pager.  Now what would be nice is the same case with a single AA or AAA battery allowing twice the PCB real estate and we could use a step-up converter like Jim is using in one of his current projects.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Most of my projects are for myself, (Hobby), or prototypes / one off custom widgets.

In both of these cases price isn't an issue, (e.g. it doesn't matter if one uses a tiny or a mega, the difference in price is not an issue for 1 - 10 PCBs).

 

For a Key Fob Programmer, there has to be a memory storage device, obviously.

Currently the largest Xmegas have 384KBytes of Application Flash, and 4 KBytes of EEPROM.

Some additional storage is needed to store a "Command File", to tell the programmer to burn the Flash, EEPROM, and/or Fuses, plus a few other small variables.

 

Two obvious data storage media are SD cards and FRAM.

 

SD is convenient in that if one's customer already had the Key Fob one could just drop an SD card in the mail to them for an update.

FRAM would require "loading" the FRAM on the Key Fob, easy for anyone on this site, but defeats the purpose, a bit, of an easy to use Key Fob Programmer.

 

Mass Production Reality Check:

Two, 256Kx8 FRAM chips would cost about $38 from Mouser, in small quantities, and the chip is already marked as End of Life!

 

The commonly used SD card FATS Library for Bascom needs a 64K or 128K uC.

Technically it will run with 1 file handle in a 32K uC, but it doesn't leave much SRAM for the main program.

 

So much for running this project on a M168!

 

Of course, as one switches to a larger uC, the next argument goes why not just use one with a USB module, and ditch the FTDI chip?

 

Unfortunately I don't have any experience with using the on chip USB modules, and this project already has enough "learning curves" attached to it without adding that one.

 

And I hate hand soldering the larger 64/100 pin uC's for building up the prototype.

 

Of course if the project was "trivial", there would already be 10 options on the market...

 

Is carrying a NetBook PC and a credit card sized PCB PDI programmer really that difficult? cheeky

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

The commonly used SD card FATS Library for Bascom needs a 64K or 128K uC.

Technically it will run with 1 file handle in a 32K uC, but it doesn't leave much SRAM for the main program.

 

I'm using elm-chang FatFs on a 32K XMega (xmega32a4) and there is still plenty of SRAM and FLASH for the main program. It does have 4k SRAM, but I'm wasting e.g. 1k+ just for uart buffers. It is a 44 pin device.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is carrying a NetBook PC and a credit card sized PCB PDI programmer really that difficult?

I already carry a laptop and ISP MkII so no big deal there, but trying to hold both and operate when tables are not available is a PITA.

And as many have said before, not so great for non-technical customers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Elm Chan's FATs is certainly well know and bug free.

 

Unfortunately my core programmer software is written in Bascom, not C, and the Bascom FATs library uses more memory.

 

Another option I'm looking at is using an SD card as a memory device, sector by sector, without the overhead of a file system structure.

The software to do this is somewhat less involved, and shorter.

 

JC  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Another option I'm looking at is using an SD card as a memory device, sector by sector, without the overhead of a file system structure.

The software to do this is somewhat less involved, and shorter.

Also not standard.  You will have to write software to be able to put the image on the SD if you go this route.  I vote for FAT file system support.

 

Neat project.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not use dataflash?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not use dataflash?

surprise  Because I hadn't considered it... 

 

Hi Steve, what a Great Suggestion!

 

So, is Adesto an Atmel subsidiary?

I couldn't find the DataFlash AT45DB041 on Atmel's web page.

The Butterfly used the B version.

Several pointers later I see the chip is now up to the E version, and is $1 each in small quantities, at Mouser, under the Adeso name brand.

 

Definitely a good possibility, especially for a Key Fob device.

 

Thanks for mentioning it!

(I knew my rant would serve a purpose.  It lowered my Blood Pressure and gave me another good option to investigate!)

 

Larry,

 

I hear what you are saying about FATS.

 

Operationally, conceptually, one would plug the Key Fob into a (Windows) PC and download the Application Program, EEPROM File, Fuses, and a "command file" to the memory device.

This would use a custom PC software program, not Atmel Studio.

 

Given that the upload to the memory is handled via a custom program, and uses the custom (Key Fob) hardware, a lot of the "usefulness" of a FATS storage structure is absent. 

 

Presumably the reason to use a FATS file structure is so that one could just copy the four files to the SD card, without using the Key Fob or the custom software.

 

I understand that convenience.  But I also understand that means more software on the uC to search for the various files, etc.

I'm not much of a programmer, but I could probably figure that part out.

The extra kicker is the FATS library for Bascom is quite large, and would really push the project to a 64K chip.

And I hate hand soldering those 64 and 100 pin chips by hand to make my prototypes!

 

Lots of options to mull over!

 

I certainly appreciate all of the comments!

 

JC  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"the E version, and is $1 each in small quantities" - never used DataFlash. Is it so expensive because of the byte-write mode similar to EEPROM? But that is not really needed for this project? Standard serial flash should work just fine? Say, AT25SF041.

Last Edited: Fri. Dec 19, 2014 - 12:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I already carry a laptop and ISP MkII so no big deal there, but trying to hold both and operate when tables are not available is a PITA.

And as many have said before, not so great for non-technical customers.

Try balancing on two stacked 5-gallon buckets on top of a 12-story building's roof covered with four feet of snow, and a temp of 14 degF and 25 mph winds gusting to 35 8)

 

I'm excited to see the interest in the programmer! FWIW, my NPE keyfobs (the ones I really like but that don't do PDI) use an AT45DB021 Dataflash, a Mega8 and a CP2102 USB interface.

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Ezharkov,

 

Murphy's Law strikes again.

Wouldn't you know I just order a couple of the "E" DataFlash chips to try out, and a couple Xmega8E5's to fix the EEPROM programming and verifying bug on the 0.5 K EEPROM chips.

And THEN I stopped by here and saw your comments about the other Standard Serial Flash chips.

Live and Learn!

 

Tom,

Maybe Santa will bring you a ladder for Christmas!

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

savino wrote:
I'm using the atxmega32a4u and I need something that can be used in the field without pc.
XMEGA32A4U is in the supported devices list for 4D Electronics LTD (Christchurch, NZ) FISP(tm).

XMEGA384C3, other XMEGA C, and XMEGA E are not in that list but "+ more" is; an inquiry might bear some fruit.

Not a fob, 4MBytes flash, JTAG or PDI.

Located by Atmel third party list for AVR programmers via Atmel support; I did not go further into that list (2 pages long).

 

Ref.

4D Electronics LTD Logo

http://www.4d-electronics.co.nz/themes/new/images/header_no_logo.png

http://www.4d-electronics.co.nz/fisp/

 Atmel Corporation

Home > Design Support > Knowledge Base

Production programmers for Atmel microcontrollers

http://atmel.force.com/support/articles/en_US/FAQ/Production-programmers-for-Atmel-microcontrollers?q=atmel&l=en_US&c=Development_Tools%3AProgrammers_and_Debuggers&fs=Search&pn=1

 Atmel Corporation

Home > About Atmel > Contact Atmel > Partners

http://www.atmel.com/about/contact/sales/default.aspx?contactType=Third%20Party%20Support%20-%20AVR

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

savino wrote:
I'm using the atxmega32a4u and I need something that can be used in the field without pc.
E-LAB Computers (Bad Rappenau, Germany) has a few portables for ISP that have XMEGA32A4U in the device list and can be powered from the target.

The XMEGA in its device list appears complete (though by a very brief look).

UPP1-X portable ISP programmer

http://www.e-lab.de/programmer/upp1_en.html

  • All data and parameters are stored in an exchangeable SD Flashcard
  • No powersupply necessary. The unit is powered direct from the USB port of the PC or the target.
  • Software runs under XP, Vista32 and Windows7, 32 and 64bit
  • Small, light weight and handy unit 110x55x20mm
  • Can process AES encrypted projects with the tool PackProg.exe and also directly from its SD card

E-LAB Computers is in Atmel's AVR third party list but their URL is not in that list.

E-LAB Computers has other programmers (portable, portable with display, remote control, DIN mount, PC, etc.).

http://www.e-lab.de/index_en.html

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Make it a Key Fob Programmer they said...

 

Just add some memory they said...

 

Minor upgrade they said...

 

To Hell with all of you!  wink

 

I swore a lot this morning "Dead Bug" mounting the DataFlash memory chip, and adding it to the PDI Programmer prototype.

 

Because of the current M168 pin usage, I'll be communicating with the DataFlash with a software SPI.  It just isn't worth the prototype surgery and current software changes to free up the hardware SPI SS\ signal.

 

Every time I turn around I add 1/2 a dozen more items to the "Still to do list".

It would sure be nice to scratch one off the list!

 

BTY, I really like the XmegaE5 series micros, but I swore a lot at Atmel, last night, when I saw the E5 series adds Fuse #6, which none of the other Xmegas utilize.

And which none of the current PDI programmer software knows anything about.

I was already perturbed that it only has 0.5 KB EEPROM, as all of the current PDI software uses integers for memory size...

The software is starting to get very kludgy with lots of special cases being added...

 

The Prototype sure isn't pretty.

Actually, its pretty ugly!

But functionality is the fundamental goal with a prototype.

 

Anyway, the project creeps forward, veeeeery slowly, but forward none-the-less.

 

JC

 

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very artistic if nothing else.....cheeky

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It looks like Doc attached some "high" memory.  Nice job splicing all the arteries, veins and nerves too.  Almost looks like original equipment.  smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Love your work Jay.

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very nice!  I love the vertical integration!

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I especially like the melted switch actuator. Been there, done that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I especially like the melted switch actuator. Been there, done that.

Sniff, Sniff...

 

What's that burning?

 

Oh man, it's the plastic knob on the switch!

 

For much of my work these days I have to wear a jeweler's loupe to see what I'm doing.

Unfortunately, one's field of view is very limited, and it is easy to bump the soldering iron against something.

 

Fortunately, no harm done, (except to my pride!).

 

JC 

Last Edited: Sun. Jan 11, 2015 - 03:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

So which is better, a tall button or short button on the switch?  A short button is less apt to get melted, but you can melt a tall one many times without much harm.  smiley

 

Years ago, when I used a plain conical tip, I used to melt stuff with the side of the iron far from the tip, because I had to hold the iron almost horizontal.  Since I discovered bent tips, by dropping my iron on the floor, I haven't done much damage with my iron.

 

Now I'm learning hot air soldering.  I melted a bit on the top of a button with that. 

 

When I get good with hot air, I may become a politician.

Last Edited: Mon. Jan 12, 2015 - 03:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hot air soldering

I'd be interested in hearing your thoughts on that.

 

So far when I do SMD PCBs I usually cook them on a frying pan, or occasionally will hand solder them. 

 

I've not yet used stencils, so pre-loading the PCB with solder pastes is the trickiest part of the task.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What cooking today?

Soldering?

 

I see my friends use a iron (those use to iron cloth) to melt the solder.

But that to solder the SMD LED, use for lighting.

 

cs

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

I've not yet used stencils, so pre-loading the PCB with solder pastes is the trickiest part of the task.

 

JC

Same here.  I have a hard time getting the solder paste to stick to the pad.  In the future I will try cleaning the pad first and maybe rough it up with fine sandpaper.  The solder paste I use has been in the refrigerator for several years.  Maybe fresh stuff would stick better.

 

The advantage of solder paste, versus tinning the pads, is I can see some activity happening about the time the solder melts.

 

So far, I find it easier to forego the solder paste.  I tin the pads with my iron and then add some flux.  The problem here is that I can see no indication of when the solder melts.  I don't know how long to apply the hot air.  Once I see plastic melting it's too late.  smiley     I'm getting better at guessing.  Poking the part gently will tell me.  If the solder is molten I can see that.  If I don't move it far, the molten solder will pull it back to the center of the pad.  If I move it too far, I have to poke it back.

 

 

The first hurdle is knowing how to set the knobs.  By trial and error, I set the air speed to the minimum and use the next smallest nozzle.   If I use the smallest nozzle, the wind speed is too high and it blows the parts around on the board.  I set the heat knob at mid-range.

 

It should help to pre-heat the board.  Maybe some day I will buy a preheater.  In the meantime I sometimes pick up the board and blow some hot air on the bottom before I begin soldering.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the feedback on how the process is going / went.

 

At some point I may give it a try, and it is nice to benefit from other's experience.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

THis looks perfect

http://www.avrtool.co.kr/shop/go...

But I am unable to get the Koreans to reply to me and their online shop is only in Korean - anyone else that might have heard of them or used the programmer

Pieter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From a quick skim of its manual I could not find how much memory is inside the ProISP IV though it does have a red empty memory LED wink; it appears to be created by Prochild, also a Korean only E-shop, but maybe an alternate contact.

http://prochild.co.kr/eshop/eshop_01.asp

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After using google.

I found the attach manual

Any help?

Look english to me.

CS

Attachment(s): 

Last Edited: Sat. Feb 7, 2015 - 11:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jip - thats about as far as I got as well - I did send email to the contact info on the webpage - if I get a response I will update this post

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it as say in the manual.

It will much better then Atmel AVRISP mkII.

I just got some info that AVRISP mkII is going EOL

CS

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chawcs_smartmrt wrote:
I am using ATxmega64A3U, but the hardware design with PDI.

 

Currently I am using ATAVRISP2 to program.

Jim's Projects

Cheap USBASP knockoff programmer

Posted on December 18, 2014 by Jim

http://jimlaurwilliams.org/wordpress/?p=4803

...

Update: PDI programmer and more cable stuff

...

... – the hacked avrdude/USBASP could see the XMega32A4U on the Xprotolab scope via PDI!  I burned the updated firmware from Gabotronics, and ...

P.S.

Looking forward to DocJC's test results.

"Dare to be naïve." - Buckminster Fuller

Last Edited: Mon. Feb 16, 2015 - 10:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey, if that ProISP linked to above already does stand-alone PDI programming then I'm off the hook!

 

My connected to a PC and interfaced via a custom PC software interface works.

 

I don't have the stand alone version working, yet.

 

Unfortunately, work is keeping me rather busy at the moment, and I've not had much time to  work on the new & improved version.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Doc.,

I agree with you too.

Just that I had drop them an email, until now no reply.

 

It is design by Atmel dist. in South Korea, Prochild.

http://www.prochild.com/eshop/es...

 

Is this model EOL?

 

CS