uProg - small, fast, portable AVR programmer with SD

How about changing the LCD to something easier to buy and install ?? e.g.
http://artronic.pl/o_produkcie.php?id=1078?
In case of need, I serve the appropriate library for Bascom.

J_Bravo, are n3310 lids not easy to buy? You will get it in every mobile store (original for PLN 30) and on alle ... it also multiplies with offers from PLN 9 for fakes, which uProg also supports. And the assembly, as you can see, is not too difficult and if someone can solder the SMD process, this connector with the plates will also be soldered

As for the assembly, the photos you posted confirm my words.

piotrva I would not exaggerate with each store Generally, it's hard to buy them apart from Allegro and online stores - these phones are already extinct and therefore they do not bring these LCDs.

In Poznań, it is practically impossible to buy

At my place in Krakow, I probably asked in 5-6 stores (out of curiosity) and they had originals from PLN 25-30 everywhere, and in one even for PLN 35 they offered LCD with a telephone for free.

As for the assembly, do I know? It is easier for me to solder these plates and press these wires with these wires (it does not move at all) than to solder the tape permanently to the PCB, although it goes out for one thing, because you have to fix it somehow, so as not to break such a tape (well, but maybe and I will admit part of the truth to my colleague, because then the whole thing is less sensitive to possible LCD shifts in relation to the connector) - just a matter of taste.

I think anyone who doesn't have two left hands will do fine with the fastening. One needs to play on the desk, so he will do it with a wire. Another need for actual programming somewhere outside the house, and he will make the housing out of something and put it together nicely.

As for the displays ... yes, the cheapest Chinese cost PLN 9 (but look at how much shipping costs, as is usually on the Allegro). I do not see any problem with access. Since we order a processor or a card slot by shipment, the display can also be ordered.

J_Bravo - how much does this display cost? Need to write to them and bargain? The availability is the same - we order. Only a secure connection, but after all, the display must be attached anyway. Well, this was the LCD I had and it remained so :)

Support for the M2560 and M2561 will be added today or tomorrow and there will be an update.


(note big)

I also got a proposal to change the way of naming the created files. Not 1 2 3 4 only e.g. tiny13-4 or mega8-1. So I take the name of Prock (which I already have), cut out the first two characters that are always "AT", take the next 5, put a dash is the sixth, and there is room for a two-digit number. Due to the limitation of characters to 8, the name will be displayed in full on the display (naming dos 8.3). And if someone wants to read, for example, Atmegi 16 and Atmegi162 memories, then the next number can be noted - because in both cases the name will look like "mega16-x". But I think it's a lot easier and I hope that it can be added in a simple way :)

tmf wrote:

I think you're counting addresses incorrectly. Note that records 02-05 contain misspelled addresses that you should read, not assume that the address space is linearly addressed. It matters in the code, where you move segments, or create your own segments in memory (BASCOM probably does not have this, so you may not encounter this problem). For example, if a variable is to be in a specific FLASH memory location, then in hex you have a record before and after which there is a "hole" in the addressing. A somewhat fancy problem, but real is sticking two hexes together. For example, I have a hex with bootloader and application code and I want to get the resulting hex. Then, additionally, the order of addressing does not have to be increasing at all.

So that you have come across batches designed in such a way that the bootloader is placed first, and then the actual program? Or complete confusion with confusion? I don't know why someone should construct a file this way, but yes, you can. I wonder if all programmers can bite something like that Because even if at the end there will be one line with a random (earlier) address, the programmer must be smart enough to save only this data in the page, and then save this page to memory, checking the last byte of this additional record and not the last byte of the page. There is work to do.

And I noticed, for example, that giving avrdude a HEX file with bootloader (only what is needed, the rest of the empty data is not there), he uploads the entire 64kB file anyway. uProg only uploads the data that exists, the rest are skipped. Also, even if we have holes somewhere in the addressing, all this is omitted - the most important thing is to get to the last byte that was previously calculated. As you write, it may not be the best solution, but it is simply implemented. If someone has a strange file and has problems with it, he will report it and we will work on a fix

