Whats the quickest way to set bits?

Printable View

- 22nd October 2010, 23:57
bearpawz

Whats the quickest way to set bits?

I am trying to create a bargraph display. It has 16 segments. My routine uses a calculation of an upper bound limit for what the display should be reading and a lower bound limit.

Code:

GraphDivider = (GraphMax - GraphMin) / 16 GraphVal = (X / GraphDivider)

Everything to do with this graph is using word variables.

So lets say my graph top value is 100, and my graph lower value is 0, and X = 50:
(100 - 0) / 16 = 100 / 16 = 6.25
50 / 6.25 = 8

Thats exactly the result I expect to get. Now, to display the number 8 on the graph (having the first 8 LED's lit, the binary number I would have to send would be %0000000011111111

Is there a way to tell pic basic to set the first 8 bits on? Looking through the documentation I see I can set bit 8 with DCD=7 but that will leave all other bits at 0
- 23rd October 2010, 01:28
mackrackit

How is the display connected to the MCU? How are you sending data to it.
- 23rd October 2010, 02:09
bearpawz

Using an alegro A6276, so the pic shifts the data out. The displays thems selfs are working fine. I was just wondering if there was a quicker way to set all bits up to a certain bit number on with out having to use a look up table.
- 23rd October 2010, 02:17
Darrel Taylor

<strike>GraphVal = $FFFF >> ((X * 16) / (GraphMax - GraphMin))</strike>

GraphVal = $FFFF >> (((X - GraphMin) * 16) / (GraphMax - GraphMin))
<br>
<br>
- 23rd October 2010, 03:03
bearpawz

DOH!

I knew there was something I wasnt thinking of...

The key was right shifting the $FFFF. If anyone else is following this, here is the final formula I came up with and it works perfectly.

GraphVal = $FFFF >> (16 - (X / ((GraphMax - GraphMin) / 16)))

This is for auto guages so the scale of the graph can swing. For instance, a fuel level gauge might read 0 to 16 galons, where a water temp guage might read 180° - 290°, so it was important to note that the bottom number might change as well as the top.
- 23rd October 2010, 03:16
Darrel Taylor

And probably something I wasn't thinking of too.
That might go backwards, and need to be inverted.

GraphVal = $FFFF >> (16-(((X - GraphMin) * 16) / (GraphMax - GraphMin)))

I'll test it and see.

Doh, you beat me to it.
Oops again. :eek:
- 23rd October 2010, 04:01
bearpawz

Uh Oh. Ok, it work flawlessly until you start working with a very tight scale. An example is the volt meter. It usually displays information from 8V to 18V with the guages I am replacing. Unfortunatly, based on the formula there ends up being too small of a number to even light one LED. (or at least its not lighting anything up). I passed in a value of 13 for my test data. This is a valid number between 8 and 18. However, when you start using the formula (the one I came up with) here is what happens:

GraphVal = (16 - (X / ((GraphMax - GraphMin) / 16)))

GraphVal = (16-(13/((18 - 8)/16)))

GraphVal = (16-(13/(10/16)))

GraphVal= (16-(13/.625)

GraphVal = 16-20

GraphVal = -4!

Sorry, Ive never been horribly great at actual math. Now what? lol.
- 23rd October 2010, 04:54
mackrackit

You will not be getting a value volts at the ADC. You will have something between 0 and 255 or 0 and 1023. 8 or 10 bits.

So maybe we should start there.
- 23rd October 2010, 05:11
mackrackit

What about this for you ADC in
http://www.picbasic.co.uk/forum/content.php?r=249
Oversample to get you 16bit rez. Then you are done.

Or am I missing something.
- 23rd October 2010, 05:30
bearpawz

Not even worried about that part right now. What will be monitoring the actual car will be a whole other system. At the moment just need to know how to get the displays to display correctly.
- 23rd October 2010, 05:46
Darrel Taylor

Try the last formula I gave in post #6

Testing here, making animation to prove it.
It works.
- 23rd October 2010, 08:57
Darrel Taylor

<object id='stUkhdQ01IR1FYSF9cWVxcU1Nc' width='425' height='344' type='application/x-shockwave-flash' data='http://www.screentoaster.com/swf/STPlayer.swf' codebase='http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,115,0'><param name='movie' value='http://www.screentoaster.com/swf/STPlayer.swf'/><param name='allowFullScreen' value='true'/><param name='allowScriptAccess' value='always'/><param name='flashvars' value='video=stUkhdQ01IR1FYSF9cWVxcU1Nc'/></object>

Code:

DEFINE OSC 4 ;----[USART Settings]------------------------------------------------------- DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1 DEFINE HSER_SPBRG 25 ' 9600 Baud @ 4MHz, 0.16% DEFINE HSER_CLROERR 1 ' Clear overflow automatically ;----[LCD Settings]--------------------------------------------------------- DEFINE LCD_DREG PORTA ' LCD data port DEFINE LCD_DBIT 4 ' LCD data starting bit 0 or 4 DEFINE LCD_RSREG PORTA ' LCD register select port DEFINE LCD_RSBIT 2 ' LCD register select bit DEFINE LCD_EREG PORTA ' LCD enable port DEFINE LCD_EBIT 3 ' LCD enable bit DEFINE LCD_BITS 4 ' LCD bus size 4 or 8 DEFINE LCD_LINES 2 ' Number lines on LCD DEFINE LCD_COMMANDUS 2000 ' Command delay time in us DEFINE LCD_DATAUS 50 ' Data delay time in us ;----[A/D Settings]--------------------------------------------------------- DEFINE ADC_BITS 10 ' ADCIN resolution (Bits) DEFINE ADC_CLOCK 1 ' ADC clock source (Fosc/8) DEFINE ADC_SAMPLEUS 11 ' ADC sampling time (uSec) ;----[Variables]------------------------------------------------------------ GraphMAX VAR WORD GraphMIN VAR WORD GraphVal VAR WORD X VAR WORD ADval VAR WORD Xmax VAR WORD Xmin VAR WORD char VAR BYTE OverRange VAR BIT UnderRange VAR BIT ;----[Aliases]-------------------------------------------------------------- RCIF VAR PIR1.5 OverPin VAR PORTC.5 UnderPin VAR PORTC.4 ;----[Default Values]------------------------------------------------------- GraphMAX = 100 GraphMIN = 0 Xmax = 100 Xmin = 0 ;----[Initialize]----------------------------------------------------------- PORTB = 0 TRISB = 0 PORTD = 0 TRISD = 0 ANSEL = %00000001 ANSELH = 0 ADCON1.7 = 1 PAUSE 250 : LCDOUT $FE,1 : PAUSE 250 : LCDOUT $FE,1 GOSUB ShowMenu GOSUB ShowLimits OverRange = 0 UnderRange = 0 ;----[Main Program Loop]---------------------------------------------------- Main: IF RCIF THEN GOSUB Terminal GOSUB GetAD GOSUB ShowGraph GOSUB CheckOverUnder GOTO Main ;----[Get and Scale Analog Reading]----------------------------------------- GetAD: ADCIN 0, ADval X = ADval * (Xmax - Xmin) X = DIV32 1023 + Xmin LCDOUT $FE,$80, "AD=",DEC ADval, " " LCDOUT $FE,$8B, "X=",DEC X, " " RETURN ;----[Show the BarGraph]---------------------------------------------------- ShowGraph: IF X > GraphMAX THEN OverRange = 1 ELSE OverRange = 0 ENDIF IF X < GraphMIN THEN UnderRange = 1 ELSE UnderRange = 0 ENDIF X = (X MIN GraphMAX) MAX GraphMIN ;-- This is the formula being tested --------------------- GraphVal = $FFFF >> (16-(((X - GraphMIN) * 16) / (GraphMAX - GraphMIN))) PORTD = GraphVal & $FF PORTB = GraphVal >> 8 RETURN ;----[Show Menu for Terminal]----------------------------------------------- ShowMenu: HSEROUT ["MENU: 1=GraphMAX, 2=GraphMIN, 3=Xmax, 4=Xmin :"] RETURN ;----[Handle the RS232 Terminal]-------------------------------------------- Terminal: HSERIN [char] SELECT CASE char CASE "1" : HSEROUT [13,10,"Enter the GraphMAX: "] HSERIN [DEC GraphMAX] CASE "2" : HSEROUT [13,10,"Enter the GraphMIN: "] HSERIN [DEC GraphMIN] CASE "3" : HSEROUT [13,10,"Enter the Xmax: "] HSERIN [DEC Xmax] CASE "4" : HSEROUT [13,10,"Enter the Xmin: "] HSERIN [DEC Xmin] CASE ELSE : HSEROUT [7] END SELECT ;----[Show Limits]---------------------------------------------------------- ShowLimits: LCDOUT $FE,$C0," GRAPH X " LCDOUT $FE,$94,"MAX: " LCDOUT $FE,$D4,"MIN: " LCDOUT $FE,$99,DEC GraphMAX LCDOUT $FE,$D9,DEC GraphMIN LCDOUT $FE,$A1,DEC Xmax LCDOUT $FE,$E1,DEC Xmin RETURN ;----[Look for Over and Under Range]---------------------------------------- BlinkSpeed CON 50 BlinkCount VAR WORD CheckOverUnder: BlinkCount = BlinkCount + 1 IF BlinkCount = BlinkSpeed THEN BlinkCount = 0 IF OverRange THEN TOGGLE OverPin ELSE LOW OverPin ENDIF IF UnderRange THEN TOGGLE UnderPin ELSE LOW UnderPin ENDIF ENDIF RETURN

This post has been promoted to a bar graph wiki page, located here: http://www.picbasic.co.uk/forum/cont...ge-min-and-max
- 23rd October 2010, 09:06
mackrackit

Wow!!!!!
That is cooool!!!!!!!
- 23rd October 2010, 12:21
aratti

Assuming you have to measure max 18 volts, then you will need a resistor devider by 4 which will yield 4,5 volts to the ADC input. Assuming you will use a 10 bits convertion then:

45000/1024 = 44 (rounded)

Your 16 leds graphs = $FFFF >>( 16- ((ADC * 44 * 16)/45000))

Cheers

Al.
- 23rd October 2010, 16:47
bearpawz

thanks daryl, it does in fact work. I got tired last night and gave up on it and I think we were cross posting some how. Now all I have to do is tackle communications and Im done with this part of the project.

Btw: Whats that cool little program your using in your video?
- 24th October 2010, 01:37
Darrel Taylor

Yeah, it was kind of late.
But like I said, I needed the practice. :)

The simulator is Proteus VSM from Labcenter Electronics.
Definately the coolest program I've ever had.
- 24th October 2010, 02:19
Charles Linquis

Darrel,

I'm thinking of buying Proteus VSM. I know I should ask Labcenter, but since you use it with PBP, could I ask you a few questions?

All my schematic capture is in Altium (formerly Protel). Do you know if Proteus will import other formats? Altium will export in Orcad 8 format and a few others.

If I write a program in PBP, I assume that I have to feed Proteus the .ASM file in for the simulation. Is that true? I can't imagine that it would show me the PBP line it was executing during an animation. Just how easy is it to use in conjunction with PBP?
- 24th October 2010, 03:11
Darrel Taylor

I don't think it can import files from any other programs.
There's nothing in the menu's, but I don't know if there are any external conversion programs.

With PBP 2.60A, you can work directly with your PBP code and it will single step through the program as it's simulating. The internal editor is terrible, but you can use MCS as an external editor. It doesn't use MCS to single step, but it's easier to write stuff.

You can also integrate it with MPLAB, and it will single step using the MPLAB IDE and watch variables, have breakpoints etc, but it reduces the screen space for the simulation.

For me, it's easier to compile programs like I always do with MCS, and just run the .HEX file in Proteus like I would on real hardware. No single stepping that way, but I don't need to single step anymore anyhow.

There's a demo version available.
It's doesn't let you create your own schematics, but there are a bunch of samples that you can write your own PBP code for. It's kind of like buying several development boards. You can't change the hardware, but you can write programs to run on them. And they're free.

I've saved so much money since I got it.
I don't buy chips and parts and breadboards and LCD's etc. anymore.
All my breadboards and electronics stuff are still in boxes after the move to Colorado. Just don't need them anymore. :)
- 24th October 2010, 17:48
Charles Linquis

I have so many unique situations that I don't know if Proteus would help. I have an unlimited number of development boards, but what is hard for me is simulation. I'm using all the pins of an '8723 (and in some cases, 2 8723's "lashed" together). I have so many combinations of digital, analog, and serial data that testing is becoming very, very time consuming.

