8051 microcontroller operating like Solitaire - University Assignment

Thread Starter

Novicedev

Joined Nov 28, 2019
5
I was tasked with creating a certain 8051 microcontroller project by my professor and I am keen to build the project all by myself, however, in order to carry out the given assignment, I may need some expert guidance. The project description is provided in below paragraph.

The microcontroller is supposed to operate similar to Solitaire which indicates that it should pick a card randomly by a push button and then display its name on LCD. Also, it is essential to note that once a card is picked, it cannot be picked for the second time (All of playing cards can be selected only once from the deck of cards). The final point would be that the project code must be written in embedded C and project simulation should take place in Proteus.

At the moment, I don’t have the faintest idea where should I begin with, what steps to take, etc. I would be really and truly grateful if you could assist me by giving me detailed instructions.
 

KeithWalker

Joined Jul 10, 2017
3,063
At the moment, I don’t have the faintest idea where should I begin with, what steps to take, etc. I would be really and truly grateful if you could assist me by giving me detailed instructions.
You have already written a brief specification (above). Make sure it includes all the requirements. The next step is to make a flow chart or psudo-code that would help you to visualize and test the program before you start writing code.

Regards,
Keith
 

jpanhalt

Joined Jan 18, 2008
11,087
Last edited:

WBahn

Joined Mar 31, 2012
29,978
I was tasked with creating a certain 8051 microcontroller project by my professor and I am keen to build the project all by myself, ... I would be really and truly grateful if you could assist me by giving me detailed instructions.
You do realize that these are mutually exclusive?
 

Thread Starter

Novicedev

Joined Nov 28, 2019
5
Thank all of you for your kind contribution to my problem but I haven't find the actual solution just yet!

Although I exactly know how to interface LCD in 8051, I'm not sure how to generate card names using push button, how to avoid selecting a duplicate name and last but not least, how to select cards randomly!

I've been searching and struggling to find the possible approaches for solving my problem for quite some time now, but I haven't got anything at all and when I ask them to give me some advice or tips, most of them recommend purchasing their courses and so on.
So, here I am, stuck in this hole, hoping that somehow miraculously I find the solution
 

jpanhalt

Joined Jan 18, 2008
11,087
Although I exactly know how to interface LCD in 8051, I'm not sure how to generate card names using push button,
I would consider choosing the card value (0-12 or 1-13) and suit (0-3 or 1-4) and/or color (0-1) separately. That may simplify the red/black alternating stacking requirement. Assigning a unique number to each card could also be done (e.g., 0-51). That might make it easier to select a unique card, but then you will have to calculate sequential cards and alternating colors/suits. As you know, the basic game is based on color and value, but the stacks at the top of the board are based on suit and value (at least the way I played the game was like that).

how to avoid selecting a duplicate name and last but not least, how to select cards randomly!
Because the deck is limited, the actual game is not random. Like the popular game, "21", a card counter may do better than a player who just relies on "luck." The LFSR type of random number generators ensure that each value is selected just once. Will your professor allow that? Otherwise, you will need a way to skip duplicates.

I've been searching and struggling to find the possible approaches for solving my problem for quite some time now, but I haven't got anything at all and when I ask them to give me some advice or tips, most of them recommend purchasing their courses and so on.
So, here I am, stuck in this hole, hoping that somehow miraculously I find the solution
LFSR is quite easy to program. Try an 8-bit version with just 2 XOR's picks at first. Let's see your work on that approach first.
 

djsfantasi

Joined Apr 11, 2010
9,156
Keeping track of the color is refundant, given that suit is also maintained. Careful choices for the suit values make testing color as easy as when you maintain a color variable without the added memory and code.
 

BobTPH

Joined Jun 5, 2013
8,813
The microcontroller is supposed to operate similar to Solitaire which indicates that it should pick a card randomly by a push button and then display its name on LCD. Also, it is essential to note that once a card is picked, it cannot be picked for the second time (All of playing cards can be selected only once from the deck of cards). The final point would be that the project code must be written in embedded C and project simulation should take place in Proteus.
What kind if idiot wrote this specification?

How is picking a card at random and displaying it on an LCD in any way similar to the game of solitaire?

Bob
 

djsfantasi

Joined Apr 11, 2010
9,156
I often approach coding, by first not coding! i spend the time defining the data first. Like, whats a card? Then, what’s a deck and what’s a sorted deck?

When you define the data, you have the required operations in mind. Subconsciously, you are making little coding decisions along the way.

So when you start coding after spending the time defining the data, it should comr to you freely.



UPDATE: Removed “Three more definitions are needed. What’s a stack and what are piles?”
 
Last edited:

WBahn

Joined Mar 31, 2012
29,978
What kind if idiot wrote this specification?