I can see that my colleague manekinen nicely restored my first m2560 - at least it will be useful and it will not lie in the cupboard
As for the file names, the prock names could be shortened and write only m8, t2313 (i.e. we skip the first 2 characters, take the first letter, then go to the number and fly the name to the end).
As for the files, it will probably be like with my bootloaders - if someone accidentally hits something, it will be known. But I think that our colleague tmf could also generate some quirks for us for extreme tests

Yes, I will prepare a few files (not fancy ones, but from my applications) that have slightly different settings than the standard ones and we can test them. As long as you are interested, of course. In general, I like the project very much, as I wrote, I have slightly different needs, but if the next version had, as I wrote, the possibility of direct communication with a PC and using it as an ordinary programmer, additionally PDI support and even programming after JTAG, it would be honey. If you would like to develop it in this direction, I will try to help.

piotrva wrote:

As for the file names, the prock names could be shortened and write only m8, t2313 (i.e. we skip the first 2 characters, take the first letter, then go to the number and fly the name to the end).

You don't even need to check if the sign is a number (it will be a little bit not optimal).

at-tiny-13
at-mega-16

They each have 4 characters So it is enough to skip 2 characters first and then 3. It will be even clearer, because full names will be entered (eg "m2560-12") - but what about procks with "AT90S" "AT90CAN" "AT90PWM" "AT90USB" prefix? We'll only see nine. A bit of a hoot But if I cut 5 characters, it will be "at90s", "at90c", at90p "," at90u "and you will know what's going on :)

tmf wrote:

Yes, I will prepare a few files (not fancy ones, but from my applications) that have slightly different settings than the standard ones and we can test them. As long as you are interested, of course.

Sure, if these are files that you can actually meet, why not, you can test and improve these hexes - gladly.

tmf wrote:

In general, I like the project very much, as I wrote, I have slightly different needs, but if the next version had, as I wrote, the possibility of direct communication with a PC and using it as an ordinary programmer, additionally PDI support and even programming after JTAG, it would be honey. If you would like to develop it in this direction, I will try to help.

I do not know how it will be with me in time. If I have it, I will be thinking about a completely new version - because you won't get much out of this one. Willingness is there, ideas are there, as always, the time is not

I recently paid 20 zlotys for these displays.
They have a plus that it is easier to solder and easier to attach to the board. You do not need makeshift plastic packaging for scalers or friends' cables. Additionally, there is only one model on one driver so there is no incompatibility problem.
LCD works on I2C and SPI.

Hello colleagues

As I tested the uProg in a system in which I had mosfet transistors on the ports used for the ISP, which gave quite a large load and thus a programming voltage drop, in order to program the processor in the system, the minimum battery voltage had to be 3.4V - then there were no problems.

But what will the voltage drop and there is nowhere to recharge?

I made a buffer - traditionally on the 74HC244.
The buffer is powered from the target circuit, so the programming voltage will be at the level of the target circuit.

Maybe it will be useful to someone

It can be connected directly to the connector on the threshold



I know that the Polygon is not connected to the ground, but it was supposed to be - the socket is much better soldered to the PCB

Hello,
I am the happy owner of this programmer (board and display were purchased from the author). I just launched it, but it showed an error - you can see in the pictures:
https://obrazki.elektroda.pl/5043712000_1310929712.jpg
https://obrazki.elektroda.pl/5393731200_1310929713.jpg
It doesn't matter if there is a microSD card or not. Reacts very slowly to button presses. Do you have to set anything up in the files on the card?
Please help.

This is how it behaves when there is no card - i.e. when it does not see it, or when there are no files on it - Have you uploaded all the directories?

Yes, but I didn't change anything.

It should move and no change ...

How did you set up the Fusebits?