And I have to deal with a lot of external hardware. Like I2C. And I almost always control fans using a PID control loop using the PICs CCP registers to send 158Khz PWM out to a "buck" converter, which is filtered to give pure DC to the fans. I watch the fan tachometers and use that feedback to control the PWM. I have an algorithm that automatically sets up the coefficients for any fan (big or small) that I hook to it. But it seems like I'm always tuning that algorithm.

I also need to process a lot of serial data - often SNMP packets that have to do a large amount of parsing. I use Lantronix XPorts or MatchPorts to do the network "heavy lifting" but long packets still come in over the USART or SPI port. The ability to inject long strings into those ports and watch the execution of the parser would be priceless. Right now, I capture network packets with WireShark and go through long lists, byte-by-byte.
Since I'm dealing with external devices, a lot of things are time-critical as well.
The whole test process takes far too long.

I can't imagine that Proteus could do all of what's needed, but if it could help me with even part of what I'm doing, it would be money well spent. What do you think?
- 24th October 2010, 19:06
HankMcSpank

This bargraph generator looks like it could be useful!

I watched the video, but I wasn't able to work outwhat all the user input was for - what I'd like a bargraph generator to do is react to an incoming analog signal.

Ideally with just 5 leds... up until, now, I've been using a dedicated bar graph IC (http://www.youtube.com/watch?v=xXB92cSQi8E - warning turn your PC sound down), but the problem with that IC is that it's a one trick pony...therefore I was thinking of using a PIC to do the bar graph - becuase this would allow corny LED patterns like Knight rider etc!...so I was pondering how to do this just a couple of days ago...this thread is very convenient!
- 24th October 2010, 19:07
Darrel Taylor

