1. Home
  2. Electronics Design
  3. Pic Program to update single bits from table
  4. Page 2

Pic Program to update single bits from table

haha... logic error? It's a bug either way and your program could have some serious flaws. If it was for medical use and that flaw had the result of killing somebody you should be counting your lucky stars because no one would look at your code to see your "logic error". (which would be called involuntary manslaughter)

Obviously if the int's are not using that data they can't cause any problems but thats a weak assumption. You never know when or how it might happen unless you explicitly state it... but only in highly optimized code would it be worth doing that way. The general practice is to disable interrupts.

But I can give several examples. Program context has nothing to do with it. You are not saving the stream. In fact many serious flaws have resulted because of such things(and they take various forms).

The general idea is

partially Modify data interrupt completely modify data

if the interrupt depends on the data, then since it interrupted it before it was completely modified the data of the data might be invalid(and usually is) and the code will not function as predicted.

A simple real example

global int x = 4

--
x = x + 3
int
x = x*9


Now suppose that the two assignements for x were suppose to operate as one 
logical unit. Say that x = 7 is actually a state that is suppose to be 
forbidden... Or suppose it\'s an error code and 7 is a different code than 
63.

Then if int uses x, which has nothing to do with program context, it will 
see x as 7 and not as 63

i.e., if it as

x = x + 3
x = x*9
int

But since you didn\'t think about the interrupt ocurring inbetween the 
statements you never realized how x = 7 was comming about.

It\'s a big deal and though you might want to be a hard head about it maybe 
one day it will bite you in the ass and you\'ll spend weeks trying to figure 
out why your code is crashing.

If you were smart you would say "Thanks, I\'ll need to remember that for next 
time" or something like that. Else your just being ignorant.

I\'ll agree that in 99.9% of the cases it won\'t matter but lets hope you are 
writing code for anything serious then.
Reply to
Jon Slaughter
Loading thread data ...

You presume allot. You can build all the straw men you want, JW's code was fine.

You really don't know what you are talking about here. I have fixed scores of obscure bugs in programs that the author couldn't fix. How much programming experience do you have?

Who was it that thought the OP didn't know how to solve his problem and was wanting a C solution?

I didn't want to be rude, but since you aparently won't have it any other way..... I've been writing code for more than 30 years on a wide variety of platforms from 8-bit micros to 36-bit mainframes, literally. I've used PICs extensively for something like seven years, now I do the ARM thing for fun. I think I know a thing or two about using a PIC chip including pretty much all the internal peripherals, using multiple and even nested interrupts. But if you'd like to compare code some time.... You are way over your head here bud, too bad you aren't smart enough to realize it. You are also way too quick to jump to conclusions about other people's abilities while trying to stand on your own shoulders.

Don't get me wrong, I like your ambition to learn and your outgoing nature most of the time. You need to do a little more careful reading and a little less "telling" people how smart you [and how dumb they] are while arguing petty, moot points with them.

Reply to
Anthony Fremont

LOL, don't we all.... ;-)

Aw, I thought you were going to whip out some cool PIC secret I hadn't heard yet. Not only does the solution that James provided take less instructions, it doesn't break the pipeline either. That makes it roughly twice as fast to execute than the "safe" version. If we're counting cycles then JW wins by a mile. Assuming it's an issue, worrying about the atomicity of an update and how it impacts an ISR is something the coder should be doing every step of the way, that's why I see it as a non-issue here. Only the OP can decide which is "better".

Reply to
Anthony Fremont

Yes, that worked well. Thanks for the info.

-Bill

Reply to
Bill B

Yes, I have the basic idea working as suggested, but one more question if you have any ideas.

I have several data tables for various sequence generation, and I was wondering if there is an easy way in assembly to call a table using a variable indentifier. In other words, instead of calling table1, table2, table3, etc. is there a methode of calling table(x) where x represents the data table to be used?

I notice I can use a hard number such as where 175 is the program line number, and the program will branch to line 175 and return the desired data. But I can't seem to figure out how to call some variable location.

Any ideas?

-Bill

Reply to
Bill B

push it on the stack and do a return?

can't use line numbers, but an array full of locations should work.

Bye. Jasen

Reply to
Jasen Betts

Is this what you mean? TableNumber is preloaded with the 'number' that you want (0, 1, 2, 3) ... CLRC RLF TableNumber, W ; multiply table number by 2 (0, 2, 4,

6) ADDWF PCL, F CALL Table0 GOTO endit CALL Table1 GOTO endit CALL Table2 GOTO endit CALL Table3 ... endit: ...
Reply to
Anthony Fremont

The small PICs don't have PUSH and POP instructions.

I see a possibility when you make one large table consisting all the small ones and an extra table consisting the table addresses. Calling this lookup routine requires two variables of course, one containing the number of the table to be consulted and one containing the entry number in that table. Suppose the entry number stored in the variable 'index' and the table number stored in w, your code can go like:

call getit ; on return w should ; contain the required value . .

getit call gettable_ad ; on entry w contains the table number addwf index,w addwf PCL,f table01 retlw value0101 retlw value0102 . . . table02 retlw value0201 . . table03 . .

gettable_ad addwf PCL,w retlw table01 & 0xff retlw table02 & 0xff .

The whole "large" table, allthough subdivided in smaller ones, should not cross a page boundary. Same applies for all lookup tables.

petrus bitbyter

Reply to
petrus bitbyter

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.