Unable to find fault in my program

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everyone,

 

I'm currently taking a course in university for microcontrollers. We have been provided with the brief for the final project for the course. In short, we are required to use an Arduino Uno with ATmega328P to interface with a DHT11 temperature and humidity sensor. The information from the DHT11 sensor should be displayed on three seven segment displays. At this point in time, my program is able to accept any number between 0 and 99 and display it on two of the three seven segment displays.

 

My code works like this:

1. Assign a value between 0 and 99 to the R16 (this register will eventually receive the value from the DHT11 sensor. But for now I just enter a value)

2. Take the value in R16 and convert it to a binary coded decimal. Store this result in R0.

3. Take the upper nibble of R0 and use a lookup table to find the correct bit pattern to display the appropriate value on the seven segment display. Store this result in R2.

4. Perform the same operations as step three on the lower nibble in R0 and store the result in R3.

5. Use the values in R2 and R3 to turn on the seven segment displays.

 

Currently, I have three separate programs. The first program consists of steps 1 and 2. The second program consists of steps 3 and 4. The final program runs step 5.

 

If I feed in a number (say 49) into the first program. It returns the correct BCD value (in this example, its 0b01001001). If I take this result and feed it into program two, I also receive the correct bit patterns (again, for this example I would receive 0b11001100 in R2 and 0b11011110 in R3. The bit pattern in R2 corresponds to the pins on the mcu that display four and likewise the bit pattern in R3 would display nine.) If I take the results in R2 and R3 and feed them into my third program and load it onto the mcu, the seven segment displays show the correct result (49).

 

Until now, everything is functioning as desired.

 

Now for my issue:

I've merged programs two and three into one program. If I take a result from program one and feed it into this new program, my seven segment displays still show the correct answer. If I take this new program and combine it with program one and run this program in Atmel Studio, I still read the correct bit pattern in the port registers. However, if I load this program onto my mcu and provide it with a value (lets use 49 again), the seven segment displays simply show an unintelligible result. 

 

Before I posted this question, I went through my code in the debugger and checked that all the registers were being modified appropriately and not unintentionally. At the end of the debug, the port registers have the correct value. However, the result I get on the seven segment display is not in agreement with the port registers.

 

I've also simulated my program on AVR Simulator IDE and it also provides the correct result.

 

I'm a bit lost. Could someone please point me in the correct direction. 

 

P.S. I've tried to avoid adding code to my post as probably quite a few of my classmates are looking for answers here as well laugh

 

Kind regards,

Nick.

 

 