How is picking a card at random and displaying it on an LCD in any way similar to the game of solitaire?

Bob
I think that solitaire tie is just to get the notion across of having to select a different random card on each draw.

But, if the object isn't to actually play the game of Solitaire (whatever variant of the game is being discussed) then we do need a better description of what IS expected. Each time the player pushes the button is the goal just to pick a random card that hasn't yet been picked and display that single card on the screen? If so, what happens after the last card is picked and the player pushes the button again?
 

Alec_t

Joined Sep 17, 2013
14,280
I agree with WBahn. You haven't said which version of Solitaire is involved. You need to know all the rules of that version if, indeed, you are expected to simulate the whole game.
 

djsfantasi

Joined Apr 11, 2010
9,156
I think that solitaire tie is just to get the notion across of having to select a different random card on each draw.

But, if the object isn't to actually play the game of Solitaire (whatever variant of the game is being discussed) then we do need a better description of what IS expected. Each time the player pushes the button is the goal just to pick a random card that hasn't yet been picked and display that single card on the screen? If so, what happens after the last card is picked and the player pushes the button again?
Really, there are so many options!
  1. Stop until the μp is reset or power cycled?
  2. Start over
  3. Display an appropriate message on the LCD, pause and then repeat with 1 or 2
  4. Same as 3, but instead of pausing, wait for a button push
  5. etc, etc... and so-on!
Just imagining several options to illustrate the incompleteness if the specification.
 

Thread Starter

Novicedev

Joined Nov 28, 2019
5
I agree with WBahn. You haven't said which version of Solitaire is involved. You need to know all the rules of that version if, indeed, you are expected to simulate the whole game.
It's not really about solitaire that much!
8051 MCU should display a card name on LCD each time we push the button
 

WBahn

Joined Mar 31, 2012
29,978
Although I exactly know how to interface LCD in 8051, I'm not sure how to generate card names using push button, how to avoid selecting a duplicate name and last but not least, how to select cards randomly!
So start tackling those as separate problems.

Problem #1: Generating random numbers.

There are lots of ways to do this, some far better than others, but I suspect you just need a way that works at least superficially. One way is to simply have a counter that increments at a high rate of speed and then each time the button is pushed the value of the counter is your random number. Now you just need a way of mapping that number to a specific card. Again, there are lots of ways to do this, some far better than others, but again I suspect that you just need a way that works at least superficially.

For instance, let's say that I need random numbers between 10 and 20, inclusive (that's 11 different values). Now let's say that I have a 16-bit free running counter and when I push the button I capture the value 17261. Well, since I need 11 different values I can take just the last four bits (since that's 16 possible outcomes), which happen to be 1101 (or 13) which is more than you want so you subtract 11 and get 2. Now you add the minimum value and get 12 and that is your random number.

This is NOT a very good random number generator as the low numbers have twice the change of being picked as the high numbers. But it's easy to understand and implement and it's a start -- you can always modify your code to do a better job later.

Problem #2: Mapping random numbers to card names.

Assuming you can generate more-or-less random numbers between 0 and 51, how could you map those to specific cards? Give it some thought and describe what you can.

Problem #3: Avoiding duplicates.

How much memory do you have available to you? Can you think of a way of storing which cards have already been picked and, if the new random card has already been picked choosing another random card until you find one that hasn't been picked? This can get tricky if you use the free running timer method of selecting your random number, but there are numerous ways to work around that issue (some far better than others).

Another member suggested using an LFSR and that is a pretty good solution as it addresses several issues at once. But you need to put in some time researching what an LSFR is and what it's properties are (as they apply to your situation) and how to deal with their limitations (which isn't too hard).

As with all things engineering, you have to make decisions about compromises. Do you go for something elegant that may take you a lot of time to research and implement (but that you will learn a lot from), or do you go with something quick and dirty that you can implement right away and that, when all is said and done, might be "good enough". Even if it's not, you'll learn from understanding why it isn't good enough and that can inform your next iteration.
 

WBahn

Joined Mar 31, 2012
29,978
Since the program is to be written in C, random numbers is already solved by the rand() function.

Bob
Very possibly. I don't know if the particular implementation the TS is using has that support in the standard library since embedded implementations are pretty loose with adhering to the standard. But the use of rand() is sufficiently useful in embedded applications and the implementation of a moderately decent pseudorandom number generator is pretty simple and is given in the standard as an example, that I would expect it to be there.

I think I made the (very possibly poor) assumption that the fact that the TS wasn't already aware of it meant that it wasn't available in his implementation.
 

jpanhalt

Joined Jan 18, 2008
11,087
If you go the LFSR route, in the EETimes link above (#4 in the list), don't forget to click on the second page to get some recommended "taps." They are not unique, but they ensure every number is selected at least once.
 
Top