AVR Freaks

Well all software design whether it be Asm or C or C++ or something else should start in the same place - some kind of flow diagram, state transition chart or similar which says. "It starts in this state", "I expect this, this or this to happen" (perhaps button presses, perhaps something else?), "As a result I now get to here". "While I'm here, this or that could happen", "That gets me to here or here". 

When you have the sequence of operation (which, with enough detail might also act as the user manual for the end user!) then you have a plan. It's then just a case of how you recognise the input events (buttons, sensors, water levels, voltage readings, whatever) and how you then use that information to move to the next place. Obviously somewhere in your particular design you are going to have to have some kind of sensing as to exactly many capsules you have seen or that you can detect.

Also consider how you are going to handle things if this is turned off at the wall. At next turn on can you still sense how many capsules are there? If not then you need to store away the count as it goes up/down so that if power is interrupted you can resume from where you last left off (EEPROM is possibly a good place to hold this kind of "non volatile" data such as capsule count)

Bottom line: it's all about clear design (it always is).

As long as you design clearly then the actual implementation should be trivial.

Seems button 6 has two different purposes? 

Or you don't yet have a clear understanding of the problem to be solved.

Spend some time (with your teacher if needed) to clear up what is needed.

The rest of the advise above is very good!  

Come back and ask more questions if you get stuck.

Jim

AVR Instruction Set Manual

Maybe it's a little too heavy on information for a newbie, but it should contain any information you would need on interesting assembler instructions!

For experienced programmers the best way to write a program is often to start with plain old pen and paper and figure out exactly what has to be done and how to do it before even starting with writing code.

But when learning all this stuff this is almost impossible because you do not have the background yet to know in which direction to take a design to make it a succes.

There are so many things you have to learn all at the same time:

- ASM instruction.

- How to use asm instructions effectively.

- How to divide a big project into smaller pieces.

- State machines, programming structures.

- How to use the tools.

Therefore I agree with the above (Meslopmp #2 and others).

Start with something simple, a sub project that is a piece of the bigger part.

Whenever buttons are involved, debouncing them is an important, but non trivial task.

Just writing an asm program that toggles a led when a button is pressed seems a simple task, but is already a part of your program.

Once you have the button working, you can exchange the led with another part of your coffee machine.

And then you can ad-hoc add functions and tinker with it.

But don't only add stuff.

Refactoring is also an important aspect of software development.

Once you gain more experience you will notice that you have done things in a weird way, or that old code does not work well with functions you want to add.

Don't be afraid to re-write the old code to make parts fit together better.

When I was learning asm a long time ago I made a cheat sheet. It had all asm instructions on a single sheet of paper with a single line explanation of what the instruction did and side effects.

Making that cheat sheet was a whole day of work, but  I learned a lot from making it.

After that day I had a reasonable understanding of what ASM instructions were available, and the sheet helped with filling in details during software development.