OK, I added a second OneWire bus as further proof of concept. In the following trace, Green and Yellow are the two OneWire buses, and Blue is still the ADC/DMA ISR. Each bus has just one DS18B20 on it and you can see both buses happily chug along sucking in the 9 byte scratchpad even as the CPU heads off to work on the V,I maths. The pinout for the two OneWire buses is as posted a few posts back (CPU pin diagram).
The output now looks like:
emonTxshield Demo 1.11 Patch PA0 through to PB14 for V!!! 1Wire DMA buffs: 384 bytes ADC DMA buffs: 11200 bytes CPU temp: 35C, Vdda: 3304mV bus0 status: 0xe0, crc: ok, temp: 23.188 bus1 status: 0xe0, crc: ok, temp: 23.062 3: Vrms: 1309.87, Irms: 1309.53, Papp: 1715312.94, Preal: 1715312.00, PF: 1.000, Count:84013 4: Vrms: 1309.87, Irms: 1309.29, Papp: 1714994.33, Preal: 1714994.00, PF: 1.000, Count:84013 5: Vrms: 1309.87, Irms: 1309.15, Papp: 1714821.24, Preal: 1714820.00, PF: 1.000, Count:84013 12: Vrms: 1309.92, Irms: 1309.28, Papp: 1715058.29, Preal: 1715057.00, PF: 1.000, Count:84015
Note carefully the comment in the code about the DS18B20 code:
// Reset both 1wire buses to start a command. This code is NOT an example
// of how to use the DS18B20, in fact, it’s an example of how NOT to use it.
// It simply uses two DS18B20s (one per bus) as a handy OneWire slave in order
// to demo/test UART off-load of OneWire transactions. As such it does no device
// discovery, and no device selection by ROM code. It will only work provided there
// is only one DS18B20 per bus. There are plenty of examples on the net implementing
// the full DS18B20 discovery and addressing stuff, use them instead if you’re
// trying to do anything serious with DS18B20s. Here they’re just a handy OneWire
// slave to bang against in a very primitive fashion.
txshield_demo_11.tar.gz (922.9 KB)