Charles,

I think you're out of luck on the fan part, it does have a fan motor but you have to measure RPM from the commutator current pulses. There's no direct RPM output.

It has the 8720 and 8722, but not the 8723 ... yet. Every new version (about every other month) has more chips and stuff.
You can run multiple chips simultaneously.

It doesn't have an XPort, but you can interface to an external COM port, so it could use a real XPort.

It has I2C and SPI debuggers that allow you to send anything you want to either the master or the slave. It will definitely be useful for that part.

But overall, I think you'll be better off sticking with hardware for such a large project, especially because simulating lots of analog circuitry slows it down considerably. It would probably take an 8 or 16 core computer to simulate your whole circuit anywhere near real-time.
- 24th October 2010, 19:16
ScaleRobotics

Quote:

Originally Posted by HankMcSpank

I was thinking of using a PIC to do the bar graph - becuase this would allow corny LED patterns like Knight rider etc!...

For Knight Rider bargraph, check out post number three on the MIBAM thread here: http://www.picbasic.co.uk/forum/showthread.php?t=10564
- 24th October 2010, 21:47
rmteo

Charles, download the current issue of Embedded Systems Design here. You can also subscribe to the print version which is available for free to professionals.

http://www.eetimes.com/ContentEETime...10esdCover.gif

It will give you a good idea of what is happening in terms of tools (hardware and software) and techniques that are used in current embedded systems design and development.
- 25th October 2010, 01:42
Charles Linquis

