Go Down

Topic: (not a ) switch case question (anymore...) (Read 3326 times) previous topic - next topic

AWOL

No, "0b" is the C binary constant prefix, just as "0x" is the hex constant prefix, and "0" is the octal constant prefix

0b00000100 = 810 = 0x08 = 010 

"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

PeterH

I notice that the definitions of the number representations start at '1'. I guess that this is because none of your dice have a zero on them. :) Nevertheless, it would make your display code more reusable (and exclude a possible source of off-by-one errors) if you started the numbers from '0'. This would enable you to use the number directly as an index into the array.
I only provide help via the forum - please do not contact me for private consultancy.

Neight


No, "0b" is the C binary constant prefix, just as "0x" is the hex constant prefix, and "0" is the octal constant prefix

0b00000100 = 810 = 0x08 = 010 




lol, what I know about C, or writing code in general, wouldn't even be a decent size drop in the overall bucket...

I very much appreciate you pointing me in the correct direction though, and I am off to do some research and learn a bit more about how and why your suggestion would work.

I did attempt to change my code as suggested, but I must be missing something somewhere.  Now when I shake the breadboard to "roll the dice" I only get the very top-middle segment to light up, so I guess its time to actually go through some C tutorials and learn more about the language so I can use it properly.

Thank you so much for your help and guidance though!
my lack of experience in the subject sort of makes communicating a bit tougher, and you have been very patient to follow along and explain things to me :)
I do understand the direction you are pointing me in, just not the "how" and "why" of it yet.  I will get there
absence of proof is not proof of absence

Neight


I notice that the definitions of the number representations start at '1'. I guess that this is because none of your dice have a zero on them. :) Nevertheless, it would make your display code more reusable (and exclude a possible source of off-by-one errors) if you started the numbers from '0'. This would enable you to use the number directly as an index into the array.


actually, I ran into that very problem and this is how I fixed it.  I originally had "0" at the top of the list, but that was displaying the dice result from 0-Xdice mode instead of 1-Xdice mode.  I put "0" at the end, which screwed up my code to display which dice mode you were in, by saying "d1" instead of "d2" or "d9" instead of "d0." (for d10).  To fix that, I used the "sevenSegWrite(dValue[state] - 1)" and everything worked out just right.
I could have just of easily used sevenSegWrite(Result + 1) but I didn't see that at the time.  Once I had it working, I was fairly timid to try and change it again.

Thank you for the suggestion though!
Very much appreciated, and I agree, starting at 0 and adding 1 to the result would have made some other parts of the code easier to write for accessing the array. 
I am just happy to have the thing working at this point.  I feel like I have come a long way in a very short time, though it is clear I have a long way to go to be proficient in the least.
absence of proof is not proof of absence

Jimmy60

I just skimmed your code and one thing I see is that it doesn't appear that you have a way to show the mode without changing it. If you were playing a game that used different sided dies then it would be nice to see the mode before shaking.

My approach to this would be to use two push buttons. One to display and one to change modes. I would have it display the mode as long as one button was held down. I'd also make it so that you have to display the mode before you can change it. So you'd hold down that button to display the mode then use the other button to change through the modes. This would also make accidentally changing modes more difficult.

Neight

you just solved my last problem!
I was trying to work out a way to keep track of the dice mode, but I only have two pins left.  using a push button is perfect, and comes with more options than a few regular LEDs to indicate level or something else that I might have thought up.
Great idea

Thanks for the suggestion!
much more simple than what I was thinking!
absence of proof is not proof of absence

PeterH


actually, I ran into that very problem and this is how I fixed it.  I originally had "0" at the top of the list, but that was displaying the dice result from 0-Xdice mode instead of 1-Xdice mode.  I put "0" at the end, which screwed up my code to display which dice mode you were in, by saying "d1" instead of "d2" or "d9" instead of "d0." (for d10).  To fix that, I used the "sevenSegWrite(dValue[state] - 1)" and everything worked out just right.
I could have just of easily used sevenSegWrite(Result + 1) but I didn't see that at the time.  Once I had it working, I was fairly timid to try and change it again.


