----- Ursprüngliche Nachricht ----- Von: Eric Decker Gesendet am: 05 Apr 2011 15:56:27
On Tue, Apr 5, 2011 at 3:40 AM, JMGross <msp...@grossibaer.de> wrote: >> >1) What does setting DMARMWDIS really do? [...] >> Normally, you don't have to deal with this, but under some circumstances >> it can be critical, and it's good that TI has included this option. > You've used it then? Is it a good idea to not risk it but just leave it on? > Unless there is an overriding performance reason to turn it off ie. > like you really need the dma to run quickly and you know that it won't > mess with anything. For example > you know you are simply copying from memory say out the SPI port > and the cpu won't touch the SPI port because the cpu knows it is busy. > The DMA interrupt makes the CPU pay attention again. Well, yes, unless there's an important reason (like copying a port content by an external DMA trigger, so the port won't change if the DMA is delayed), you can keep it on. One of the critical operations is when both, DMA and CPU access the same register, and a DMA write would be overwritten by the CPU write, but the value written by the CPU is based on the previous register content (or memory, that is). It may happen if you use the DMA to copy hardware config from ram to registers, and the CPU changes the config or accesses the register. If the DMA timing is not critical, leaving it on is the safer way. You might want to include a flag in the driver call that defaults to true (set the bit), but may be passed as false if DMA timing is critical. I think, however, that in those critical cases a direct programming of the DMA would be preferred over a generic driver anyway. >> p.s.: the MSP _is_ a RISC processor, since RISC means Reduced Instruction >> Set. > The traditional (Patterson et. al, Berkeley and the IBM 801) includes the > concept of the only memory operations go into registers and all other > ops are register to register. > This allows one to simplify and greatly increase the pipeline and > make the machine run really fast. > The TI ISA doesn't really fit that. True. (I worked with Sparc processors many years ago). However, the drawback of this concept is the high amount of code required. Basically, you're writing in microcode. Which partly negates the advantage of the pipelining. It makes, hopwever, execution times more predictable, since CISC processor tend to have different execution cycles based on the actual program flow. On TI, each combination of operation and addressing modes has its own, fixed execution time, and pipelining is unnecessary, as the instructions usually execute in as many clock cycles as there are memory accesses. (in case of register operations as target, the next isntruction is fetched during the calculation and register write). You could write plain risc programs (only using MOV when interfacing memory), and in fact, the A instructions of the MSP430X pretty much do that. Your program wouldn't execute faster (already on 1 instruction/cycle then, except for branches/calls - no delay slot - and memory access), only be longer and require more registers for the intermediate values. Adn I really didn't like the fact that you had to use two instructions to load a register with an immediate value (as the value was part of the instruction and could only load part of the register) >> It does not mean that you have to write your programs in microcode, >> splitting all operations into separate instructions. > Yeah I know. I used to write real microcode. And when I was at > cisco we built a network blade for FDDI that had a microcode > architecture that was 180 bits wide. Well, many years ago, I designed a 4-bit processor completely from TTL chips. It was an university project. One of the few with real educational value. I also wrote the microcode for this baby. Not a very complex instruction set (how much can you do with 16 instructions?) but it did run stable with >200kHz. > I would call the TI ISA RISC like. depending on how narrow you take the definition of RISC. Since it definitely isn't a CISC and the usual usage only has these two classifications. > Perhaps splitting hairs. But it is germaine > for the discussion about what DMARMWDIS does. Well, on a 'strict' RISC system, there were no way to determine whether the DMA may interrupt a sequence of commands or not. The code had to disable/enable DMA manually. > If I understand it properly because of complications of TI's RISC > like architecture and implementation, the impact of DMA cycle > stealing can have side effects and turning off the DMA > while in a processor execution cycle maintains some level of necessary > atomicity. Cycle stealing, maybe, but also interleaving of CPU and DMA access to the same ressource. It is no processor thing, it's mainly of importance when the plain abstract code hits the reality of external (to the CPU core) hardware and events. For the CPU itself it makes no difference whether it is interrupted by DMA or whether its CPU clock misses a beat (or many). It's like interrupts: for the plain program flow, it is unimportant whether an interrupt occurs. The code won't notice. But for the interactin with the physical reality, this might have some importance and that is why there is a DINT() command, to keep a sequence of instructions uninterrupted. It has nothing to do with RISC or CISC at all. SO you cna look at this bit as an automatic DINT()/EINT() (DDMA/EDMA) placed around all instrucitons that do an atomic RMV to memory, to keep the RMV atomic. > True RISCs avoid this kind of thing but not letting it happen. True RISC would have to disabel the DMA to not have a sequence uninterrupted that reads from memory, operates in register and then writes it back > Then again the old machines I'm thinking of had seperate CPUs, > seperate caches, and seperate DMA > engines that talked directly to main memory. > The CPUs never saw this kind of problem because they operated > out of the cache. > Now cache coherency definitly was a problem. Yes, DMA writes to memory had to update the cache, so the CPU does not run on old data. However, caches are only needed if a memory access takes longer than one CPU cycle. On MSP it doesn't. It only would if there were such a thing like a double-core MSP. (and for - not only - this reason I just dumped the idea of a double-core MSP in the TI E2E forum) JMGross ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
