Upload ASM file to ATmega8A

I’m sorry I’m new to micro controllers and programming but thought I would start with a simple project LED VU meter using a Atmel AVR ATmega8A. The author of the project is not responsive to questions but he provides a ASM file and a HEX file … problem is I don’t know what I need to upload the file or which file to upload to the micro controller here is the link to the project Sound level indicator with 2x 20 LED and peak indicator any help would be appreciated, please be gentle this is my first introduction to micro controllers … Thanks in advance :cry:


That is a very old project, and getting that code uploaded is not going to be easy. It appears that the project uses PonyProg, which requires a custom interface for uploading and might not run on anything newer than Windows XP. There’s no way of knowing whether or not that HEX file would be compatible with any of the current IDEs, but in any case I don’t see much point in trying to upload someone else’s HEX file for this project. The code would not be complex if rewritten for a higher-level language than assembly, and if you create it yourself then you will know how it works and you can adjust it to your own conditions. How far advanced with the hardware are you? If you were to implement the design using a development board such as a UNO then you can use the facilties of the IDE to generate the required upload command for a HEX file which might be worth a try. But I think you are pretty much on your own with a project that old.

There is a much newer version here. The difference is that the LEDs are not multiplexed, so it can’t support as many. But it could be upgraded to the full 40 of the original using that circuit diagram and some variation to the display code.


Hi All
Just had a look at that link. Interesting that the author has designated the LED values as having a value of ?db with 0VU as the reference. It would be interesting how he managed logarithms with an Atmega chip as used in Arduino. I don’t recall seeing any mention of logs in any Arduino text. One way would be to calculate the corresponding signal voltage for each step and then compare with the input voltage. I think that would work. It is unclear from his circuit whether he is applying audio (AC) directly to the ADC input or if it is rectified audio (DC). I think it would have to be rectified.

Then we get to a VU meter. This has some very specific criteria regarding the meter type, meter ballistics, impedance presented to a line (7500Ω) and even the rectifier type. To be any use for its intended purpose these criteria should be met. All AC meters actually are looking at the peak value. The conversion to RMS and the non linearity at the bottom end of the low voltage ranges are simply taken care of by the meter scale markings. Digital meters calculate this for display purposes. Quality professional digital “VU” meters take care of all this electronically. I think maybe some simple more economical units use the peak values with no thought for ballistics which I suppose is really OK if one only wants an indication and/or a cosmetic look. You have to be aware of what you are looking at if serious measurement use is anticipated.

Then come the actual levels. In the old days of 600Ω source and 600Ω load dbm was the accepted standard and 0VU equalled +4dbm. Along came low source impedance (40Ω) and high load impedance (10kΩ) which is good as it allows a distribution amp to happily drive the usual 8 outputs of 10kΩ. The use of dbm became redundant under these circumstances so this became dbu where 0dbu is 775mV (0.775V) irrespective of line impedance. Thus 0VU is now +4dbu. I might point out here that all these numbers refer to a sine wave RMS value.

I have always been involved in the 0VU = +4dbu variety but doing a bit of reading recently I find another one. The original type is now referred to as a “professional” device and the other a “domestic” device where 0VU is actually -10dbu. A whopping 14db difference. I will have to do a bit more research to find out if the different types are specified when advertised as “VU” meters.

Anyway they all look pretty and the barograph types have the ability to “trap” the high points which is difficult or near impossible with the moving coil type of meter.

I am not trying to kill off either variety but I thought this might generate some interest.
Cheers Bob


Hi Pete,

Assembly was the first programming language I learned and while it can give you a greater appreciation for what’s happening inside the silicon chip I wouldn’t recommend it as the easiest path to learn for beginners. I have huge respect for anyone who can learn in the lowest level languages but I think most people will benefit from the more widely available educational resources you get when learning with something like a micro:bit or Raspberry Pi Pico and using an interpreted language which can be run on various hardware without changes.

I think the ability to be able to “trap” the high point is the one singular time I’ve seen a digital meter trump an analog meter from an aesthetic standpoint.

Thanks, Jeff and Bob for your insights and helping to spot the tricky parts often overlooked when someone presents a finished project writeup.


Thanks all for your replies, ok seems I may have been a bit ambitious on this as a first project it may seem, I might tackle something maybe not so old … thankyou


If you are very new to programming etc. then you have a steep learning curve whatever way you go. I don’t see a problem tackling this project although most people start with something basic like flash one LED once a second. Whatever project you tackle the steps are the same (a bit simplified) -

  1. Create a source program (something readable by a human), either by writing it yourself (hard) or copying one (much easier).
  2. There are a zillion programing languages, and there are as many microprocessors. To convert the source code to something the microprocessor can use requires a compiler that understands the source and also knows which microprocessor is the target. The output of a compiler is called object code.
  3. But the compiler doesn’t put the object code into the microprocessor. This requires a programmer. The programmer reads the object code and generates the right signals to write the object code into the memory of the processor.

In general, object code for microprocessors is created as an Intel format .hex file. This is good, because it means that most compilers produce the same format object code (which is bit for bit what has to be written into the microprocessor memory). and most programmers read that format. So given a .hex file it is very likely any programmer will read it correctly and write it to the target microprocessor. [noting that a .hex file is specific to a microprocessor, and shouldn’t be written to a different one. It is unlikely to work].

For the VU meter, the author has already done steps 1 and 2 and produced a .hex file. So to put this program into a ATmega8A it is only necessary to find a programmer that will program it, from the .hex file. There are a few methods - the usual is a piece of software on a PC that drives a piece of hardware (usually via USB) that generates the right signals to program the microprocessor. I see online that people are using an Arduino board as the hardware to program the processor. But there will be a few ways to choose from. Programming a microprocessor from scratch does require the right signals to be presented in the right way, so the PC/hardware/microprocessor chain is the common way.

The Arduino method simplifies this by preprogramming the microprocessor to accept a program via a standard interface (e.g. usb) thereby avoiding the need for a special piece of hardware. The preprogrammed bit is referred to as a bootloader, it has to be programmed by the ‘from scratch’ method before being sold to the user. From then on, it supervises the loading of other programs but remains in the background. Microprocessors are being designed so that the bootloader cannot be overwritten accidentally.

Hope this helps.