1
\$\begingroup\$

I'm creating a project that uses I2C serial communication in assembler and I'm having some issues transmitting data and receiving back so I thought I should somehow debug the whole program, besides oscilloscope and maybe proteus I thought if I knew the flow of the program execution I might know where the problem is, if ack is set or noack, first thing that came to mind is a delay and a led after each instruction is done, is this a good approach or do you suggest something different, if it is a good approach give e some ideas and how much of the delay are you proposing? Thank you.

\$\endgroup\$
2
\$\begingroup\$

It's certainly true that toggling LEDs is a time-honored method of debugging embedded systems.

Sometimes it's useful to put your oscilloscope on the LED(s) to see fast activity, but it's also possible to put delays in the program to make the activity visible directly — but only if your sure that the delay won't materially affect whatever else is going on.

"A delay and a LED" after every instruction sounds excessive (how many LEDs do you have?). Instead, focus on the key decision points in the algorithm and use the LEDs to show which way they went. For example, if your I2C master controller has a number of different "states", use the LEDs to show which state it is in at any given moment.

\$\endgroup\$
1
  • \$\begingroup\$ It doesn't matter how many LEDs are because i can reuse them, set and clear, and that's a good idea about decision points that's what i thought after, thank you. \$\endgroup\$ – Çlirim Murati Mar 20 '19 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.