Page 4 of 5
Re: 1-Wire. Hardware abstracted
Posted: Mon Jan 25, 2016 11:33 pm
by avrhack
barthess wrote:Any way I have pushed changes to github. But I am unable to test them in hardware today.
@avrhack could you test it? Are changes suited your thoughts?
So what I've done with your code is this:
- Ran the pre-changed code against PB7; that works perfectly with timer 4 ch 1+2, AF2
- Ran the changed code with the updated local PWM config etc. set up to work as the original code did, still against PB7; that works perfectly
- Ran the changed code set to use PC13, no changes other than port, pin, AF (4 instead of 2), timer (1 instead of 4) and channels (0,1 instead of 1,2); that doesn't work unfortunately
- Cleared the PC13 pad using normal Chibi pad commands and then set it, to confirm it wasn't a drive-strength issue with that pin per your earlier advice. That works perfectly as a reset and on my logic analyser I can also see the 'presence' pulse reply from the device so confirming that the pin drive is fine
So I conclude that a) my hardware is working on both PB7 and PC13, but something it not working with the PWM set to use the complementary output.
What I need to do next is to single-step through the code with the debugger but I've run out of time this evening and I'm away for work for a few days so I will continue my investigations later in the week. Obviously if I can find where the issue lies and whether it's the configuration parameters I've given as opposed to the code changes you've made then great. If I think it's something in the code I'll let you know of course. And hopefully I won't find that it's just the timer can't work in the way I need it do, using a complementary output only!
More to follow
Re: 1-Wire. Hardware abstracted
Posted: Thu Jan 28, 2016 10:15 pm
by avrhack
I had more time this evening to run things through the debugger and I've found and fixed the issue - working great with your new code using PC13 barthess - many, many thanks for such a quick fix!
The issue was that the PWM_COMPLEMENTARY_OUTPUT_ACTIVE_LOW parameter only works if STM32_PWM_USE_ADVANCED is TRUE in mcuconf.h. As soon as I had made that change everything sprung into life beautifully.
Now all I have to do is get strong pullup working - I know you're such a fan of that
In case someone else wants to try this, the code snippet for the setup stuff is......
Code: Select all
#define ONEWIRE_MASTER_CHANNEL 0
#define ONEWIRE_SAMPLE_CHANNEL 1
#define ONEWIRE_PORT GPIOC
#define ONEWIRE_PIN 13
#define ONEWIRE_PAD_MODE_ACTIVE (PAL_MODE_ALTERNATE(4) | PAL_STM32_OTYPE_OPENDRAIN | PAL_STM32_PUDR_PULLUP)
#if ONEWIRE_USE_STRONG_PULLUP
static void strong_pullup_assert(void)
{
palSetPadMode(ONEWIRE_PORT, ONEWIRE_PIN, PAL_MODE_ALTERNATE(4) | PAL_STM32_OTYPE_PUSHPULL | PAL_STM32_PUDR_PULLUP);
}
static void strong_pullup_release(void)
{
palSetPadMode(ONEWIRE_PORT, ONEWIRE_PIN, PAL_MODE_ALTERNATE(4) | PAL_STM32_OTYPE_OPENDRAIN | PAL_STM32_PUDR_PULLUP);
}
#endif /* ONEWIRE_USE_STRONG_PULLUP */
static PWMConfig pwmCfg =
{
.frequency = 1000000,
.period = 960,
.callback = NULL,
.channels = {
{PWM_OUTPUT_DISABLED, NULL},
{PWM_OUTPUT_DISABLED, NULL},
{PWM_OUTPUT_DISABLED, NULL},
{PWM_OUTPUT_DISABLED, NULL}
},
.cr2 = 0,
.dier = 0
};
static const onewireConfig ow_cfg =
{
.pwmd = &PWMD1,
.pwmcfg = &pwmCfg,
.pwmmode = PWM_COMPLEMENTARY_OUTPUT_ACTIVE_LOW,
.master_channel = ONEWIRE_MASTER_CHANNEL,
.sample_channel = ONEWIRE_SAMPLE_CHANNEL,
.port = ONEWIRE_PORT,
.pad = ONEWIRE_PIN,
#if defined(STM32F1XX)
.pad_mode_idle = ONEWIRE_PAD_MODE_IDLE,
#endif
.pad_mode_active = ONEWIRE_PAD_MODE_ACTIVE,
#if ONEWIRE_USE_STRONG_PULLUP
.pullup_assert = strong_pullup_assert,
.pullup_release = strong_pullup_release
#endif
};
Re: 1-Wire. Hardware abstracted
Posted: Fri Jan 29, 2016 5:57 pm
by barthess
Code: Select all
static PWMConfig pwmCfg =
{
.frequency = 1000000,
.period = 960,
Just to be clear. That fields will be overwritten by driver so you can safely
set them to 0 before driver start.
Re: 1-Wire. Hardware abstracted
Posted: Sat Jan 30, 2016 5:56 pm
by avrhack
barthess wrote:Code: Select all
static PWMConfig pwmCfg =
{
.frequency = 1000000,
.period = 960,
Just to be clear. That fields will be overwritten by driver so you can safely
set them to 0 before driver start.
Understood and thanks again for your great work - several sensors all working perfectly evening in parasitic power mode with strong pullup. I've looked at the timing on my logic analyser and it's perfect - I know you don't like it but it really works well even in a setup like mine where I have a separate p-mosfet driven from a different GPIO to get more power into the pullup.
Re: 1-Wire. Hardware abstracted
Posted: Sat Jan 30, 2016 7:46 pm
by barthess
avrhack wrote:I know you don't like it
I am not dislike it. I just want to aware people to not use it when
possible.
Any way I am happy to know that your setup works perfectly. Could you
shortly describe what your device is? What the MCU? What and how may
sensors (not only 1-wire) in it? How high is MCU load during data acquisition?
I want to know approximate system able to work correctly in strong pull up mode.
Re: 1-Wire. Hardware abstracted
Posted: Sat Jan 30, 2016 10:07 pm
by avrhack
barthess wrote:Could you
shortly describe what your device is? What the MCU? What and how may
sensors (not only 1-wire) in it? How high is MCU load during data acquisition?
I want to know approximate system able to work correctly in strong pull up mode.
It's an STM32F303CC running at 72MHz at the moment with only 2 sensors on a breadboard. I haven't checked the MCU load - the acquisition using your library is running in its own thread so I suspect during the 750mS conversion time there's very little load. How do you want me to measure this as I'm happy to do some additional instrumentation if that helps given your code is so useful to me.
Thanks.
Re: 1-Wire. Hardware abstracted
Posted: Sat Jan 30, 2016 11:08 pm
by barthess
Measurement of CPU load is simple in general. Just analyze how much
of time consumed by the idle thread compared to overall time.
But your current design just acquire data from sensors and do some
basic data transformation.
Lets do it in other way. Let me know if your real life project
starts to generate 1-wire related failures.
Re: 1-Wire. Hardware abstracted
Posted: Thu Feb 18, 2016 5:16 am
by avrhack
barthess wrote:Measurement of CPU load is simple in general. Just analyze how much
of time consumed by the idle thread compared to overall time.
But your current design just acquire data from sensors and do some
basic data transformation.
Lets do it in other way. Let me know if your real life project
starts to generate 1-wire related failures.
Just to let you know that the real life application has run flawlessly for the last few weeks with 4 sensors on a relatively long (7m) onewire bus with parasitic power and strong pullup.
Re: 1-Wire. Hardware abstracted
Posted: Thu Feb 18, 2016 8:37 am
by barthess
@avrhack
Thank you for real life application report!
Re: 1-Wire. Hardware abstracted
Posted: Tue Mar 22, 2016 11:55 pm
by dismirlian
Hi barthess,
Thanks for the 1-wire driver, it works perfectly!
Browsing through the code, I've seen this:
Code: Select all
pwmEnableChannel(pwmd, mch, ONEWIRE_RESET_LOW_WIDTH);
//[point 1]
pwmEnableChannel(pwmd, sch, ONEWIRE_RESET_SAMPLE_WIDTH);
//[point 2]
pwmEnableChannelNotification(pwmd, sch);
//[point 3]
osalSysLock();
osalThreadSuspendS(&owp->thread);
osalSysUnlock();
What would happen if a higher-priority thread preempts this one in points 1, 2 or 3, and performs a long task? I think that the driver could cease to work properly. For example, in point 3, the thread could be suspended *after* the callback was called. I haven't studied the code well enough. Do you think this could be a problem?
If this is a problem, one possibility would be:
Code: Select all
pwmEnableChannelNotification(pwmd, sch);
osalSysLock();
pwmEnableChannelI(pwmd, mch, ONEWIRE_RESET_LOW_WIDTH);
pwmEnableChannelI(pwmd, sch, ONEWIRE_RESET_SAMPLE_WIDTH);
osalThreadSuspendS(&owp->thread);
osalSysUnlock();
Thanks again for sharing your work.
Diego.