I suspect the problem you're describing is the result of code that does not separate out the abstraction of the dice from the abstraction of the display.

I suggest you should aim to implement a function that displays a given number, and call it with an argument which contains the number generated from your virtual 'dice'. The display logic should not depend at all on which dice you're using or how you 'roll' them or anything like that - it should just receive a number to be displayed.

In your current solution you will support the display of values in the range 1 .. 20 plus blank. Since these numbers correspond to positions 0 .. 20 in the display array, you would need to subtract one from the value when you access the array. My suggestion was that you should put the definition for '0' at the front of the array, even though you never expect to need to display a zero in this application, so that you can use the number directly as an index into the array without any need for offsetting it. This also means that the display function would handle zero correctly, which (IMO) makes it safer and easier to reuse for other projects.
I only provide help via the forum - please do not contact me for private consultancy.

Neight

@PeterH

I am sure you are correct.
I haven't wrote my own function without working directly from an example before, but I am sure with a little digging, I can figure it out.

I actually have some idea of how I would do that, though it will take some testing to find out.
Thank you for the suggestion!
This is my goal, to figure out how to get my idea working on my own, then get help from others to learn where I can make it better.
many more things that get talked about on this forum are making sense, and I always enjoy the process!
absence of proof is not proof of absence

Neight

Ok, I seem to have hit a wall today...

I have re-designed my digital dice project.
I am now trying to use two 7 segment displays to show the dice roll results.
I am trying to multiplex them without external ICs.
they are both common cathode displays, and I have the segments for both wired together, and the cathodes wired through 2n2222a transistors to perform the multiplexing.
I have the segments mapped out correctly, and have already tested that.
I am having trouble getting the results to display.
basically, I don't have a clue how to take the double digit result of the random function, and correctly display them on the two displays.

Looking for any guidance or links that would show me how to do this.  There are loads of tutorials and examples of how to use the 7seg, and how to multiplex them, but they all seem to have some pre-packaged message to scroll or display, and not how to display numbers that the arduino comes up with internally.

sorry if my description is unclear, and if anyone has any questions on my project, I am more than happy to answer them.
absence of proof is not proof of absence

PeterH

If you're using multiplexing then each LED is controlled by a combination of output pin states. When your dice handling code provides a value for display, you need to translate that into a set of LEDs that need to be illuminated. One way to do that is to use the display number as an index into an array of ints, and have each bit of the int associated with a given LED. This lets you do a simple lookup to get from the dice value to the bit-mask telling you which LEDs need to be on.

Then you need some code that runs repeatedly at a fairly short interval, which flashes each of the 'on' segments in turn by switching the appropriate combination of output pins to turn it on and then off. The length of time that each LED is flashed for, and the interval between flashes, needs to be consistent for all LEDs and for all displayed numbers.
I only provide help via the forum - please do not contact me for private consultancy.

dhenry

Quote
I don't have a clue how to take the double digit result of the random function, and correctly display them on the two displays.


1) Once a random number is generated, load the corresponding segment information into a two-byte buffer called LRAM[2]: LRAM[0] is the tenth digit and LRAM[1] is the single digit.
2) in your display function, keep track of the current digit to be displayed (using a digit counter)
3) (optional) turn off all digits.
4) send the segment information of the current digit to the segments.
5) turn on the current digit.
6) advance the digit counter to the next digit.
7) exit the display function.

All you need to do is to implement the above steps with your code.

Once you have that done, write a timer isr and call the display function from the timer isr periodically.

With that approach, the displaying is done in the background, without user intervention (other than loading up the segment information into the buffer).



Neight

ok, couple of quick (hopefully) easy questions.

should I write the array to define the answer as 0-9 or as 0-20.
My highest dice value will be 20, but that can be broken down into 2 and 0 on the display.
I am not sure if I need to write a byte value for 10-20, and if so, how would I do that.

It seems to me it would be easier to write the array 0-9 and call up the proper byte for each digit on each display.

