| ??? 03/28/05 09:01 Read: times Msg Score: +1 +1 Good Answer/Helpful |
#90519 - Knowledge, not language. Responding to: ???'s previous message |
Ian Bell said:
We have discussed this in other threads but in essence the shared data problem can occur whenever two pieces of code share common data and one piece of code can interrupt the other while it is in the middle of using the data. The result is at least corrupt data and often worse.
The most common form of code interrupting other code is of course in interrupt routines . Anytime a code fragment reads a multibyte value set by and ISR or writes a multibyte value used by an ISR, it is possible for the ISR to occur part way through the read or write and either corrupt the value being read or use a partly set value. This is the shared data problem. To avoid it the read or write operation must not be interruptable. This is called an atomic operation and the code fragment where the problem might occur is known as a critical section. Sure - but exactly the same problem exists in assembler. This is a question of understanding the interreaction between ISR code and non-ISR code, the programming language is irrelevant. People think provided the use unsigned chars they will not get the problem. This is not the case for several reasons: 1. Compilers often promote chars to ints internally. Ah, this old chestnut. The situations where a conforming compiler performs any kind of 'promotion' of chars are clearly defined by the 'C' standard. The Keil compiler, and, I would guess, any compiler targeted specifically at the 8051 does not promote char in most of these situations. If you use a char, you get a char. 2. The operation needs to be atomic so if you read a char, operate on it then save back where you got it from, the operation is not atomic. 3. The problem can apply not only to the data but to shared pointers. Again, exactly the same problem exists with assembler. A common solution is to disable interrupts just before the critical section and enable them just after. Again, this solution along with many other strategies for handling shared data is language independent. There seems to be a common misconception that assembler must be used whenever 'low level' stuff has to be done. The only occasions where assembler is essential in a project are: 1) Configuration required before the 'C' startup code is called. 2) Object code must remain identical at every compile. 3) Extra speed optimisation is required. 4) Extra code size optimisation is required If I've missed anything off the above list I'm sure somebody will be happy to point it out... |
| Topic | Author | Date |
| 8051 in C or assembly? | 01/01/70 00:00 | |
| Probably C | 01/01/70 00:00 | |
| Always C | 01/01/70 00:00 | |
| Mostly 'C' | 01/01/70 00:00 | |
| No magic wand | 01/01/70 00:00 | |
| Assembler when? | 01/01/70 00:00 | |
| Shared data problem?? | 01/01/70 00:00 | |
| Shared Data Problem | 01/01/70 00:00 | |
| I see | 01/01/70 00:00 | |
| Sared Data | 01/01/70 00:00 | |
| addendum | 01/01/70 00:00 | |
| Shared Data | 01/01/70 00:00 | |
| Knowledge, not language. | 01/01/70 00:00 | |
| Knowledge | 01/01/70 00:00 | |
| Knowledge | 01/01/70 00:00 | |
| Promotion | 01/01/70 00:00 | |
| Promotion | 01/01/70 00:00 | |
| Promotion | 01/01/70 00:00 | |
| Traps for the unwary | 01/01/70 00:00 | |
| Preaching | 01/01/70 00:00 | |
| Ditto | 01/01/70 00:00 | |
| red rag.... | 01/01/70 00:00 | |
Bend over then... | 01/01/70 00:00 | |
| hauling assembler | 01/01/70 00:00 | |
| Clarification | 01/01/70 00:00 | |
| Keil Allows this to be disabled | 01/01/70 00:00 | |
| Know your tools | 01/01/70 00:00 | |
| It means 8 bit may be 16 bits | 01/01/70 00:00 | |
| More knowledge! | 01/01/70 00:00 | |
| not really | 01/01/70 00:00 | |
| So which... | 01/01/70 00:00 | |
| Calculations in C | 01/01/70 00:00 | |
| ibid | 01/01/70 00:00 | |
| Not always.. | 01/01/70 00:00 | |
| Example | 01/01/70 00:00 | |
| Better?? | 01/01/70 00:00 | |
| assembly | 01/01/70 00:00 | |
| YMMV | 01/01/70 00:00 | |
| assembly | 01/01/70 00:00 | |
| Hitting the Wall | 01/01/70 00:00 |