This is the respberry 3
wlan0 is built-in network card to link web
enxe84e0638ecb6 is external network adapter to route forwarding
wlan0 IEEE 802.11bgn ESSID:"PandoraBox_00166C"
Mode:Managed Frequency:2.412 GHz Access Point: 20:76:93:00:16:68
Bit Rate=13 Mb/s Tx-Power=1496 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=49/70 Signal level=-61 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
enxe84e0638ecb6 unassociated Nickname:"<WIFI#REALTEK>"
Mode:Auto Frequency=2.412 GHz Access Point: Not-Associated
Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Try to use config.txt in /boot.
Related
I have a problem using the SPI bus user space driver (spidev) in version 4.14 of lnx-xlnx. Sometimes only one byte (instead of for example the desired 4 bytes) is written to the MOSI due to SCLK dropping, for no apparent reason in a full duplex transfer. What could be happening?
I have 3 devices(GPS-Rx only, tft display-TxRx and a motor driver-Rx only) that connect only using uart. 2 of which only Tx, while one another has both Tx and Rx. I am using uart 0, for tx-rx peripheral. Flash mode and peripheral usage with device are separated with a push switch.
I also have a micro sd card requirement, so pins of uart1 has to be changed from spi pins.
I am using esp-idf and I am trying to use uart_set_pin. Now I have 2 questions,
How do I set no pin for Tx? Setting "UART_PIN_NO_CHANGE" would set it only to default Tx pin.
Can I use GPIO 16 and 17 for Rx pins of uart1 and uart2 respectively?
I need to read temperature data with using MAX31865 SPI communication. First of all, I tried to read 4 byte data:
import machine
import ubinascii
spi = machine.SPI(1, baudrate=5000000, polarity=0, phase=0)
#baudrate controls the speed of the clock line in hertz.
#polarity controls the polarity of the clock line, i.e. if it's idle at a low or high level.
#phase controls the phase of the clock line, i.e. when data is read and written during a clock cycle
cs = machine.Pin(15, machine.Pin.OUT)
cs.off()
cs.on()
data = spi.read(4)
cs.off()
print(ubinascii.hexlify(data))
I tried many times with different codes but result is always similar b'00000000'.
I am using ESP32 WROOM.
I used this pins:
ESP32 : D12 - D14 - 3V3 - GND - D15
Max31865: SDO - CLK - VIN - GND - CS
I am new on micropython and esp32.
I don't know what should I do. Is there any suggestions , recommended tutorials or idea?
Short answer: see if you can use CircuitPython and its drivers for MAX31865.
Long answer: a bunch of stuff. I suspect you've been following the Adafruit tutorial for MAX31855, but its SPI interface is very different from the MAX31865.
Your SPI connection is missing the SDI pin. You have to connect it, as communication is bidirectional. Also, I suggest using the default SPI pinout on ESP32 side as described in the micropython documetation for ESP32.
The SPI startup looks to be missing stuff. Looking at the SPI documentation a call to machine.SPI() requires that you assign values to arguments sck, mosi, miso. Those would probably be the pins on ESP32 side where you've connected SCLK, SDI, SDO on MAX31865 (note mosi means "master out, slave in" and miso is "master in, slave out").
The chip select signal on the MAX is inverted (that's what the line above CS input in the datasheet means). You have to set it low to activate the chip and high to disable it.
You can't just read data out of the chip, it has a protocol you must follow. First you have to request a temperature-to-resistance conversion from the chip. The datasheet for your chip explains how to do that, the relevant info starts on page 13 (it's a bit difficult to read for a beginner, but try anyway as it's the authoritative source of information for this chip). On a high level, it works like this:
Write to Configuration register a value which initiates the conversion.
Wait for the conversion to complete.
Read from the RTD (Resistance-To-Digital) registers to get the conversion result.
Calculate the temperature value from the conversion result.
The code might be closer to this (not tested, and very likely to not work off the bat - but it should convey the idea):
import ubinascii, time
from machine import Pin, SPI
cs = Pin(15, Pin.OUT)
# Assuming you've rewired according to default SPI pinout
spi = machine.SPI(1, baudrate=100000, polarity=0, phase=0, sck=Pin(14), mosi=Pin(13), miso=Pin(12))
# Enable chip
cs.off()
# Prime a 1-shot read by writing 0x40 to Configration register 0x00
spi.write(b'\x00\x40')
# Wait for conversion to complete (up to 66 ms)
time.sleep_ms(100)
# Select the RTD MSBs register (0x01) and read 1 byte from it
spi.write(b'\x01')
msb = spi.read(1)
# Select the RTD LSBs register (0x02) and read 1 byte from it
spi.write(b'\x02')
lsb = spi.read(1)
# Disable chip
cs.on()
# Join the 2 bytes
result = msb * 256 + lsb
print(ubinascii.hexlify(result))
Convert result to temperature according to section "Converting RTD Data Register
Values to Temperature" in datasheet.
Side note 1: here spi = machine.SPI(1, baudrate=5000000, polarity=0, phase=0) you've configured a baud rate of 5MHz which is the maximum for this chip. Depending on how you've connected your devices, it may not work. The SPI protocol is synchronous and driven by master device, so you can set any baud rate you want. Start with a much, much lower value, maybe 100KHz or so. Increase this after you've figured out how to talk to the chip.
Side note 2: if you want your conversion result faster than the 100ms sleep in my code, connect the DRDY line from MAX to ESP32 and wait for it to go low. This means the conversion is finished and you can read out the result immediately.
I have one energy meter and i am trying to retrieve voltage, freq values from meter on raspberry pi uart over RS485
My connections for raspberry pi and rs485 are as follows
Rs485 DI - Tx of raspberry pi
Rs485 R0 - Rx of raspberry pi
Rs485 DE/RE -Pin 7 of raspberry pi
my code is as follows:
import serial
import RPi.GPIO as GPIO
from pymodbus.client.sync import ModbusSerialClient as ModbusClient
from pymodbus.register_read_message import ReadInputRegistersResponse
from pymodbus.register_read_message import ReadInputRegistersRequest
import logging
logging.basicConfig() log = logging.getLogger()
log.setLevel(logging.DEBUG)
GPIO.setmode(GPIO.BOARD) GPIO.setup(7,GPIO.OUT,initial=GPIO.LOW)
client= ModbusClient(method = 'rtu', port='/dev/ttyS0',stopbits = 1,timeout =0.3, bytesize = 8, parity = 'N', baudrate = '9600')
connection = client.connect()
print "Connection" print connection
while 1:
volt=0
freq=0
if connection:
try:
voltage1= client.read_input_registers(0x000,4,unit=0x03)
print voltage1
except:
print "Error: No message Received"
client.close()
And i am receiving the output as follows
DEBUG:pymodbus.transaction:Current transaction state - TRANSACTION_COMPLETE
DEBUG:pymodbus.transaction:Running transaction 4
DEBUG:pymodbus.transaction:SEND: 0x3 0x4 0x0 0x0 0x0 0x4 0xf0 0x2b
DEBUG:pymodbus.framer.rtu_framer:Changing state to IDLE - Last Frame End - None, Current Time stamp - 1557304284.88
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x7b 0x20 0x31 0x20 0x31 0x20 0x32 0x36 0x2e 0x33 0x35 0x20 0x31
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
DEBUG:pymodbus.transaction:Current transaction state - TRANSACTION_COMPLETE
DEBUG:pymodbus.transaction:Running transaction 5
DEBUG:pymodbus.transaction:Clearing current Frame : - 0x7b 0x20 0x31 0x20 0x31 0x20 0x32 0x36 0x2e 0x33 0x35 0x20 0x31
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x7b 0x20 0x31 0x20 0x31 0x20 0x32 0x36 0x2e 0x33 0x35 0x20 0x31
DEBUG:pymodbus.transaction:SEND: 0x3 0x4 0x0 0x0 0x0 0x4 0xf0 0x2b
DEBUG:pymodbus.framer.rtu_framer:Changing state to IDLE - Last Frame End - None, Current Time stamp - 1557304284.98
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
WARNING:pymodbus.client.sync:Cleanup recv buffer before send: 0x37 0x2e 0x35 0x35 0x20 0x33
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Incomplete message received, Expected 13 bytes Recieved 7 bytes !!!!
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x2e 0x30 0x36 0x20 0x7d 0xd 0xa
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
If I'm not getting it wrong, you're defining your GPIO pin correctly but you're never toggling it high and low. To be able to drive the DE/~RE signal on your RS485 chip you should take the GPIO high before you write on the bus and low right after to be able to read the answer from your meter.
Unfortunately, I'm afraid what you're trying to do is not possible with pyModbus out of the box. You can take a look at this link:
https://github.com/riptideio/pymodbus/issues/33
You might be able to tweak pyModbus and use the RTS alternative functions on your Pi (see here: https://github.com/mholling/rpirtscts), but I don't think this path will get you very far reliability wise.
As I wrote here: RS485: Inappropriate ioctl for device, you might be better off going for a hardware solution. If you can't get new hardware you could always try the 555 timer solution, at least as a temporary fix.
Good luck, and be sure to post your progress or any further ideas.
EDIT: Solution using libmodbus instead
The suggestion to use libmodbus was very successful. Follow these steps if you want to try it (tested with Raspberry Pi 3B):
1) Clone libmodbus fork with GPIO support to your Pi:
git clone https://github.com/dhruvvyas90/libmodbus
2) Configure, compile and install libmodbus library (same commands as for the main repo):
./autogen.sh && ./configure --prefix=/usr && make && sudo make install
3) Go to rpi-test folder and compile the example:
gcc -o test -I/usr/include/modbus test.c -lmodbus
4) Run test, you will need to change permissions or sudo it: sudo ./test
What you get is actually much better than I expected and probably good enough for most Modbus hardware:
In blue, you see the TX from the Pi's UART (pin number 8 on the connector) and in yellow you get your DE/~RE (pin number 11, GPIO17) that you should connect to your RS485 chip. As you can see there is a delay of 0.6 ms from the end of the Modbus data frame until the bus is free for the slave to answer. At the speed I was using (9600 bps) the minimum delay you need to comply with the Modbus specification is around 3 ms (3.5 chars), so it should be fine for most situations.
The only thing pending would be to add all these GPIO functions to the pylibmodbus wrapper but that should be quite easy. I'm planning to use this library from Python real soon in the field with my Pocket Chip computer to work as a Modbus handheld tester so if you or anybody else manage to find the time I'd be more than glad to test it.
As soon as I have more time I'll try libmodbus together with my FTDI serial port and take a couple of scope captures to compare hardware vs. software signaling.
I forgot to mention that the only changes I made to the test.c were:
Line 13: #define UART_PORT "/dev/serial0"
Line 14: #define BAUD_RATE 9600
The first one just to the name of the embedded serial port on my Pi and the second one is the speed I always use for testing purposes.
EDIT: Software vs. Hardware signalling
As promised I have tested the solution proposed with libmodbus but instead of the embedded UART on the Raspberry Pi I made it work together with my FTDI USB adaptor to compare the time it takes to release the bus.
You can see how the TXEN (magenta trace) manages to go low about 250 microseconds after the stop bit while the GPIO on the Pi (in blue) takes more or less the same time as in the capture above (500-600 microseconds).
So pending more extensive testing, my conclusion is libmodbus does a great job for UARTs where you don't have a TX enable signal available. I think it should be possible to have reliable Modbus communication for most scenarios.
Solution with pylibmodbus
I wrote the missing functions for the pylibmodbus library.
See here: https://github.com/marcosgatcomputer/pylibmodbus
Once you have everything installed (the libmodbus branch with support for GPIO and pylibmodbus from the link above) you can try the test file:
from pylibmodbus import ModbusRtu
#Define Modbus RTU client (Python 2.x)
client=ModbusRtu(device="/dev/serial0", baud=19200, parity="N", data_bit=8, stop_bit=1)
# For Python 3.x you have to explicitly indicate ASCII enconding
#client=ModbusRtu(device="/dev/serial0".encode("ascii"), baud=19200, parity="N".encode("ascii"), data_bit=8, stop_bit=1)
#Read and set timeout
timeout_sec = client.get_response_timeout()
client.set_response_timeout(timeout_sec+1)
#Connect
client.connect()
SERVER_ID=0
BCM_PIN_DE=17
BCM_PIN_RE=9
#Set Slave ID number
client.set_slave(SERVER_ID)
#Enable RPi GPIO Functions
client.enable_rpi(1)
#Define pin numbers to be used as Read Enable (RE) and Drive Enable (DE)
client.configure_rpi_bcm_pins(BCM_PIN_DE,BCM_PIN_RE)
#Export pin direction (set as outputs)
client.rpi_pin_export_direction()
#Write Modbus registers, 10 starting from 0
client.write_registers(0, [0]*10)
#Read 10 input registers starting from number 0
result=(client.read_registers(0, 10))
#Show register values
print result
#Release pins and close connection
client.rpi_pin_unexport_direction()
client.close()
This code works with Rpi 3B. For Pocket Chip I had to modify libmodbus to account for the GPIO pin numbers (the original code was not able to write on the /sys/class/gpio/export file to create the gpio1015 device). This issue might happen for hardware with 4 digit numbers (if you see folders like gpiochipxxxx on your /sys/class/gpio/)
I have no real experience with hardware programming. I would like to know how to find out which registers, i.e their addresses, are used for an ethernet connection to send and receive information in a processer. In particular, for ATMEL's at91sam9g20 processor. I have searched the documentation and I'm not sure of the following of what I've found:
-Transmit data: signal name ETX0-ETX3. Receive data: signal name ERX0-ERX3.
Also, Offset: 0x18 Receive Buffer Queue Pointer Register and offset: 0x1C Transmit Buffer Queue Pointer Register.
I would appreciate any help as I'm very stuck on this issue.
Thank you
In the procesor documentation you find the following:
chapter 8 - general memory mapping - this gives the offset of the EMAC memory block as 0xFFFC:4000
chapter 36 - description of the Ethernet MAC subsystem
item 36.3.2 - memory interface - tells how the memory buffers for RX and TX is set up
item 36.5 - user interface - table 36-6 gives the names and offsets to all registers used by the subsystem
The signals (=pins) and register offsets you describe are correct.