EDIT (As per Jim's comment):

 

I forgot to mention that the seven segment displays are charlieplexed multiplexed (apologies for the confusion. I still have lots to learn cool

A schematic of the circuit showing how the seven segment displays are connected to the microcontroller.

Last Edited: Wed. Mar 25, 2020 - 02:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Welcome to AVRFreaks!

 

Sounds like your debugging approach is right on, so the ports with the displays have the bit pattern your looking for, but its not displaying on the LED's correctly...

Can you post your schematic of how you have connected your LED's to the UNO?  (hint: use the mountain range icon in the edit menu above to post pictures)

Or if you do not have a schematic, post a clear picture of your setup.  Some one may spot something.

 

At this point you need to troubleshoot why the "correct" bit pattern is not producing the expected display.

 

Some things to check, how are you driving the 14 LED's (2 x 7 segment LED)? Directly from the port pins (with series current limiting resistors (I hope)?

Or are you "multiplexing" the LED's?

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

N1ck wrote:

I've also simulated my program on AVR Simulator IDE and it also provides the correct result.

 

I'm a bit lost.

If you see the right result in the Sim but it doesn't work in the electronics I would suspect the 7seg wiring.

 

Probably time to show schematics and code I think !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim,

 

Thank you very much for your reply.

 

I have updated the post to include my schematic. 

 

Nick.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson,

 

Thanks for the advice. I will check the connections. 

 

I'm unfortunately apprehensive to upload my code because I fear someone in my course may copy my solution. This would place me in a rather difficult predicament if the lecturer feels that plagiarism has occurred.

I understand that not providing code makes finding a solution rather difficult. Is there any particular part that I could provide that would assist you?

 

Nick.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

N1ck (Edit) wrote:

I forgot to mention that the seven segment displays are charlieplexed.

 

Holy mother of God - nothing like making things easy for yourself then ! (and this is NOTHING like making things easy)

 

(obviously the issue with something like Charlieplexing is that you "cannot stop". So you can make that work standalone but if you then try to add "other stuff" there's every chance you may interfere. So have you put the charlieplexing stuff on a timer interrupt or something so it carries on regardless?)

Last Edited: Wed. Mar 25, 2020 - 02:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

N1ck wrote:
I went through my code in the debugger and checked that all the registers were being modified appropriately and not unintentionally.

Is that a debugger in the real hardware ?

 

If so, use it to trace the data going through your code, watch the LEDs change as you step, etc.

 

If you don't have a real debugger, then instrument your code with print outputs to the UART.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

How does one charlieplex a 7 seg display with a common A/K?

 

Jim

Edit: that is NOT charlieplexed, that is multiplexed.

 

 

 

 

 

 

Last Edited: Wed. Mar 25, 2020 - 02:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

How does one charlieplex a 7 seg display with a common A/K?

 

Jim

Edit: that is NOT charlieplexed, that is multiplexed.

 

 

 

Thanks Jim. It appears that I'm definitely wrong in saying charlieplexing. I have updated the initial post :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Even in multiplexed you presumably have some kind of "round robin" scheme where you output the data for each digit in its own time frame and enable that particular one to display. This again is a process that cannot stop. So in the failing code are you sure the display cycling thing is continuing uninterrupted? Are you using a timer interrupt or something like that to do regular/repeated digit updates?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

N1ck (Edit) wrote:

I forgot to mention that the seven segment displays are charlieplexed.

 

Holy mother of God - nothing like making things easy for yourself then ! (and this is NOTHING like making things easy)

 

(obviously the issue with something like Charlieplexing is that you "cannot stop". So you can make that work standalone but if you then try to add "other stuff" there's every chance you may interfere. So have you put the charlieplexing stuff on a timer interrupt or something so it carries on regardless?)

 

I've unfortunately made a mistake, I should have rather said that I multiplexed the displays.
I do think that your point is valid. I will definitely try adding an interrupt to the multiplex procedure and see if that hopefully fixes it. 

awneil wrote:

N1ck wrote:
I went through my code in the debugger and checked that all the registers were being modified appropriately and not unintentionally.

Is that a debugger in the real hardware ?

 

If so, use it to trace the data going through your code, watch the LEDs change as you step, etc.

 

If you don't have a real debugger, then instrument your code with print outputs to the UART.

 

Hi awneil,

 

Thank you for your reply.

I should have said that I used the simulator in Atmel Studio. I'm sadly not familiar with UART but I will see what I can do to use it.

 

Nick.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I feel that I need to add some context. This project is due in May and I've started it early. We were being taught interrupts and timers but the whole covid19 situation sadly unfolded.

I currently just use the code below to pause for (hopefully a long enough duration so that everything is displayed properly)


delay:                   
    LDI     R18, 120    
delay1:
    LDI     R19, 20      
delay2:
    DEC     R19          
    NOP                  
    BRNE    delay2       

    DEC     R18          
    BRNE    delay1      
RET

I understand that this is bad practice because you only really know how long you need to wait at runtime. I'm guessing that some sort of an interruption (like you said) is occuring?

Upon reflection, it appears that this may be my issue?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The issue will be if you are expecting to keep the display refreshed at the same time you try to do "other stuff". That is the reason you typically use interrupts so you can have something that "ticks away" at its own rate and just keeps on doing the same job (driving the display) while other code gets on and does "other stuff". Sure that "other stuff" is being regularly interrupted so it takes longer than it might otherwise but the key thing is that, like the Duracell bunny, the display cycle just keeps on running.

 

Without seeing the code it's just conjecture but often when you have "two programs" (both of which "need the CPU") then you try to merge their operation it's often the case that the operation of one (or even both) is upset by not being able to do things as regularly as it needs and the usual solution to that is "interrupts" so the regular/time critical stuff can get its fair share of the CPU time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much!! This makes so much sense. I will definitely go and finish learning about interrupts and then implement this in my code. Once I'm done with the implementation, I will report back :-D