If you have a GG, send me an e-mail and I will try to help

The card contains all the files. The card is of the SD type (not SDHC), formatted in FAT32. 3.4V power supply from the power supply. I haven't set the fusebits yet (I don't know how yet). Tomorrow I will check the transitions between the card pins and the prock.

Well, you have to change the fusebits, first of all. Second, what's your capacitor next to the SD card?

Capacitor 10uF as in the diagram. And how to change fusebits? in config.ini?

You change fusebits in the processor not in config.ini and 10uF may not be enough

What did you program the processor with?

On standard 1MHz it will go too, but very slowly

Capacitor give a minimum of 20-22uF. Fusebits are changed with the programmer ...

mlassota wrote:

I made a buffer - traditionally on the 74HC244.
The buffer is powered from the target circuit, so the programming voltage will be at the level of the target circuit.

Maybe it will be useful to someone

It can be connected directly to the connector on the uProg

Thanks for sharing the ready-made buffer, I think I still have such a system somewhere, so I will definitely do it - because it will certainly facilitate the programming of systems with loaded ISP lines by other elements.

Simon79 wrote:

Hello,
I am the happy owner of this programmer (board and display were purchased from the author). I started it a moment ago, but it showed an error - you can see in the pictures

On the display you can see the cut word "SD ERROR", which means that the card has not been initialized and thus no settings from the file have been read. As colleagues advise, the 10 uF capacitor is too small. The diagram is mine, but please read the description - I explained in it something about the initiation of the card and the current it consumes at startup. A 22uF or 33uF capacitor will certainly do the trick :)

Simon79 wrote:

Reacts very slowly to button presses.

So the circuit is at 1MHz. Be sure to set the fusebits. See the support file in the batch directory. After that, everything should move nicely :)

Update .... yeah .... was supposed to be, unfortunately I ran into some problems but everything is on the right track

There are a few ideas for automation, so I'm going to throw in my three cents on this.
Well, the idea of automation came up, we load fusses and hex / bin, if they have the same name. But it can be disastrous when using CPU download files in this way. For example, we have files with numbers 1, 2 and 3, and fusebits from a certain processor model are read sequentially. But then we also download flash from this 3rd system (which we get, let's assume number 1) and we want to upload it to another, but ... which can temporarily block the processor, even worse if the system is composed of SMD) fusebits.
So my idea would be this.
1. Automatic save
We have an additional auto option in the flash write option, it reads txt files from an additional directory on the SD card in which we have saved (let's assume in the following lines) 1.fusebits, as in the original files with fusebits in this programmer, 2.the name of the related file from the flash directory, 3. the name of the related file from the eeprom 4 directory, lockbits (if we do not want to upload any of them or change fuses / lockbits, we signal it with an empty line).
And you know how the programmer behaves - uploads fusks, flash, eeprom, sets LB
2.automatic reading
we click the auto-read option (there is still enough space in the flash menu) and then the programmer reads all the above-mentioned settings and creates the appropriate files with memory images and saves the file in the auto directory, where it saves the names of these files and FB, LB settings.

What would colleagues think of such a solution?
We are waiting for your opinions

Update No. 3

Soft v.1.3
o Fixed bug when uploading HEX files that do not start with address 0 - e.g. bootloaders.
o the size of the hex file is a bit faster
o modified "config.ini" file - now it will be more readable
o added OSCCAL setting to "config.ini" file - if you use increased programmer speed (bit0 in "config.ini" file) then you can enter your own calibration from 00 to FF - some procks failed at maximum overclocking.
o added the MAX SCK setting to the "config.ini" file - if for some reason the programmer incorrectly selects the SCK speed (too fast) and there are errors, you can select the maximum speed from which the programmer will start.
o added file deletion function - select the file and while holding the LE button press the RI button. Release the LE button to exit.
o resistance to vibration of button contacts has been improved
o fixed support for chips with extended memory (atmega2560 and atmega2561)
o added the "manual" function that allows you to enter your own fusebits. Scroll through each character with UP and DN buttons, use RI button to confirm your selection and go to the next character. After confirming the last one, the programmer will save and then read the fuses and display them in the bottom line. You can cancel with the LE button. The program takes FACTORY DEFENSES for a given layout, and this is what we edit.
Be careful when using options! I posted a short video HERE option can be said in beta.
o added an additional lowest SCK speed - 8kHz - it is possible to program chips clocked with clockwork quartz.
o the way of naming created files has been changed. From now on, the names will have the form "m8-xx", "m162-xx", "t2313-xx" where x is the sequence number. This makes it very easy to identify the files. It was enough to add ONE line of code and what a convenience
o the chip.db file should be updated - I changed the prock names in it so that they do not contain slashes. If the program creates a name
file from the name of the prock, then the name "Atmega644 / A" will give rise to the name "m644 / -1" - the file with a slash cannot be read on
computer. I have replaced the slashes with dashes.
o a file with the "LICENSE.TXT" license has been added, it should be copied to the main directory of the card. It should be read and possibly his
Polish version of. The programmer will not work if this file is missing or if it has been modified.
o maybe there are still some changes, but I don't remember how to add anything :)

File changes:
-config.ini
-chip.db 1.03
-new folders "welcome" and "goodbye".
- LICENSE.TXT file for version 1.3

Further suggestions:
- memory auto program - both read and write, easy copying of whole processors, etc. I didn't enter it this time due to insufficient free memory. Please read the post above from my colleague piotrva and submit any ideas
-detection of enabled lockbits before trying to read to the file - then we will get the appropriate information instead of creating an empty file
-safe change of daffodils - if after saving dregs the verification returns an error, the program will not release the reset but will allow you to re-write them. Then we will not block Prock due to communication errors - in fact it has not happened yet, but it's better to be safe than sorry
- xmega and PDI support - I will definitely try to add it
- "correct" handling of HEX files in this version I have not introduced, because the topic is a bit deeper. It is not only about the correct adding of extended addressing, but most of all about the possibility of random programming of memory fragments. While programming bytes is a piece of cake, when programming by pages, the program must be smart enough not to get lost.

FAQ - or frequently asked questions and answers
I will supplement this list over time, so far there are so many:

Q: I can't see anything on the screen / can't turn it on.
AT 1: Measure the voltage across the memory card capacitor and the display capacitor - they must be the same as the supply voltage.
O2: Make sure the display is in the correct alignment that all contacts connect in the right places.
O3: Look for assembly errors, make sure that the processor is correctly programmed.
AT 4: Make sure you have uploaded all files to the card.
AT 5: Make sure that the supply voltage is lower than 3.7V - otherwise the programmer will not turn on.

Q: The screen shows chaff, the subtitles are cut off. I can see a greeting.
ABOUT: Change the display type in the "config.ini" file - bit 7

Q: "ERROR" is displayed for a moment - no greeting. Subtitles may be shifted.
AT 1: The memory card has not been initialized. Make sure you format it to FAT16 or FAT32 and that it is a regular SD card up to 2gb (not SDHC).
O2: The capacitor on the memory card power supply should be at least 10uF, if the card does not work, increase the capacity to 22uF or even 33uF.
O3: Make sure that the power supply to the system is 3.3V (minimum 3.0V) - some cards need this voltage to start.
AT 4: Try a different card.

Q: Card has errors, files cannot be deleted or read.
ABOUT: Format the card and upload the files again.

Q: The card is no longer recognized by the computer.
ABOUT: Format the card in your phone or digital camera.

Q: The programmer selects a speed that is too high and verification reveals write errors.
AT 1: In the case of a long programming tape, change the max SCK frequency setting in the file "config.ini"
O2: If the tape is short, it means that the programmer works too fast (e.g. at 16.1MHz) and for the target chip clocked with e.g. 8MHz, the SCK speed will actually be 2.025MHz (and the maximum is 4 times smaller, i.e. 2.00MHz) - the whole works on error boundary. Reduce the calibration value "OSCCAL" in the file "config.ini" by a few units and check the behavior of the programmer.
O3: If the target system's ISP lines are loaded with something, use a buffer on these lines or reduce the speed manually in "config.ini"

Oh, today I have assembled 4 pieces of these programmers, each with a different memory card, with a 22uF capacitor for the card, with three different types of displays - all 4 started very nicely "from the kick" without any problems All I had to do was choose the contrast for everyone.

In the attachment (hopefully) all the files:
Before uploading a flash, please read the THIS LINK

Update 3 without errors in my opinion. Everything flashes nice. In addition, it selects programming speeds much better than version 2, so that even with osccal = FF everything runs without errors (several dozen entries of different memories / fusks / lb).
This batch tested by me on processors: m168, m328p, m2560.

piotrva wrote:

... so that even with osccal = FF everything runs smoothly

Hello
It depends on the specific processor model - both target and programming - I tested on tinny 2313 mega8 mega16 mega32 mega328 mega128 and even on a grandfather like 90s2313 although the latter is generally not fully supported - and why :)

At home, I set the oscall to F0 and the problems with programming with SCK = 2MHz disappeared. When it was on FF mega128 she could scream when reading and writing - but not always.

The change to F0 did not result in a noticeable change in the speed of uProg - as was the case with the change of the calibration disable bit - and it significantly improved the stability - especially at high SCK frequency and with loaded ISP lines.

Regards
M.

And what clock did you clock the tested processors? Because I actually tested the tiny2313 on 11.059200MHz quartz before and there were errors, but from what I remember, the uProg v1.2 was behaving the same on m644p with 16MHz quartz ... to measure how fast the uProga clock actually runs)

