Skip to content

1-Wire extensions and fixes for reprogramming GoodFET42#39

Open
andyjpb wants to merge 3 commits intotravisgoodspeed:masterfrom
andyjpb:master
Open

1-Wire extensions and fixes for reprogramming GoodFET42#39
andyjpb wants to merge 3 commits intotravisgoodspeed:masterfrom
andyjpb:master

Conversation

@andyjpb
Copy link

@andyjpb andyjpb commented Jul 28, 2018

As per commit messages.

  • Add support for 1-Wire SearchROM
  • Fixup the build so that make reinstall works on my GoodFET42.

andyjpb added 3 commits July 28, 2018 18:30
Signed-off-by: Andy Bennett <andyjpb@ashurst.eu.org>
Signed-off-by: Andy Bennett <andyjpb@ashurst.eu.org>
Signed-off-by: Andy Bennett <andyjpb@ashurst.eu.org>
@travisgoodspeed
Copy link
Owner

I think I can merge this with only minor changes. Which one-wire device should I order to test it on?

@andyjpb
Copy link
Author

andyjpb commented Aug 1, 2018

I've been using the DS18B20 temperature probe but it should work with almost any 1-wire device as SearchROM is one of the basic commands in the protocol. It's one of the multi-drop commands tho' so ideally you want to have two or more devices on the bus.

Let me know about the changes and I can make them.

In other news, I'm having trouble getting things working with all the other temperature probes that I've tried so haven't been able to test the SearchROM as much as I'd like. They don't even respond to ReadROM which is already supplied in the code. Perhaps it's something to do with the long wires they have (the one that works has a short lead whereas all the other ones have 3 -> 5 m leads). I also tried powering them off my own Vcc and just connecting data and GND to the GoodFet but that didn't work either. They respond to the reset pulse but then don't send any other data: the bus just seems to stay high.

I hooked things up to the logic analyser. delay_us seems to be mostly generating delays that are twice as long as they need to be, except for 5us delays that come out at about 6us. However, the delays generated aren't always consistent so the timeslots vary in length by a few% each time.
I changed the owe firmware code to use delay_tick instead and the delays are better but still not perfect and now the short (5us) delays have the worse tolerance. Given this and the trouble I had reprogramming the device (as per Makefile patch) do you think I have a problem with my GoodFET? Is there any way to test it? I built it to reprogram the CC430 watch dongle into an RFCat but haven't used it for anything else.

The graphs in the MSP430 datasheet seem to suggest the IO pins are good for a few mA but the pullup is much larger than the iButton guide specifies. I'll have to rewrite the code to use an external pullup tho' as just adding more resistors between data and Vcc doesn't work because when the GoodFET pulls the bus low it does it by connecting the internal resistor in a pulldown configuration and thefore we end up with a voltage dividor with the small, external pullup on the top and the large internal pullup on the bottom and therefore the pin doesn't go down enough.

Is there a way of uploading some new firmware at runtime without reflashing the device each time?

Thanks for your help and all your efforts developing the GoodFET in the first place!
Let me know if you can get the SearchROM code working with devices that you have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants