Shop OBEX P1 Docs P2 Docs Learn Events
Weird problem. MAX7219 & Propeller — Parallax Forums

Weird problem. MAX7219 & Propeller

TCTC Posts: 1,019
edited 2013-12-05 16:59 in Propeller 1
Hello all,
I have a weird one that I cannot figure out. I am trying to get a MAX7219 to work with the prop. It works. Somewhat.
I have an LED hooked to pin 23 just to show where in the program it is at. The MAX7219 only has 3 displays, and all of them count from 0-9 as fast as they can.
This is just the start of the program, and I need to find out why it is doing this so I can continue with it.

I have included my code.

What happens
1) I turn on the power supply
2) about 2 seconds the LED that is connected to pin 23 will light up
3) Then after about 18 – 20 seconds it will start counting and the LED will flash and work like it should
4) After about 30 – 32 seconds it will freeze. The displays will stop, stay on and show numbers, and the LED will be on or off ( like the prop stopped in the middle of doing something)
5) Then after 30 – 32 seconds it will start working again

One, I need to find out why it takes so long to go from lighting up the LED, and starting the display
and two, I need to find out why it will stop, when it should keep running forever.

Thanks
TC
zip
zip
MAX7219_demo.zip
1K

Comments

  • TCTC Posts: 1,019
    edited 2013-12-05 11:20
    I am so sorry everyone, I feel this question got lost since I posted it so late in the evening.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-12-05 13:37
    I have a couple MAX7219 on their way so if you ask this question next week I might have a clue of how to help.

    That said I do have some suggestions.

    Add some delays. I wonder if there needs to be a bit of time between calls to the '7219 object.

    What's your power supply like. Could the LEDs be causing a reset?

    And finally the sure fire way to find you problem. Add debug statements. Lots of them.

    When I'm having trouble with code I just have the program tell me which method it's in, what the values of variables are and so forth. Usually with enough information coming out of the program I can find where something isn't happening as expected.
  • LawsonLawson Posts: 870
    edited 2013-12-05 13:55
    TC wrote: »
    4) After about 30 – 32 seconds it will freeze. The displays will stop, stay on and show numbers, and the LED will be on or off ( like the prop stopped in the middle of doing something)
    5) Then after 30 – 32 seconds it will start working again

    Haven't read your code, but that sounds exactly like an issue with CNT rollover. Either you're occasionally waiting for a CNT value that's already passed, or you are doing something like "CNT_target > CNT" in the code. You should always calculate the difference between CNT and your CNT_target first before doing a comparison. (i.e use "(CNT_target - CNT) > 0" to avoid rollover issues.)

    Marty
  • kwinnkwinn Posts: 8,697
    edited 2013-12-05 13:56
    I wonder if it could have something to do with your waitcnt statements. Try replacing the calculation (clkfreq / 100000 * 10) with an actual value.
  • TCTC Posts: 1,019
    edited 2013-12-05 14:03
    Duane Degn wrote: »
    Add some delays. I wonder if there needs to be a bit of time between calls to the '7219 object.

    What's your power supply like. Could the LEDs be causing a reset?

    And finally the sure fire way to find you problem. Add debug statements. Lots of them.

    When I'm having trouble with code I just have the program tell me which method it's in, what the values of variables are and so forth. Usually with enough information coming out of the program I can find where something isn't happening as expected.

    I will have to try adding some delay to it. But wouldnt the problem be there all the time? not at the start, and every 20 seconds?

    I tried two power supplies, first one is a computer power supply where both the +5V, and +3.3V have there own ground. Then I tried my power supply that I have had for years that has never gave me any problems.

    I did a debugging, and every time the PROP would stop, so would the debug. then continue with where it left off at.

    That is why I am at a loss.
  • TCTC Posts: 1,019
    edited 2013-12-05 14:06
    Lawson wrote: »
    Haven't read your code, but that sounds exactly like an issue with CNT rollover. Either you're occasionally waiting for a CNT value that's already passed, or you are doing something like "CNT_target > CNT" in the code. You should always calculate the difference between CNT and your CNT_target first before doing a comparison. (i.e use "(CNT_target - CNT) > 0" to avoid rollover issues.)

    Marty

    The only CNT i am using is a delay for clocking the data, and to load the MAX
    waitcnt(cnt+((clkfreq / 100000 * 10) - 4296) #> 381)
  • TCTC Posts: 1,019
    edited 2013-12-05 14:09
    kwinn wrote: »
    I wonder if it could have something to do with your waitcnt statements. Try replacing the calculation (clkfreq / 100000 * 10) with an actual value.

    I got the calculation from "SPI_spin.spin" ( Beau Schwabe (Parallax) ) I just took out the parts i didnt need. Im still trying to fully understand how the delay works, what would you recommend?
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-12-05 14:19
    TC wrote: »
    I got the calculation from "SPI_spin.spin" ( Beau Schwabe (Parallax) ) I just took out the parts i didnt need. Im still trying to fully understand how the delay works, what would you recommend?

    Ah, I had incorrectly assumed you got the object from the OBEX. Sorry. Since the driver is untested, there even more ways possible to mess it up. :smile:

    No one has used the Prop with the '7219 (and shared the code)? That's surprising.
  • kwinnkwinn Posts: 8,697
    edited 2013-12-05 14:22
    Try it without subtracting 4296.
  • TCTC Posts: 1,019
    edited 2013-12-05 14:27
    Duane Degn wrote: »
    Ah, I had incorrectly assumed you got the object from the OBEX. Sorry. Since the driver is untested, there even more ways possible to mess it up. :smile:

    No one has used the Prop with the '7219 (and shared the code)? That's surprising.

    Mess it up?!?! I know I will mess it up, that is half the fun.

    And I agree with you. A 7219 is a great chip, once I am done and it fully works, I am going to post it.
  • kwinnkwinn Posts: 8,697
    edited 2013-12-05 14:28
    The end result of the calculation should be 8000 - 4296 which is 3704 clock cycles. If the previous suggestion does not work try a delay of 8,000 and 20,000.
  • TCTC Posts: 1,019
    edited 2013-12-05 14:40
    kwinn wrote: »
    The end result of the calculation should be 8000 - 4296 which is 3704 clock cycles. If the previous suggestion does not work try a delay of 8,000 and 20,000.

    THAT DID IT!!!! :smile: Thank you very much.

    Now I have a question, Why was that screwing it up? and is there a way for someone with very little knowledge of timing, to understand what is going on?
  • LawsonLawson Posts: 870
    edited 2013-12-05 15:56
    TC wrote: »
    The only CNT i am using is a delay for clocking the data, and to load the MAX
    waitcnt(cnt+((clkfreq / 100000 * 10) - 4296) #> 381)

    There's your problem, "+" is a higher priority operation than "#>" so it evaluates first. So that statement ends up being as. 
    (cnt + ((clkfreq/10000) - 4296)) #> 381
    That does a limit minimum on a target CNT value. Half the time you'll be waiting for CNT to equal 381, hence the 32 second delay. i.e. when CNT is a two's-compliment negative number. CNT loops through all numbers between the POSX and NEGX constants.

    Marty
  • TCTC Posts: 1,019
    edited 2013-12-05 16:59
    Lawson wrote: »
    There's your problem, "+" is a higher priority operation than "#>" so it evaluates first. So that statement ends up being as. 
    (cnt + ((clkfreq/10000) - 4296)) #> 381
    That does a limit minimum on a target CNT value. Half the time you'll be waiting for CNT to equal 381, hence the 32 second delay. i.e. when CNT is a two's-compliment negative number. CNT loops through all numbers between the POSX and NEGX constants.

    Marty

    Oh, now I get it!!! That makes sense now. Thank You
Sign In or Register to comment.