There the m128 ran on the internal 8MHz RC with a 4.85V power supply - so the RC itself could have a slightly lower value - apart from the fact that the RC with stability is also different ...
We came to the conclusion with a colleague mannequin that uProg should be clocked at 15.8MHz than 16.1 ... It's just more reliable :)

As for the frequency meter - I also think about it very long, but I can't find anything interesting

To make it easier with this OSCCAL for people who do not have a frequency meter, I did some tests on 4 different systems.
Power supply 3.3V.

OSCCAL value - operating frequency MHz

layout 1:
FF - 16.31
FB - 15.65
F7 - 15.30
EF - 14.35

layout 2:
FF - 16.22
FB - 15.74
F7 - 15.20
EF - 14.27

layout 3:
FF - 16.01
FB - 15.44
F7 - 15.01
EF - 14.11

layout 4:
FF - 17.48
FB - 16.87
F7 - 16.40
EF - 15.44

As you can see, the latter is a rocket - and the slingshot from the same series.
The safe value is EF (i.e. 255-16 = 239).
On another chip, it will only give you 14MHz, but it's not too bad :)

...

AHA - if the programmer displays the inscription "LICENSE" with the correct license placed on the card, check if the file has no hidden, system or read-only attributes - this is an additional protection.

...

Another thing ... If someone doesn't want to use this accelerated speed, they will have some trouble with slow-motion animations. Animations can be turned off in the options, but to get rid of greetings and goodbyes, simply remove the "goodbye" and "welcome" folders from the card. If we leave the file "welcome.bmp" on the card, it will only be displayed as in the previous version.

Well, then the auto programming mode (e.g. according to Piotr's idea) and it will be the perfect programmer. I hope it will fit (even at the expense of reading, it is a programmer, not a reader, after all )

J_Bravo wrote:

after all, it's a programmer, not a reader )

Okay - and how to verify what this programmer has uploaded and are there any errors?
Have a second chip - "reader"?

mannequin - well, the latter is a rocket ... 17.5MHz ... and on RC ... Satan is not a processor