Dear all,
I am programming the tiny via usbasp and avrdude, namely intel.hex file and it works well, fast... I would like to follow how many uploads I have done... how would somebody approach this with another tiny as a counter ?
Looking forward to any ideas how to approach this.
BR.
For any particular reason?
You would have to modify the tools and/or the embedded code to ensure that everything always maintained this - so if you ever used a different tool, or forgot to include the necessaries in the embedded code, or it didn't work, you'd lose everything.
Probably the easiest & most reliable method is just to stick a label or tie a tag on the board, and write on that.
Dear all,
I am programming the tiny via usbasp
BR.
I'd go for simplicity:
// program.cmd avrdude ... stuf ... echo %DATE% %TIME% >> prog.log
In DOS the >> operator means "append to existing file"
Here is an example of something similar in action:
D:\>type test.cmd @echo off echo hello echo %DATE% %TIME% >> prog.log D:\>test hello D:\>test hello D:\>test hello D:\>type prog.log 19/06/2020 13:48:45.69 19/06/2020 13:48:47.85 19/06/2020 13:48:49.72
Apart from the fact that this tells me I ran the command three times it also tells me WHEN I ran the command on each of those three occasions.
Used to be that avrdude supported that:
-y
Tells AVRDUDE to use the last four bytes of the connected parts’ EEPROM
memory to track the number of times the device has been erased. When this
option is used and the ‘-e’ flag is specified to generate a chip erase, the previous
counter will be saved before the chip erase, it is then incremented, and written
back after the erase cycle completes. Presumably, the device would only be
erased just before being programmed, and thus, this can be utilized to give an
indication of how many erase-rewrite cycles the part has undergone. Since the
FLASH memory can only endure a finite number of erase-rewrite cycles, one
can use this option to track when a part is nearing the limit. The typical limit
for Atmel AVR FLASH is 1000 cycles. Of course, if the application needs the
last four bytes of EEPROM memory, this option should not be used.
-Y cycles
Instructs AVRDUDE to initialize the erase-rewrite cycle counter residing at the
last four bytes of EEPROM memory to the specified value. If the application
needs the last four bytes of EEPROM memory, this option should not be used.I don't know which version was the last to support this.
You could recreate the functionality yourself with a wrapper script:
EDIT: A quick review of the older versions' documentation here:
http://download.savannah.gnu.org/releases/avrdude/
... shows that the feature was removed beginning with v6.0.1. The last version which supported it was v5.9. You could always roll back to v5.9, but you will lose the benefit of any new features which were added after that, and any bug fixes as well.
Note, the changelog doesn't actually show this as having been removed until 6.1, but I'm fairly confident that 5.9 was the last to feature it. Curiously, the usage message when invoking avrdude without any command line options remains right up until the current version 6.3, but it is not actually supported.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
You could recreate the functionality yourself with a wrapper script:
- read last four bytes of eeprom, interpret as 32-bit integer counter
- increment counter
- upload new code (erase-rewrite)
- write counter to last four bytes of eeprom
Why would you need 4 bytes for this, if the flash can only be written 10k times?
Wouldn't a two byte (uint16_t) be enough?
Why would you need 4 bytes for this, if the flash can only be written 10k times?
Wouldn't a two byte (uint16_t) be enough?
Mind you, 24bits is likely enough (16M+), but the feature was added to avrdude at a time when 24-bit integers were not really a thing in the world of GCC. If creating one's own wrapper script to accomplish the same thing, one could choose whichever width one wanted. However, for compatibility with older versions of avrdude, 32-bit would be needed. Otherwise, a 16-bit counter set to 0x0001 would read as 0xFFFF0001, or 4,294,901,761.
EDIT: typo
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
how would somebody approach this with another tiny as a counter ?
Well, lots of software approaches suggested above, but I have to admit my first thought was to do this with hardware...
Lots of ways to solve any problem...
You need to decide how you are going to read the data back from the micro that does the counting.
You could use an LCD, a graphics LCD, a 7-Seg LED display, a USART link to a PC running a terminal program (what a hassle for this project), or a Bluetooth module that shows the data on your cell phone, or a WiFi module that posts the data on a web page, or a piezo beeper that sends you the data in Morse Code, or, or, or...
Which of those you use will determine how many I/O pins you need, and how much memory you need.
As a general rule, it is wise to start with a big micro and develop your code.
If you then really want to port the project to a tiny micro, so be it.
If you are only making one or a couple of the project boards, then the differential cost for starting with a decent sized micro is very small compared to the hassle of being 90% done with your project and running out of memory or I/O pins.
Developing your project on an Arduino Nano platform might be a good approach.
It has lots of memory and I/O pins, plus the power supply by-pass caps, USB interface, an LED, a reset PB switch, etc., all in a very small form factor, and all for only several USD.
You can use any programming language and environment you wish to use.
My thought was to put a micro, (or Nano), on a small PCB with an incoming signal programming header and an outgoing, (pass through), programming header.
The micro watches the Reset\ pin, (through a resistive divider, if needed), to monitor the Reset\ line for the initiation of programming signal.
Count those and keep the number in the micro's EEPROM.
If necessary one could watch another programming pin to see when the programming episode had finished, so as to more easily identify when to increment the counter.
The project is basically a "man-in-the-middle" monitoring the ISP signal (s) and incrementing the counter as needed.
There are certainly several details to work out, making it a worthwhile undertaking from a learning perspective.
How to detect the start of a new programming episode?
How to display the data?
How to store the data in the micro's EEPROM?
How to power the project, (From the programmer, from the target, with its own power supply)?
How to reset the counter, is desired?
How to lay out the incoming and outgoing ISP headers, correctly.
Etc.
JC
Edit: Typo
paper and pencil.
Thank you, but I am preparing the individual programming setup where I will keep the log of programming.
BR
Yeah, this looks like one of the best ideas, now I have to work on how to read/program/flash the USBasp via the Arduino.
BTW Has anyone done that?
BR.
Thanks, thats all good, but I am not going to have the access to the computer, but rather only to the programming device that I am building, hence the option of counting, etc.
BR.
Thanks, this is very optimistic idea, I like it, what I need to think now is how to write "this" information to the tiny belong that will be keeping the log of counting?
I guess this could be done via the command of SPI, namely the Slave Select and have two tinies in parallel?.
Has any of you done that yet, has any experiences with having more than one uC on SPI ?
BR.
OOOUUUU, this is a lot of "do", but you are right, it is important how to do from start to end.
Indeed, the question of HW is important, so far, my idea is to light the LED once certain number is reached... eg. RED.
Why, am I looking at AT Tiny, because I have few left and I do not need more to count the number of programming and turn the RED led on...
BUT, can you say more about this:
My thought was to put a micro, (or Nano), on a small PCB with an incoming signal programming header and an outgoing, (pass through), programming header.
The micro watches the Reset\ pin, (through a resistive divider, if needed), to monitor the Reset\ line for the initiation of programming signal.
Count those and keep the number in the micro's EEPROM.
If necessary one could watch another programming pin to see when the programming episode had finished, so as to more easily identify when to increment the counter.
The project is basically a "man-in-the-middle" monitoring the ISP signal (s) and incrementing the counter as needed.
If I got you right, you are referring to the "reset pin" which could be used to read the number of programming? Indeed, this does not provide me the information whether the programming was successful, or does it? In this case I am wondering, is there a keyword or code command, something must be, that acknowledges that proper programming has been achieved, can that part of writing/reading, be read by the 2nd tiny? Indeed, in this case, I could distinguish between the number of tries and number of programmed uCs? Right.
BR.
It needs to b e automatic, not human "labour" involved...
BR
Yeah, this looks like one of the best ideas, now I have to work on how to read/program/flash the USBasp via the Arduino.
USBASP is an open source project based on VUSB stack which been around for about 15 years so you can easily find "how it works".
Too many project that people had done with it.
But you don't have to bother about "how to read/program/flash" but just add a variable as counter and save it to eeprom at every succesfull programming.
And (only) if you need it you can dump that eeprom data thru UART (or else as you wish) via one of the USBASP command (eg: read SCK speed?).
So you don't need other chips to do it.
I'm not Arduino fans so don't ask me how to do it with Arduino. It can be easily done with AVR Studio.
BTW Has anyone done that?
Mostly nowadays USB moduls with chips that don't have USB peripheral is using VUSB stack.
So as I said too many people had done it.
Smith
Hello all,
thank you again for your input, I have managed to put something together and it works perfectly.
In general,I am counting the number of RST when high, respectively the number of target uploads, which is what I wanted.
Eg. the RST is pulled high when the SPI is used to upload the program on the uC. I am reading this with the tiny and one of its pins. I have used the debounce to filter the noise, however, I am not sure, if it is necessary ... either way, when prototyping with the switch, it was essential...
So far it looks the USBasp can power the tiny (used only for counting the number of programming) along the programing of the target, but, was thinking to put the tiny to sleep while there is no programming yet, wake it up just to count the RST, then go back to sleep, and allow the USBasp to finish the upload while the tiny is asleep. Let me know what do you think? Which vector would you use in ISR? PCINT0,
? Would it be smart to add counting++ in the ISR or in main loop. And should the be awaken in ISR or before? BTW I am storing the number of counting in the E2prom...
looking forward to your comments, etc!
Hello !
OK the question of power is out , sleeping not require usb (2.0) provides much more current thaN needed.
But, this time I have figured that RST is not really the best way of looking at this, namely because it does not really work properly. For example, this solution also considers when I am only detecting the uC and accordingly it counts as if the programming was executed, but it was not. So, I guess I need to dig into the SPI protocol more and detect actual programming logic...
Anyone has an idea?
Best.
provides much more current thaN needed.
Anyone has an idea?