I keep threatening to change compilers (to C18, for example) or make a bigger move to ARM chips, but it seems like I never have time to make the switch.

Also, I have so many thousands (truly!) of PICs in military applications that it is really hard to change. In some cases, it took a year to get the hardware qualified but we now have enough of a 'track record' with the hardware and sw that we can get products qualified "by example". If I changed chips, I would have to start over.

I guess I'll have to keep doing it the hard way for a bit longer.

And one more thing - anyone who thinks that PBP is somehow not as good as 'C' can be told that it is running in an awful lot of very, very critical military applications. When written correctly, PBP is bulletproof.
- 25th October 2010, 02:18
rmteo

Quote:

Originally Posted by Charles Linquis

....And one more thing - anyone who thinks that PBP is somehow not as good as 'C' can be told that it is running in an awful lot of very, very critical military applications. When written correctly, PBP is bulletproof.

Hey, if it works for you and your customers are happy, go for it. :)
- 25th October 2010, 02:35
Charles Linquis

But I will still have to make the change sooner or later. That is, unless we can get Darrel to add functions, procedures, better string handling and a few other features to the next version of PBP!
- 25th October 2010, 15:47
rmteo

Charles, it is not about you saying that something is bulletproof or whether C (or other language) is better/worse than PBP (or anything else). It is about how easy/difficult it is to ensure (from a maintenance/validation standpoint) that the application/system is correct and how you can validate/test that is so.

