| ??? 06/03/00 21:13 Read: times |
#3029 - RE: 16-bit 8052s |
Hi Martin & Steve,
I do not really want to give away too much information about exactly what I'm doing for various reasons, sorry. I am not making any developments into the improvement of DMX512, although I can think of several ways the method used for data communications between lights and their control could be improved, there is little point in trying seeing as it's unlikely any lights or controllers would use my method. What am working on is the way in which lights are controlled and programmed by the lighting engineer. As you both may know, the various features of a DMX-512 compatible light (dimmers, colour-changers, scanners etc..) are controlled by an 8-bit value at a given address (0-511). The lighting controller simply offers a way of automating or letting the user change the value of each channel. I have considered using several processors, but I have two problems: Say my system only had one DMX512 output (that's 512 channels), which is not the case (my system's spec is quite high, providing support for upto 8 DMX512 outputs, 4096 channels). I could use perhaps 4 processors, each looking after 128 channels each. This is the only way I can think of splitting up the work between processors. The primary task of the system is to essentially playback sequences of events (value changes) over the 512 channels. It is very important that all the processors stay in sync, otherwise parts of the sequence will out run others, resulting in an unsightly mess!!.. This problem seems easy to solve, why not just run all the processors off the same clock? Okay, I could do that, but due to the nature of the firmware the processors will be running, the sequences could still go out of sync (the reason why is quite complicated, I don't want to confuse matters by explaining it). The second problem is that the processors won't just simply be replaying sequences, they will be performing various DSP functions on the outputs and inputs of the system. The processors will need to share channel data with each other, I'm not sure how this could be done. The fact that the system has to process all the channels (and several hundred other values) at a frame rate of 25 times a second (I would prefer higher, 50 would be nice), I think any sort of I2C or SPI interface between processors would be unacceptable. I have thought about using a DSP chip for the application, but what I require is the ability to play several sequences of different lengths and sizes and at different speeds, I need to be able to perform parallel DSP functions on several hundred channels at once (DSP chips are generally not suited to 'parallel' processing, certainly not at this level). Although DMX512 is 8-bit, many parameters in a lighting system are 16-bit, and I feel if all the processing was done with 16-bit values (which if needbe could be rounded down to 8-bit before outputing for some parameters), the flexibilty of the system could be greatly increased (flexibility is a key factor in the design of this system). I will only need a data bus width of 8-bits outside the processor. But would prefer to perform 16-bit calculations etc. inside the processor without having to worry about doing so with 8-bit instructions (which would almost double the work load on the processor). Do you still think I should use multiple processors (if so, how!?!?). I really do think this is a job for a single processor, even though it is essentially a large scale parallel processing application. It would nice to use several of these systems in situations where more than 8 DMX512 ports are needed, but high-speed access to all the addresses in the system will still be needed by all the processors involved... What have I got myself into?!?!? help!!!!!!! Matt. |
| Topic | Author | Date |
| 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| 16-bit 8052 is the Philips XA | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| RE: 16-bit 8052s | 01/01/70 00:00 | |
| HMI -vs- MMI: The Darwin Factor | 01/01/70 00:00 | |
RE: HMI -vs- MMI: The Darwin Factor | 01/01/70 00:00 |



