I have ESP23 dev kit with micropython firmware esp32-idf3-20200329-v1.12-317-g688323307.
I also have ds18b20 waterproof sensor. datasheet link
I wrote this code for it:
import time, onewire, ds18x20
import machine
from machine import Pin
ds_pin=Pin(19)
ds_sensor = ds18x20.DS18X20(onewire.OneWire(ds_pin))
roms = ds_sensor.scan()
for rom in roms:
print(rom)
It returns tis info:
[bytearray(b'(\xbcN6\x14\x19\x01\xba')]
Before reading temp data from sensor, we first need to use the scan() function to scan for DS18B20 sensors. The addresses found are saved on the roms variable (the roms variable is of type list). scan() function sends request and sensor returns its unique 64-bit serial code.
I used manual here
Today I bought two more ds18x20 waterproof sensors (I don’t know what type of sensor - ds18a20/ds18b20 or else - are they, ‘cause eager chinese manufacturers sealed sensors inside metal bullet too good, so I can’t just look inside).
I tried to run the same code with them, but it returned the following:
bytearray(b'(\xff\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xfe\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xfc\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xf8\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xf0\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xd0\xff\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xff\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xfe\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xf6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xe6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xc6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xff\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xfd\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xf9\xff\xff\xff\xff')
bytearray(b'(\x90\x86y\xff\xff\xff\xff')
bytearray(b'(\x90\x86y\xfe\xff\xff\xff')
bytearray(b'(\x90\x86y\xfa\xff\xff\xff')
bytearray(b'(\x90\x86y\xf2\xff\xff\xff')
bytearray(b'(\x90\x86y\xe2\xff\xff\xff')
bytearray(b'(\x90\x86y\xa2\xff\xff\xff')
bytearray(b'(\x90\x86y\xa2\xfd\xff\xff')
bytearray(b'(\x90\x86y\xa2\xf9\xff\xff')
bytearray(b'(\x90\x86y\xa2\xf1\xff\xff')
bytearray(b'(\x90\x86y\xa2\xe1\xff\xff')
bytearray(b'(\x90\x86y\xa2\xc1\xff\xff')
bytearray(b'(\x90\x86y\xa2\x81\xff\xff')
bytearray(b'(\x90\x86y\xa2\x01\xff\xff')
bytearray(b'(\x90\x86y\xa2\x01\xfb\xff')
bytearray(b'(\x90\x86y\xa2\x01\xf3\xff')
bytearray(b'(\x90\x86y\xa2\x01\xe3\xff')
bytearray(b'(\x90\x86y\xa2\x01\xc3\xff')
bytearray(b'(\x90\x86y\xa2\x01\x83\xff')
bytearray(b'(\x90\x86y\xa2\x01\x03\xff')
bytearray(b'(\x90\x86y\xa2\x01\x03\xfe')
bytearray(b'(\x90\x86y\xa2\x01\x03\xfc')
bytearray(b'(\x90\x86y\xa2\x01\x03\xdc')
bytearray(b'(\x90\x86y\xa2\x01\x03\\')
When I try to read temperature using this values it returns ‘CRC error’.
What can be done? Is the problem with code, or the sensors are failed somehow?
Connect one sensor at a time when you do the scan.
You haven't shared how you're wired the DS18x20 sensor. Make sure its positive power connection is to 3.3V not 5V.
Make sure you've connected a resistor (4.7K should be good) between the data pin of the sensor and 3.3V. OneWire devices absolutely won't work reliably without this resistor - you might see the kind of problem you're seeing.
If you're sure it's wired correctly the next step would be to try it with different firmware, for instance a Dallas one-wire scanner using the Arduino Core. That would eliminate the possibility of problems with the library you're using and MicroPython.
looks like fake sensor
How to tell original from fake DS18B20 temperature sensors
Looks like i'm a fool))
Yes. One 4.7K pull up resistor and it's alive! IT'S ALIVE!!
aaaand whats'up doc?
then we use internal PULL_UP mode we pull up signal only for ESP.
BUT! DS18B20 is microchip too. And the wire for little DS18B20 is like giant radio aerial.
Maybe in my first sensor this problem was solved on hard level.
Related
I completed Anton Potočniks' introductory guide to the red pitaya board and I am now able to send commands from the linux machine running on the SoC to its FPGA logic.
I would like to further modify the project so that I can control the phase of the signal that is being transmitted via the red pitayas' DAC. Some pins (from 7 down to 1) of the first GPIO port were still unused so I started setting them from within the OS and used the red pitaya's LEDs to confirm that they were being set without interfering with the functionality of Anton Potočnik's "high bandwidth averager".
I then set the DDS_compilers' to Phase Offset Programmability to "streaming" mode so that it can be configured on the fly using the bits that are currently controling the red pitaya's LEDs. I used some slices to connect my signals to the AXI4-Stream Constant IP core, which in turn drives the DDS compiler.
Unfortunately the DAC is just giving me a constant output of 500 mV.
I created a new project with a testbench for the DDS compiler, because synthesis takes a long time and doesn't give me much insight into what is happening.
Unfortunately all the output signals of the DDS compiler are undefined.
My question:
What am I doing wrong and how can I proceed to control DACs' phase?
EDIT1; here is my test bench
The IP core is configured as follows, so many of the control signals that I provided should not be required:
EDIT2; I changed declarations of the form m_axis_data_tready => '0' to m_axis_phase_tready => m_axis_phase_tready_signal. I also took a look at the wrapper file called dds_compiler_0.vhd and saw that it treats both m_axis_phase_tready and m_axis_data_tready as inputs.
My simulation results remained unchanged...
My new test bench can be found here.
EDIT3: Vivado was just giving me the old simulation results - creating a new testbench, deleting the file under <project_name>.sim/sim_1/behav/xsim/simulate.log and restarting vivado solved this problem.
I noticed that the wrapper file (dds_compiler_0.vhd) only has five ports:
aclk (in)
s_axis_phase_tvalid (in)
s_axis_phase_tdata (in)
m_axis_data_tvalid (out)
and m_axis_data_tdata (out)
So I removed all the unnecessary control signals and got a new simulation result, but I am still not recieving any useful output from the dds_compiler:
The corresponding testbench can be found here.
I also don't get any valid output when I include the control signals.
The corresponding testbench can be found here.
Looks like m_axis_data_tready is not connected. No data will come out unless that's asserted.
I just started with microchip world.
I'm about to buy a PicKit3 and i've seen it can outputs from 1.8V to 14V MCLR.
The pic i will use is the PIC16F1829 and it should work with MCLR # 5V.
In the datasheet it seems i would need a zener/shunt to limit the voltage.
First of all isn't there a board ready to play with?
Can i use LVP? If so using MPLab 8 IDE how do i change in LVP?
Is the pin connection the same?
Since i haven't bought it yet i would rather avoid burning a pic
Regards,
Notes at the bottom of page 345 in the PIC16F1829 data sheet (DS40001440E) recommends using a voltage limit circuit when using the ICD2 device programmer.
According to Microchip this is "not required" when using the PICkit3.
Get a few extra PIC16F1829 just in case.
You ask about boards ready to use, take a look at the Curisotiy Nano boards
https://www.microforum.cc/topic/9-microchip-xpress-evaluation-boards
These are ready to use and do not need any programmer. You can simply send a file to these devices over USB. They are also have debugging capability.
In terms of the 14V on MCLR, the device is designed to handle whatever pulse will be generated by the PICkit3, so you do not need any protection for the PIC against that. In fact limiting the voltage on that pin will prevent the device from programming so you definitely do not want to do that. If you are however using this pin to connect to other parts on your board the other parts probably will need protection.
You can most definitely use LVP, just be careful, it is possible to use LVP to disable LVP, and then the only way to get it back on is to use HVP!
Lastly in the IDE under programming options you can change the mode there (Use low voltage programming mode entry)
In the IDE i've set the voltage appropriately and everything went ok on its own.
I didn't have to enable anything fancy
Coming form this question yesterday, I decided to port this library to my board. I was aware that I needed to change something, so I compiled the library, call it on a small program and see what happens. The 1st problem is here:
// Check for GPIO and peripheral addresses from device tree.
// Adapted from code in the RPi.GPIO library at:
// http://sourceforge.net/p/raspberry-gpio-python/
FILE *fp = fopen("/proc/device-tree/soc/ranges", "rb");
if (fp == NULL) {
return MMIO_ERROR_OFFSET;
}
This lib is aimed for Rpi, os the structure of the system on my board is not the same. So I was wondering if somebody could tell me where I could find this file or how it looks like so I can find it by my self in order to proceed the job.
Thanks.
You don't necessarily want that "file" (or more precisely /proc node).
The code this is found in is setting up to do direct memory mapped I/O using what appears to be a pi-specific gpio-flavored version of the /dev/mem type of device driver for exposing hardware special function registers to userspace.
To port this to your board, you would need to first determine if there is a /dev/mem or similar capability in your kernel which you can activate. Then you would need to determine the appropriate I/O registers for GPIO pins. The pi-specific code is reading the Device Tree to figure this out, but there are other ways, for example you can manually read the programmer's manual of the SoC on which you are running.
Another approach you can consider is adding some small microcontroller (or yes, barebones ***duino) to the system, and using that to collect information from various sensors and peripherals. This can then be forwarded to the SoC over a UART link, or queried out via I2C or similar - add a small amount of cost and some degree of bottleneck, but also means that the software on the SoC then becomes very portable - to a different comparable chip, or perhaps even to run on a desktop PC during development.
I'm busy writing a driver for a UART. The, struct uart_port has a field uartclk see this link. According to a slide set I found from free-electrons, this is among the most important fields to initialize. Yet, the Xilinx AXI UART Lite, which I'm writing a driver for, doesn't initialize this member see this link to see.
I'm wondering about the importance of this field. What is this in relation to a UART? Why is it important? What role does it play in the serial core?
Thanks
P.S. I know there's a driver existing. However, this driver assumes the UART Lite is to be used in an embedded environment. In the application I'm writing to, this is not the case.
The UART like any other IP in the system has to have functional and interface clocks. In some IPs it might be same clock, in some it might be more interface or functional clocks. The uartclk field reflects the actual frequency on the input to baudrate generator (don't be confused by the frequency of functional clock which most of the time is constant). When user calls termios to set a desired baudrate the UART driver for actual hardware recalculates uartclk, if needed, and bottom layer, if used, configures the registers. That's how 8250 works. In other cases it might be left unused, if, for example, serial hw driver does everything on its own.
I have a a Sparkfun Max 7456 breakout board that I am trying to rewrite the character table to an ASCII format. I have been following the Arduino + MAX7456 OSD thread but cannot seem to load the .mcm file to the breakout board. I have tried hyper terminal and tera term. Tera term allows me to "transfer" the mcm file but I do not get any type of confirmation in the terminal window. When I try simple sample code like "Hello World.ino" I get no response and the default character set is still displayed. Hyper terminal tells me there is a COM port conflict with the Arduino IDE. I know the steps are available in the above mentioned thread but the picture/ code resources have mostly been removed. I don't know if I'm missing something in the code or if I am not using the terminal program correctly. I have the following connections between the breakout board and the Uno and have been trying Arduino code provided at the start of the thread;
Breakout/ Uno;
CS-->D10
SDIN--> D11
SCK--> D12
SDOUT--> D13
+5V
GND
I have tried using wires that are <5cm and >=10cm and I am using NTSC. Can anybody determine what I am doing wrong or point me in the right direction please. Thanks in advance,
I figured out my issue. Using Google translate I was able to get code from;
http://f5mna.free.fr/Arduiexpert.htm
Previously, I was only making the connections listed in the code when the full list is;
D13--> SCLK
D12--> SDOUT
D11--> SDIN
D10--> CS
+5VDC must be applied to the +5V pin on the board as well as a 1k resistor in series with LOS and a 10k with RESET.
As for using tera term. First shutdown the Arduino IDE and open the connection in the terminal program. The code provided in the above link will indicate it is ready for file transfer and will prompt you with a transfer complete message.
All in all, simple solutions but I was a newcomer to a very old thread. Hope this helps anyone else having the same issues in the future.