eLua design change to allow synchronized PWM channel start?
Locked
 
|
Martin Guy |
eLua design change to allow synchronized PWM channel start?
|
Hi
I'm looking at the AVR32 PWM stuff, and one thing that strikes me is that the platform allows synchronized starting of several PWM channels, but the eLua module interface to pwm forces you to start them one by one. Other eLua module functions can apply to a variable list of things, for example the functions of the pio.* module which can set/clear a range of pins in one operation. I thought it would be best to discuss this here first, since it is a change to the eLua API. To avoid breaking existing code, this can be applied to functions where the PWM channel id is the last (or only) parameter. This is fine for pwm.start(id) and pwm_stop(id). pwm_start() is exactly the one that makes an operational difference, since doing synchronized starting is impossible at present. pwm.setup(id, freq, duty) cannot be extended in this way unless it accepts a number id or a table of ids as the first parameter, but it seems a bit strange. Is changing the frequency and/or duty cycle of several PWM output synchronously (or as close to synchronously as can be achieved in practice) a useful thing to be able to do? That only leaves pwm.setclock( id, frequency ) and pwm.getclock( id ) - I doubt that extending these is useful. Anyway all the existing platforms except one have a common base clock frequency for all PWM channels. Thoughts? Sorry, I've never used PWM in practice so only see what is possible, not what is actually useful in practice. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Marcelo Politzer |
Re: eLua design change to allow synchronized PWM channel start?
|
|
2011/4/3 Martin Guy <[hidden email]>:
> Hi > I'm looking at the AVR32 PWM stuff, and one thing that strikes me > is that the platform allows synchronized starting of several PWM > channels, but the eLua module interface to pwm forces you to start > them one by one. > > Other eLua module functions can apply to a variable list of things, > for example the functions of the pio.* module which can set/clear a > range of pins in one operation. > > I thought it would be best to discuss this here first, since it is a > change to the eLua API. > > To avoid breaking existing code, this can be applied to functions > where the PWM channel id is the last (or only) parameter. > > This is fine for pwm.start(id) and pwm_stop(id). pwm_start() is > exactly the one that makes an operational difference, since doing > synchronized starting is impossible at present. > > pwm.setup(id, freq, duty) cannot be extended in this way unless it > accepts a number id or a table of ids as the first parameter, but it > seems a bit strange. > Is changing the frequency and/or duty cycle of several PWM output > synchronously (or as close to synchronously as can be achieved in > practice) a useful thing to be able to do? > > That only leaves pwm.setclock( id, frequency ) and pwm.getclock( id ) > - I doubt that extending these is useful. Anyway all the existing > platforms except one have a common base clock frequency for all PWM > channels. > > Thoughts? Sorry, I've never used PWM in practice so only see what is > possible, not what is actually useful in practice. Well, For motor control you sure want the PWMs to be in sync, at leas 2 of them for brushed DC. Even thou it doesn't seem a typical eLua application might be handy to someone. > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- []s, Marcelo _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
On Mon, Apr 4, 2011 at 12:02 AM, Marcelo Politzer <[hidden email]> wrote: 2011/4/3 Martin Guy <[hidden email]>: If people feel a need for this we can definitely extend pwm.stat() and pwm.stop() to accept more than one ID, this is simple. I agree the API is not consistent at times. Most of it was born out of pragmatic reasons; I saw a good reason for a number of GPIO pins to change their state at the same time so I implemented that. We are still before 1.0 so the API can change unexpectedly.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: eLua design change to allow synchronized PWM channel start?
|
|
My colleague Antonio (who doesn't follow elua-dev) writes:
On 4 April 2011 15:53, antonio cingolani <[hidden email]> wrote: > Ciao Martin, > we have modified Vga module, now you can choose to drive > Max 4411 (Audio chip) whit Propeller or UC3A, so we need > to start at least 2 PWM at the same time to synchronize the right > and left audio channel. When you design a motor control board > this synchronization is also required. > Another reason to have the synchronism between PWM channel > is when you driving 4 transistors in full-bridge configuration > (switch on /off the transistor 2 at time) and, if not synchronized, > the transistors break out surely. > However, to perform all this, a little of speed is required... > eLua is enough fast? When you use the PWM in the way indicated > above (motor control, and full-bridge configuration) must use the > ADC, execute some calculations and change the PWM duty for each > PWM channel used (at the same time) before the transistor blow up. > I think is correct to change eLua PWM module to allow global change > (start, clock, duty ecc...) but how far we can use PWM is possible know > only after tested it. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: eLua design change to allow synchronized PWM channel start?
|
|
In reply to this post by BogdanM
Hi,
On Mon, Apr 4, 2011 at 07:46, Bogdan Marinescu <[hidden email]> wrote: Hi, Tks for the thoughts Martin. Because of the large (and growing) number for supported platforms and architectures, the eLua platform-interface needs sometimes to be limited to what is common to all (or most). This doesn't mean we can extract the best from every target. For features found on some specific platforms, we have the Platform-Specific modules concept (See Platform Modules on our Main Menu options. Sorry, the sub-link system is not ideal {yet} to send you a link). I'm not sure if this is the case, as what you mentioned seem to exist in most platforms but, if not, you can write a module like avr32.pwm. to include functions specific to this platform. We've done it already, for some weird initialization taks on mbed and str912, for the str912 Real Time Clock and for supporting the EK-LM3Sxxxx RIT OLED displays. As Bogdan has mentioned, we don't mind (too much :) changing the API to support better models, even if this breaks some code and this is why we haven't called any of our versions a eLua 1.0 yet. But this should be done very carefully, not only to support one very used platform but to make sure the changes will bring benefits to all. If not possible, there will always be the handy solution of creating platform-specific modules.
Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
On Sun, Apr 3, 2011 at 1:19 PM, Martin Guy <[hidden email]> wrote:
> Hi > I'm looking at the AVR32 PWM stuff, and one thing that strikes me > is that the platform allows synchronized starting of several PWM > channels, but the eLua module interface to pwm forces you to start > them one by one. > > Other eLua module functions can apply to a variable list of things, > for example the functions of the pio.* module which can set/clear a > range of pins in one operation. ADC allows this as well, although in all cases (currently) this is effectively multiplexing a single ADC with multiple ports. > > I thought it would be best to discuss this here first, since it is a > change to the eLua API. > > To avoid breaking existing code, this can be applied to functions > where the PWM channel id is the last (or only) parameter. > > This is fine for pwm.start(id) and pwm_stop(id). pwm_start() is > exactly the one that makes an operational difference, since doing > synchronized starting is impossible at present. > > pwm.setup(id, freq, duty) cannot be extended in this way unless it > accepts a number id or a table of ids as the first parameter, but it > seems a bit strange. The adc function sample will take a table of channels to initiate "parallel" multiplexed sampling on a set of channels, such as adc.sample({0,1,2}, 4) would get 4 samples on channels 0, 1 & 2. We also do have some syntax with some messaging modules like spi.write that will take multiple data that will serially send multiple data: spi.write(id, data1, [data2], ..., [datan] ). In some ways I think that the difference here between passing multiple additional parameters, versus multiple items in a single item (a table) might be one way to imply differences between parallel and serial processing? > Is changing the frequency and/or duty cycle of several PWM output > synchronously (or as close to synchronously as can be achieved in > practice) a useful thing to be able to do? > > That only leaves pwm.setclock( id, frequency ) and pwm.getclock( id ) > - I doubt that extending these is useful. Anyway all the existing > platforms except one have a common base clock frequency for all PWM > channels. > > Thoughts? Sorry, I've never used PWM in practice so only see what is > possible, not what is actually useful in practice. I've not personally had a need for this sort of synchronization, however, I certainly appreciate that regardless of whether this would translate into working on every piece of hardware as expected, it would mean that one could start PWM output with one command rather than multiple ones if multiple channels were needed, which I think does have some value. > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: eLua design change to allow synchronized PWM channel start?
|
|
In reply to this post by Dado Sutter
On 4 April 2011 21:08, Dado Sutter <[hidden email]> wrote:
> Because of the large (and growing) number for supported platforms and > architectures, the eLua platform-interface needs sometimes to be limited to > what is common to all (or most). > This doesn't mean we can extract the best from every target. For features > found on some specific platforms, we have the Platform-Specific modules > concept (See Platform Modules on our Main Menu options. Sorry, the sub-link > system is not ideal {yet} to send you a link). > I'm not sure if this is the case, as what you mentioned seem to exist in > most platforms but, if not, you can write a module like avr32.pwm. to > include functions specific to this platform. We've done it already, for some > weird initialization taks on mbed and str912, for the str912 Real Time Clock > and for supporting the EK-LM3Sxxxx RIT OLED displays. Thanks for the thought. In fact, the AVR32 PWM has some extra stuff that people might need: - alignment: left-aligned waveform or centred (symmetrical) waveform - polarity: each cycle starts low then goes high, or starts hight then goes low - generating an interrupt at the end of each cycle of a waveform which I guess are not portable between platforms. However, for now I'm just trying to get something that works at all. These platform-specific refinements can happen in a second moment. Conversely, if some but not all of the platforms support some feature, say centre-aligned waveforms, then do we end up with at91.pwm.alignment() avr32.pwm.alignment() and other_board.pwm.alignment()? In the specific case we are talking about here, the API change to start/stop (/configure?) several PWM outputs in one call seems orthogonal to the other modules, as well as being a more convenient syntax, and if a platform can't do it in reality, it can just start several channels in a for loop in C, which will stil be more closely aligned than doing it with a for loop in Lua. > As Bogdan has mentioned, we don't mind (too much :) changing the API to > support better models, even if this breaks some code and this is why we > haven't called any of our versions a eLua 1.0 yet. Sometimes the API needs redesigning (or refining) in the light of practical experience, but given the small amount of code already written for eLua, we should be able to do this without too much pain. It's kinder to users if we ensure that existing code that uses the old interface either continues working with some legacy interface, or fails to compile with an error. > But this should be done very carefully, not only to support one very used > platform but to make sure the changes will bring benefits to all. If not > possible, there will always be the handy solution of creating > platform-specific modules. Of course, although the API already contains stuff that cannot be implemented on all platforms. For example, the PWM interface thinks you can set the clock frequency independently for each channel, both at the Lua level and the C interface: but none of the platforms can do this. Changing the clock of one channel changes it for all of the others (or "some of the others" in the AT91 case!) - something users need to be aware of while writing for a specific platform. Already, platform-independent code is difficult in eLua. Look at led.lua for example. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: eLua design change to allow synchronized PWM channel start?
|
|
In reply to this post by Marcelo Politzer
On 3 April 2011 23:02, Marcelo Politzer <[hidden email]> wrote:
> Well, For motor control you sure want the PWMs to be in sync, at leas 2 of them > for brushed DC. Even thou it doesn't seem a typical eLua application > might be handy > to someone. Forgive me, I don't understand this. All I can find on the web is examples that just run a DC motor at half power by having the power on for half the time. What kind of motor control uses two synchronised PWM channels? M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: eLua design change to allow synchronized PWM channel start?
|
|
In reply to this post by Martin Guy
On Wed, Apr 6, 2011 at 06:23, Martin Guy <[hidden email]> wrote:
Basically yes. With the new, more powerful and more and more specific peripheral beasts of today's MCUs, it becomes hard to support everything in a standard way. But we must try to extract the most from the possibly-portable features, even if they are not exactly the same and eventually loosing some functionality, and add support for platform-specific ones in modules like the ones you've mentioned. In the specific case we are talking about here, the API change to Right.
Yep. Finished and working applications can continue to run on older versions too, just like it happens with lots of Lua apps. It's kinder to users if we ensure that existing code that uses the old Yes. We can offer legacy-interfaces modules (be it Lua-C binds or plain Lua massage code) if really needed. Usually, the growing clock speeds with time tend to absorb the extra performance penalties for these solutions.
Humm, right and this doesn't sound too good for me. I'm not sure if there is a clear or really widely portable solution for this though. It would be nice to hear more thoughts on this. Already, platform-independent code is difficult in eLua. Look at Well, I think this is actually a nice example of platform-independend code. Of course, because of the pins assignments that may differ even within different models of the same family sometimes, there will always be a need for a code section to "bind" the program's I/O with the actual pins/ports used. This is easily and nicely done in simple structures in Lua, be it with the ugly big IF contruction of this example (done to make it simple for starters) or with nice Lua tables. Still, the rest of the code runs untouched among all supported platforms. For small applications like the tiny led.lua example, the size of this "bind" section can look big compared to the rest of the code. But for serious applications it disappears on a Lua table definition or even a small function to do the job. M Best Dado _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Marcelo Politzer |
Re: eLua design change to allow synchronized PWM channel start?
|
|
In reply to this post by Martin Guy
2011/4/6 Martin Guy <[hidden email]>:
> On 3 April 2011 23:02, Marcelo Politzer <[hidden email]> wrote: >> Well, For motor control you sure want the PWMs to be in sync, at leas 2 of them >> for brushed DC. Even thou it doesn't seem a typical eLua application >> might be handy >> to someone. > > Forgive me, I don't understand this. All I can find on the web is > examples that just run a DC motor at half power by having the power on > for half the time. > What kind of motor control uses two synchronised PWM channels? > > M > There is a circuit called H-bridge used to control a motor in a reversible way (run to both sides). There are a few ways for the mcu to drive this circuit, one of them is using a PWM on one side of this bridge, and its complement on the other side. I don't know if you know electronics, but on the bottom of this page there is a table with values of A and B. There you have a Not Allowed HI HI, where you need sync to make sure wont happen. Or... A better circuit :) http://www.cadvision.com/blanchas/hexfet/np-s.htm Hope it helps. -- Best, Marcelo _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: eLua design change to allow synchronized PWM channel start?
|
|
On 6 April 2011 19:28, Marcelo Politzer <[hidden email]> wrote:
> 2011/4/6 Martin Guy <[hidden email]>: >> What kind of motor control uses two synchronised PWM channels? > > There is a circuit called H-bridge used to control a motor in a > reversible way (run to both sides). > > I don't know if you know electronics, but on the bottom of this page > there is a table with values of > A and B. There you have a Not Allowed HI HI, where you need sync to > make sure wont happen. > > Or... A better circuit :) > http://www.cadvision.com/blanchas/hexfet/np-s.htm Thanks. Yes, making the motor go backwards and forward at the same time would not be a good idea :) But I think this is a different issue from the problem I am considering. To drive that circuit you would enable one (and only one) of the PWM outputs (A or B), to run the motor at variable speeds forwards or backwards. I'm talking about starting several PWM outputs simultaneously, exactly in phase with each other. Antonio mentioned an application that does need phase synchrony: using the PWM outputs to produce stereo (or multi-channel) audio, as simple DACs. For that, starting the two channels at the same time is essential. In the datasheet they mention the posibility of centre-aligned non-overlapping PWM outputs, for which this synchronous starting is supposed to be particularly useful. Of course I don't have any idea what that would be useful *for*... time to take a course in PWM applications... M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
On Wed, Apr 6, 2011 at 12:23 PM, Martin Guy <[hidden email]> wrote:
It's a thin line on the platform interface. If most of the platform support the feature it will probably stick directly to the platform interface. If not it will become a platform specific module even if these tend to repeat themselves.
In the specific case we are talking about here, the API change to Some platforms might be able to do it in reality, but it will be always one of these pesky "platform specific" functions.
Yes, that's exactly the plan :) It's kinder to users if we ensure that existing code that uses the old interface either continues working with some legacy interface, or
Yes, something has to be implemented for situations like this. Two main ways I can think of: 1. document all of these platform-specific gotchas on the wiki
2. add warnings directly in eLua (configurable, like levels and on/off). I'd go with 2 personally. Already, platform-independent code is difficult in eLua. Look at That's an example of bad implementation actually. What we would ideally do is a more object-oriented approach, for example have a .lua file for each board in turn (for example mbed.lua) that defines peripherals related to that board. For example:
LED1 = pio.PA_6 LED2 = pio.PA_5 SW1 = pio.PB_0 ....... These files will be on the romfs of the eLua image. Then the led.lua would just need to require( pd.board() ) and use LED1. It suddenly gets much simpler :)
Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
Dudes, I don't have anything against hardware discussions on the eLua list (quite on the contrary) but please don't hijack the thread.
Best, Bogdan
On Wed, Apr 6, 2011 at 8:55 PM, Martin Guy <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: eLua design change to allow synchronized PWM channel start?
|
|
On 6 April 2011 19:59, Bogdan Marinescu <[hidden email]> wrote:
> Dudes, I don't have anything against hardware discussions on the eLua list > (quite on the contrary) but please don't hijack the thread. I found the info informative and relevant, since it was a potential need for synchronized PWM outputs. The fact that it wasn't an example of what I meant was my bad because I hadn't explained what I meant by "synchronized" (i.e. in-phase waveforms, rather than co-operating outputs). M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |