I always seem to find strange ideas in my head, and unfortunately I'm new to Arduino. (Last serious programming I did was in pascal of all things, and a touch of 6800 assembly and an odd proprietary code last year)
I'm looking to read a parallel BCD signal from a pre-exisiting board, then convert it to decimal. Two digits are sent at the same time via 8 binary pins. It also has to be done quickly, as it's a strobed signal, so it changes every 1000us. So I am going to want to use port manipulation to read the signal. I also want to conserve code space too, as if this works I’m going to be dramatically enlarging the concept.
I'm using variables named num1,num2 for the binary data and numA,numB for the converted decimal.
I have the 8 pins wired all to Port-A on an ardunio Mega board.
Most of the code I think I have ok, but it’s doing the port read that is confusing me. So is the amount I can simplify and combine the code into smaller blocks within the Arduino language.
And for the BCD conversion that I dug up somewhere else… This, I’m still working on how to even include this in the code. So I am pretty sure I’ll need to amend this to some degree
Depends on the value of PinA. Although, if you worked for me, I'd kick your all for using num1, num2, NumA, and Numb as the variable names. Surely, you can think of more meaningful names than that. A and b? Give me a break. I can (almost) accept a and b or A and B. But A and b? No.
Or, could I even cut that down even further by going with this version?
Believe it or not, based on how the hardware side of it works, those variable names actually make sense (pardoning the typo on the capitalization). It only generates two single digit numbers at any given time, and depending on the strobe sequence it places them in different locations. So I really am looking for number 1 and number 2.
When the strobe goes low.....
Read number 1, convert it. Then put it in its location on the LCD, based on the strobe number
Read number 2, convert it. Then put it in its location on the LCD, based on the strobe number
As the the rest of your post? Since there's no actual content and only a hefty dose of snark.... I'm not even sure how to respond.
Actually, it sounds to me like you are looking for digit 1 and digit 2. The difference may be subtle, but it is important.
As the the rest of your post? Since there's no actual content and only a hefty dose of snark.... I'm not even sure how to respond.
Perhaps, you should try running that stuff by the compiler. When it gets done laughing at Void, Byte, and the backwards curly braces, let us know what changes you make.
Yes, I get the difference between a number and a digit. I am looking to derive the numeric values of two separate digits, coming out of a BCD encoder. So perhaps I could have used bcd1 and bcd2, or digit1 and digit2. But in the future I also need keep track of how many digits there are, so I wanted to use 'digit' for a different purpose. And, ok, I capitalized void and byte out of old grammar habits, when I started a new line.
As to what changes I'd make? I'd suggest DECAF (and yes, I made that a constant, not a variable), to be honest. God help us all if you are, or were, a teacher. I totally understand the fact that I have a fair amount errors in there when I typed up the original post. Usually when somebody asks a question, they are acknowledging that lack of information, and are actually trying to learn. But If all you want to do is puff out your chest to make yourself feel better, go right ahead.
Just to be nice though, I did go back and correct much of it. And I will look into using the forum tools to display the code better.
so it changes every 1000us. So I am going to want to use port manipulation to read the signal.
A signal that changes every millisecond is slow. You won't need port manipulation to keep up with that - and that's good because the code will be easier to write and maintain.
How long does it take to perform 8 binary reads from pins? Keep in mind I also have to monitor another 16, and trigger the BCD reading section of the code off of the falling edge, and that's in the more basic iteration.
I'm not too worried though about the complexity of doing the port work. I'm so used to dealing with that kind of binary level information from some of the near-assembly level work I've done in the past, it's easier for me to wrap my head around than C++ based code right now. Buy yeah, not having to bit count in hex is a nice change of pace, that's for sure.