From the software perspective, you have discovered that as an application becomes more complex, it gets increasingly difficult to maintain (make changes, additions or corrections). As you have mentioned, languages having structured elements (such as functions, procedures, local and global variables, etc.) go a long way in making it so. Also, features such as pointers, structures, members and unions are very useful when dealing with complex data structures. These features are available in languages such as C.

As for hardware, having the ability to do some form of in-circuit hardware debugging is extremely useful. The ability to single step through the firmware (at the source and/or debug level), set breakpoints, inspect memory and register values, change values on-the-fly, tracing, etc. can give you a view of what your system is actually doing that is difficult to impossible otherwise.
- 25th October 2010, 22:47
Charles Linquis

I only made the 'bulletproof' comment because although I write mostly in PBP, I have hired people that knew only 'C'. At first, they were totally convinced that a program written in BASIC was either very slow in execution, or lacked a lot of functionality, or was a "toy" for some other reason.

After a couple of months, they realized their opinions were wrong. All of them learned PBP at least to some extent.

I was trying to give a "pep talk" to all the other PBP coders out there.

My heartburn with PBP is that it is difficult to write reusable code, and also the lack of easy debugging.
- 25th October 2010, 23:25
rmteo

Charles, if I (and even more importantly, my customers) are convinced that we have a serious (non-toy in your words), commercial grade MCU development toolchain that is considered bulletproof, I would not bother looking for anything else. :D
- 25th October 2010, 23:25
mackrackit

It all comes down to who is banging on the keyboard.

I write crappy code no matter what language I use. I imagine folks like Darrel and Bruce write great code no matter what language they use.

I also bet that Darrel and Bruce can write in Basic and blow even a good "C" coder out of the water.

So if you like B, C, or what ever... use it. What is good for one is not necessarily good for another.
- 26th October 2010, 00:58
rmteo

Sorry Dave, coding ability (or lack thereof) isn't the issue here. :rolleyes:
- 26th October 2010, 01:28
mackrackit

Quote:

Originally Posted by rmteo

Sorry Dave, coding ability (or lack thereof) isn't the issue here. :rolleyes:

Darn, wrong again...
But I coulda swore it was the code that made these things work like we want them to. :confused:

Oh well, back to the drawing board.
- 26th October 2010, 02:49
ScaleRobotics

Quote:

Originally Posted by rmteo

Charles, if I (and even more importantly, my customers) are convinced that we have a serious (non-toy in your words), commercial grade MCU development toolchain that is considered bulletproof, I would not bother looking for anything else. :D

Carefull rmteo,

One of your customers might see that you spend an awfull lot of time on this toy compiler forum, and wonder if you are really programming their equipment with the bulletproof C. Sure you try to convert others here to the dark side on a regular basis, but is that just to disquise the fact you really like PicBasic better? ;)
- 26th October 2010, 04:38
rmteo

Quote:

Originally Posted by scalerobotics

Carefull rmteo,

One of your customers might see that you spend an awfull lot of time on this toy compiler forum, and wonder if you are really programming their equipment with the bulletproof C. Sure you try to convert others here to the dark side on a regular basis, but is that just to disquise the fact you really like PicBasic better? ;)

Actually my customers don't give a hoot as to what I like - they only care about what they want. And as long as I give them what they want (on the terms and conditions we have mutually agreed upon) they really don't care what I do with my time - even if I decide to spend it on a toy compiler (your words) forum.