1-Wire. Hardware abstracted

[avrhack]

This onewire master driver looks ideal for what I need ie not tying up a U(S)ART. Only down side is that I didn't plan my design very well so I have the onewire connected to PC13 and it's a nightmare to change. Looking at the code for the PWM driver and the Onewire driver though, it seems that all is not lost. PC13 can use timer8 but it's the complementary output ie TIM1_CH1N which won't work with the driver as-written.

Seems that all that's required is to set PWM mode to PWM_COMPLEMENTARY_OUTPUT_ACTIVE_HIGH rather than the hard-coded PWM_COMPLEMENTARY_OUTPUT_ACTIVE_LOW that the Onewire driver uses at the moment. I can obviously hack the code very easily, but I'm sure there must be a neater way to add something to the Onewire driver configuration so the code remains generic and able to use the complementary outputs as well as the main outputs.

Thoughts?

[barthess]

Hi. Glad to know that somebody uses my work.
My code has no PWM_COMPLEMENTARY_OUTPUT_ACTIVE_LOW suppose you are talking about strings like that

Code: Select all

owp->pwmcfg.channels[mch].mode = PWM_OUTPUT_ACTIVE_LOW;

We can add new field in onewireConfig structure storing constant for channel's mode. It is kind of hack but
looks useful. It will be suitable for driving bus through N-channel MOSFET using direct (not complementary)
PWM pin for example.

P.S. PC13 pin is bad choose for 1-wire because of very limited current capabilities of that pin.

[barthess]

Update:
Also I see problem with hardcoded PWMConfig pwm_default_cfg. It is not
hardware agnostic. I want to delete it and use memset(0) in onewireObjectInit() function
with subsequent manual initialization of "frequency" and "period" fields.
Any better ideas?

[Giovanni]

You could make the configuration structure point to an externally-provided PWM configuration structure.

Giovanni

[avrhack]

You could make the configuration structure point to an externally-provided PWM configuration structure.

Giovanni

Yes that sounds like a good idea, and the structure and include the appropriate mode for the PWM i.e. normal or complementary, which broadens the choice of pins and timers that can be used.

[avrhack]

P.S. PC13 pin is bad choose for 1-wire because of very limited current capabilities of that pin.

Actually if I'm going to be honest it's even worse - I actually hooked up to PC14 on my PCB without thinking about it which means no timer support at all for 1-wire, however as PC13 is right next door and unused, I can just bridge them with a blob of solder!

That said, I had also hooked up PB7 driving a p-mosfet for hard pullup so the driving capability is less critical in this particular case.

[barthess]

I had also hooked up PB7 driving a p-mosfet for hard pullup

Suppose you are carefully read my warnings about strong pullup feature and know what are you doing.

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?

[avrhack]

I had also hooked up PB7 driving a p-mosfet for hard pullup

Suppose you are carefully read my warnings about strong pullup feature and know what are you doing.

Wouldn't go that far, but the worst I can do is blow it up

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?

Fantastically quick - you've caught me completely by surprise with that one. I will need to do a little work tomorrow evening on this to give it a try and will let you know thanks!

[barthess]

Wouldn't go that far

https://github.com/ChibiOS/ChibiOS-Cont ... wire.c#L39

but the worst I can do is blow it up

Even worse. It will turn to debugging nightmare with spurious resets and(or) incorrect data.

[avrhack]

Wouldn't go that far

https://github.com/ChibiOS/ChibiOS-Cont ... wire.c#L39

but the worst I can do is blow it up

Even worse. It will turn to debugging nightmare with spurious resets and(or) incorrect data.

Yeah I know it can be tricky, but it ran fine on an Atmel AVR with a bit-bang interface using no other hardware resources though so I'm confident I can make the strong pullup work. For my application it's just a question of enabling it to supply power for a temperature conversion - I have 4 devices on the bus so I send the command telling them all to do a temperature measurement then pull up the bus for the appropriate period.