Error in presence() ?!

[Giermann]

Is this code working for someone at all? I couldn't get my DS9490 to recognize my custom slave. Reading what happens shows me, that 'waitForRequest()' aborts when 'presence()' doesn't return TRUE. Looking at the code, it actually returns nothing... what's wrong?

Is there any working tiny 1-Wire Slave library for Arduino GUI around here?

[MarkusLange]

Yes I know looks and acts wired. I have added a few things and add the Interrupt based trigger the original is from an russian page. I'm on my way to recreate it from scratch when ever I find some time.

[orgua]

hi @Giermann i have rewritten most of the code and tried to include some sensors. could you test your code with this lib: https://github.com/orgua/OneWireHub

[MarkusLange]

WOW orgua, you and Shagrat2 really did amazing thinks on the crap I had put online, I'm just at the beginning looking by it. You put so many stuff in it I only dreamed of

[orgua]

thanks markus, i think it's still a bit early to be used, but the open tasks should be done within this week. if you have ideas and energy we can join forces. it would also be interesting to test it on a real system. i only have remote access to an loxone-house-automation which supports just a subset of the sensors. so i could only verify the ds18b20 so far. the rest is handled by onewire-lib and special testcases.

[Giermann]

Wow - cool! I've started my own implementation of BAE910 (which is supported by OWFS and gives many possibilities for my slave), but the worst problem was timing, I guess while calculating the CRC16.

I may try another test case using your DS2408, which also needs 16 bit CRC. I'm targetting the ATtiny85, which might not be as fast as the ATmega on my Arduino, so I'll run some tests and report the results. While blaming the time needed for CRC calculation, I also thought about using an on-the-fly CRC calculation, as I found it in Tobias Muellers implementation of an DS2423 [1]. Maybe, this would also speed up your code.

Could you please try to minimally explain the concept of having a OneWireHub and connect multiple devices to it? What's the advantage of this? The only thing I see, is implementing multiple slaves on a single µC. But it might be helpful for Users to describe the concept...

[1] https://www.tm3d.de/index.php/1-wire-device-mit-avr (German)

[orgua]

i will look into the code - seems to me that we three speak german? CRC can be either fast or "small". the current implementation is small. so maybe there is still some potential. the motivation for the hub is to emulate ICs and offer a shared code base. without much overhead one µC can emulate more than one IC simultaneously. my main goal is to use modern sensors (mainly I2C or SPI Interface) and translate their measurements into one or more emulated ds2438 (4x 16bit). This feature would remove limitations on modern house-automation-systems. You are right. this motivation should be placed on the project.

[MarkusLange]

Yes I think we all speek german, I see you remove the Interrupt part, I will post my last expriences there below, I've tryed to create a full none-blocking reset and presence sequence, that works in the one or other way but an none-blocking bit transmission did not work or not in the way I did it.

BareMinimum_Onewire_last_done_new_plain (ino).txt

[orgua]

@MarkusLange : i will look into it this week.

@Giermann : first , thanks for the link! I wanted to implement a state machine and this code already has it in some way. Second, i have three ideas for your problem:

1. load balancing: combine sendByte() and recvByte() with the crcUpdate(). Both already have a 0to7-for-loop. You can even do it in the idling lowphase while sending a bit. the standard supports clockstretching from 65 to 120 µs per bit. So every little uC should get it done
2. Use pycrc to generate a crc16 with lookup-table. Maybe 5times faster, but 256*2byte lookup needed
3. Try this CRC speed comparison:

Test-Code for faster CRC-Calculations
CRCing 254 bytes 
Var 1 took 2476 us, got 127B
Var 2 took 1384 us, got 127B
Var 3 took 1880 us, got 127B
Var 4 took 1528 us, got 127B

--> code is in crc-comparison

[orgua]

hi markus, i like that the irq-version would be non-blocking, but it's always hardware-dependent and will limit the pin-choice. it would be interesting though to solve the interrupt driven data-transmission. there are enough ticks in one time-slot, even with <=8MHz. can i use your code-example?

[MarkusLange]

Yes of course, my expirience so far it works without other slaves when I use the interrupt driven data-transmission, restet and presence works so far with or without other slaves

[orgua]

i tried some things and i don't find a nice solution for the hub. it will end in a big mean state-machine because some sensors have to react during the transmission. it would be possible, but i have no clue how to get it into a maintainable model. irq-handling the reset-, presence- (and maybe search-) routine would be a nice addition:

• the poll() can be called less often
• poll() would be less blocking, only on real communication
• µC can sleep when bus is unused
• poll() can take over (and has to at a certain time)

[orgua]

hi @Giermann, can you recommend the DS9490R? btw: i included the faster crc-ing in the latest commits. instead of 10µs overhead between bytes, there are 0.9µs overhead between bits now. timings are taken from an atmega328@16MHz. i included it in the ds2408, but don't know if it is feature-complete enough.

[Giermann]

Could you both please pick up my mail address [deleted]

I guess, a private discussion makes much more sense in this stage... :)

[GitLang]

Re: [OneWireSlave] Error in presence() ?! (#7)

Hello Sven,

It would be a shame for this discussion to move to private email, rather than being recorded in the archive for others to follow.

Wednesday, February 24, 2016, 3:11:35 PM, you wrote:

Could you both please pick up my mail address from here: https://www.dropbox.com/s/fxdiha2r3gbrm6o/mailadresse.txt?dl=0 I guess, a private discussion makes much more sense in this stage... :) — Reply to this email directly or view it on GitHub.

Best regards, Git                            mailto:gitlang@hotmail.com

[MarkusLange]

i tried some things and i don't find a nice solution for the hub. it will end in a big mean state-machine because some sensors have to react during the transmission. it would be possible, but i have no clue how to get it into a maintainable model. irq-handling the reset-, presence- (and maybe search-) routine would be a nice addition:

the poll() can be called less often
poll() would be less blocking, only on real communication
µC can sleep when bus is unused
poll() can take over (and has to at a certain time)

Yeah I know but an stable reset detection is possible also the pull down detection from the presence detection will work

[Giermann]

@Gitlang: please don't get me wrong! I'd publish everything that results from every (private) conversation - but currently I'm trying to merge everything we have: Markus first implementation, my (still local) changes and Orguas new attempt.

I'd like to have small working group testing different things before "we" publish the next version.

@orgua: I'll do some tests with your code on my ATtinys in the next days, maybe this weekend. And YES, I'm very happy with my DS9490Rs. I also have one LinkUSB, but do not see any advantage - apart from the RJ-45 connector, which is quite easier to use if you have "retired" patch cables...

[Giermann]

It would be a shame for this discussion to move to private email, rather than being recorded in the archive for others to follow.

Due to orguas intense work, you all might want to follow the development on his repository: https://github.com/orgua/OneWireHub

Most of the things are already working, at least on ATmega chips. Orgua is still investigating some time issues on ATtinys, but I'm sure he gets it running soon.