I think what ppl are doing is putting a diode in and using 2 GPIOs rather than 1 for single wire
Yep (i'm currently using diode & 2GPIO solution) because GIPO direction switch is too slow, but occasional interrupts are causing undesired delays during reading.
I too would be interested in an answer to this - but I suspect the question needs to be expanded to "and pre-emptive scheduling"
Have a feeling that the way in which this could be done (I am interested in interfacing a camera (OV7670) to board) would possibly be via the quark - if it gets activated.
Anyway - will watch thread with interest
Could this sensor be used with the standard one wire protocol? As far as i've seen it needs other timings.
Your idea to disable interrupts is not good, we're not on a mcu. The correct way to work with this sensor under Linux would be a kernel module.
By the way, there are a lot of people who want to use the DS18B20 temperature sensor, which is a typical one wire sensor. The kernel is prepared for this, w1gpio / w1therm are the modules. But also the latest kernel misses them:
'CONFIG_W1 is not set'
In my eyes a 'must have' for an Edison.
Given the necessity for clean timing , I would suggest hooking the sensor to something like the ATtiny25 and have it do the hard work and program it to send data in a more simple way back to the Edison.
I just had a thought which may help get to a solution.
Back in the dim dark past I used to do a lot with VMS - and the scheduler priority was split into 2 sections - timesharing and realtime. Processes running in realtime were non premptable - which is exactly what we want here.
SO if you set a section of code to run in realtime whilst you play with the one wire interface, I am pretty sure that you will be able to do everything you want and be sure that you will not get stomped on.
Note - See warnings about not playing nice <-- (see what I did there) with scheduler priorities on Unix/Linux (for example are real time clocks updated.............
Sorry it took me so long, but it was very busy week :/
Anyway... i used pthread_setschedparam with SCHED_FIFO instead of chrt, without success...
I believe that here https://rt.wiki.kernel.org/ could be an answer to my problem, but i may be wrong.
But there's also still an option with kernel module as mmi mentioned...
I've never written one, but i guess i'll have to look into it
Dumb question but when you set the shed param, did you elevate the priority.
The way I look at it is the process (lets say you are emulating SPI) would be
1. Set interrupt on SPI CS
2. In ISR, elevate priority
3. Poll SPI data until CS goes low;
4. Lower pririty
5. Return from interrupt.
I know, I know - this breaks rule 1 of interrupts - get in and out as quick as possible!
i gave up on this idea of building own kernel module...
anyway, i just tried new MCU SDK and it works like a charm