@ steved
You are correct about wide usage of parasitic power.
I am incorrectly formulate my thoughts. I mean strong pullup support.
There is no difference between externally/parasitically powered modes
if you do not need strong pullup. I will rename that ifdefs.
One more question (it is more addressed to Giovanni). Is it worth
to change all function prefixes and driver name from "onewire" to "OWB"?
1-Wire. Hardware abstracted
-
Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: 1-Wire. Hardware abstracted
In general I prefer short prefixes but it is matter of personal taste.
Giovanni
Giovanni
Re: 1-Wire. Hardware abstracted
I decided to stick with "onewire" prefix. Only external driver declaration is OWD1.
1) "onewire.c" file name is more eye recognizable than "owb.c"
2) I prefer the prefix the same as file name.
Any way. I cleaned code, write comments and integrate it in community repo.
Suggestions, patches and bug reports are welcome.
1) "onewire.c" file name is more eye recognizable than "owb.c"
2) I prefer the prefix the same as file name.
Any way. I cleaned code, write comments and integrate it in community repo.
Suggestions, patches and bug reports are welcome.
Re: 1-Wire. Hardware abstracted
@ Giovanni
During porting to STM32F1xx platform I think about
hiding of pin mode switching into driver. To do that
I need to add port and pin in the driver config structure.
What typedefs I must to use? Are "ioportid_t" and "ioportmask_t"
good for it? PAL driver is not very clean for me.
During porting to STM32F1xx platform I think about
hiding of pin mode switching into driver. To do that
I need to add port and pin in the driver config structure.
What typedefs I must to use? Are "ioportid_t" and "ioportmask_t"
good for it? PAL driver is not very clean for me.
-
Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: 1-Wire. Hardware abstracted
Hi,
You can do like the SPI driver does, it has pin and port references in the configuration structure. The problem is that modes are not necessarily standardized.
Giovanni
You can do like the SPI driver does, it has pin and port references in the configuration structure. The problem is that modes are not necessarily standardized.
Giovanni
Re: 1-Wire. Hardware abstracted
I have tested 1-wire driver on STM32F030. It does not need any modification comparing to STM32F4xx.
Only STM32F1xx needs some #ifdefs because of different alternate function realization.
Only STM32F1xx needs some #ifdefs because of different alternate function realization.
Re: 1-Wire. Hardware abstracted
Hi,
I'm using 1Wire stuff and very interested in a STM32 port.
I didn't find the 1Wire master mentionned below, but I'm very interested in how to make it work using µC resources, such as PWM, in order to increase performance and lower jitter.
1Wire masters are a lot : I'm already using the DS2482-800 8-Channel 1-wire bus master i2c on STM32, it works well and doesn't require an UART (requires I2C, OK).
But 1Wire slave driver would be huge ! For example, in order to cascade many 1-Wire devices. It could use the interface of a R/W memory (write / read buffer) to handle user requests and send responses.
I'm already using http://www.fabiszewski.net/1-wire-slave/ on PIC, which is very basic (based on infinite loops ...), but I'm looking around an interrupt-based port on STM32. Can this 1Wire hardware abstracted master help ?
NB
I'm using 1Wire stuff and very interested in a STM32 port.
I didn't find the 1Wire master mentionned below, but I'm very interested in how to make it work using µC resources, such as PWM, in order to increase performance and lower jitter.
1Wire masters are a lot : I'm already using the DS2482-800 8-Channel 1-wire bus master i2c on STM32, it works well and doesn't require an UART (requires I2C, OK).
But 1Wire slave driver would be huge ! For example, in order to cascade many 1-Wire devices. It could use the interface of a R/W memory (write / read buffer) to handle user requests and send responses.
I'm already using http://www.fabiszewski.net/1-wire-slave/ on PIC, which is very basic (based on infinite loops ...), but I'm looking around an interrupt-based port on STM32. Can this 1Wire hardware abstracted master help ?
NB
Re: 1-Wire. Hardware abstracted
This driver designed as master only. I do not think it can be implemented without
heavy polling approach (bad for multitask environment like ChibiOS).
But you are free to implement slave variant and send pull request.
Note: slave and master must be totally independant drivers.
heavy polling approach (bad for multitask environment like ChibiOS).
But you are free to implement slave variant and send pull request.
Note: slave and master must be totally independant drivers.
Re: 1-Wire. Hardware abstracted
Hi,
I didn't find the sources of the 1Wire Master mentionned in this discussion.
My question is : How can a 1wire driver be optimised using PWM and/or ICU drivers ? (master and slave should have almost the same constraints)
The approach I was thinking about (for 1Wire slave) requires interrupts and events on rising and falling edges. That means 2 interruptions for each single bit received. (Sending bit requires Wait(µs)). Sure this is no good for multithreading :
- Is it compatible with RTs timings on STM32F4 ? (1Wire bit period is about 65µs, 6.5µs for overdrive speed) and what amount of time will remain for other tasks ?
- What are the RT functions which allow thick time measurement (between rising and falling edge) ?
Thank you for the help,
NB
I didn't find the sources of the 1Wire Master mentionned in this discussion.
My question is : How can a 1wire driver be optimised using PWM and/or ICU drivers ? (master and slave should have almost the same constraints)
The approach I was thinking about (for 1Wire slave) requires interrupts and events on rising and falling edges. That means 2 interruptions for each single bit received. (Sending bit requires Wait(µs)). Sure this is no good for multithreading :
- Is it compatible with RTs timings on STM32F4 ? (1Wire bit period is about 65µs, 6.5µs for overdrive speed) and what amount of time will remain for other tasks ?
- What are the RT functions which allow thick time measurement (between rising and falling edge) ?
Thank you for the help,
NB
Re: 1-Wire. Hardware abstracted
Hi,
Code is located in separate repository https://github.com/ChibiOS/ChibiOS-Cont ... /onewire.c
More about community repository you can read here http://wiki.chibios.org/dokuwiki/doku.p ... ty_overlay
Current code generates 1 hardware interrupt per data bit. No polling nor OS's provided Wait(us).
1) Its interrupt pressure and timing requirements comparable with serial driver running on 115200 (87uS).
It becomes extremely sensible to interrupt jitter when used in strong pull up mode. I have never tested
it in overdrive mode because I do not have such slave devices.
2) There is no one. Only PWM hardware interrupts.
About slave. Looks like it may be implemented in following way:
1) Receive uses ICU. 1 interrupt per bit.
2) Transmit uses EXTI for falling edge waiting and GPT in single shot mode for releasing DQ line when
zero bit transmits. 2 interrupts per bit in worst case.
Code is located in separate repository https://github.com/ChibiOS/ChibiOS-Cont ... /onewire.c
More about community repository you can read here http://wiki.chibios.org/dokuwiki/doku.p ... ty_overlay
Current code generates 1 hardware interrupt per data bit. No polling nor OS's provided Wait(us).
1) Its interrupt pressure and timing requirements comparable with serial driver running on 115200 (87uS).
It becomes extremely sensible to interrupt jitter when used in strong pull up mode. I have never tested
it in overdrive mode because I do not have such slave devices.
2) There is no one. Only PWM hardware interrupts.
About slave. Looks like it may be implemented in following way:
1) Receive uses ICU. 1 interrupt per bit.
2) Transmit uses EXTI for falling edge waiting and GPT in single shot mode for releasing DQ line when
zero bit transmits. 2 interrupts per bit in worst case.