At this point, I am absolutely convinced I am over-thinking this issue, but I have looked at so many different ways of handling a two digit 7 segment display, I think I am getting lost in the options.

second, what exactly is a timing isr?
I know that is probably a dumb question, but it is a term I haven't run into yet, so I am just trying to make sure I look up the right thing :)

absence of proof is not proof of absence

dhenry

Quote
should I write the array to define the answer as 0-9 or as 0-20.


Doesn't matter.

Quote
At this point, I am absolutely convinced I am over-thinking this issue,


More importantly, you are under-doing it: sit in front of your arduino / ide and start coding one step at a time.

Neight

Quote

Quote
At this point, I am absolutely convinced I am over-thinking this issue,


More importantly, you are under-doing it: sit in front of your arduino / ide and start coding one step at a time.



Thanks for the reply!
actually, I have tried writing this up several ways, but haven't even been able to get both displays to work yet.
I have had all kinds of odd results (the right character showing up on the wrong display, and only half brightness, both characters showing on one display one after the other, things like that, but most of the time, I get no result.)

I have been scribbling code on paper all day trying to get this straight in my head.  Not sure why I am having so much trouble honestly.  everything else I have tried on the arduino has ended up being pretty cut and dry, and worked.  At most I have maybe had to scratch my head for an hour or so, until I stumbled on a sample code that I could use correctly to do the job.
I have even had this project working perfectly with a single seven segment display, but wanted to expand it as a challenge to myself, and to learn about multiplexing.
I figured all I would have to do is merge my working code with some example multiplexing code and viola, working digital dice that could be used in a multitude of dice games.
as a matter of fact, once I had this working with my basic setup, I am even looking to add a few more modes, that would allow each display to show results for a single die, allowing for a person to roll two dice at once, and skip having to see one result for three seconds, then roll again to get a second result.

For the overall project I have a long way to go, but I am trying to teach myself the code step by step and increase the complexity as I get one part working.

I really appreciate the advice and patients I am getting with this.  I have only been working with electronics for less than two years, and only learned how to use ICs about 6 months ago (555 timer aside, it's hard to learn electronics without running into some good 555 timer projects)
I have had my Arduino for maybe two weeks, and have learned more on how to use it in the last two weeks than I have basic electronics in the last two years.
Much that is discussed on forums such as this one are a bit over my head with the abbreviations and terms I am not familiar with, and I usually just look things up as I run into new information.  Usually this process works well for me, but today has been one of those "can't quick wrap my head around it" kind of days...

I am sure I will get it, it will just take some time, and a little tweaking of my current learning curve :P
absence of proof is not proof of absence

PeterH

#29
Jan 13, 2013, 04:54 pm Last Edit: Jan 13, 2013, 04:56 pm by PeterH Reason: 1

should I write the array to define the answer as 0-9 or as 0-20.
My highest dice value will be 20, but that can be broken down into 2 and 0 on the display.
I am not sure if I need to write a byte value for 10-20, and if so, how would I do that.

It seems to me it would be easier to write the array 0-9 and call up the proper byte for each digit on each display.


Either way could be made to work.

If you have got your LEDs arranged in a single multiplexed matrix then the simplest way to get it working would be to conceptually treat all the segments in both digits  as being part of a single display which can display any number from "00" to "20" (or however far you want to go).

If you ever wanted to be able to change the physical arrangement of LED segments (and the wiring to the Arduino, and Arduino pin-outs etc), vary the number of digits you can display, support multiple sets of multiplexed outputs then you could abstract out the concept of an LED segment display than can display a single digit, and the logic used to control each segment via the multiplexed output. This would reduce the amount of code you needed to rewrite when you do similar types of thing in other projects. However, I suggest that, at least at first, you start with the simplest approach and get that working. Unless you plan to implement a lot of different projects using this type of hardware I would doubt that it is worth your time to generalise the software. In any case you can take that decision in future if you get fed up with copying and pasting this code between projects and are confident enough to deal with extra complexity.
I only provide help via the forum - please do not contact me for private consultancy.

Go Up