I have set up a CANOpen network consisting of 3 engines, each having their own CANOpen slave. I have a Hilscher CifX board acting as CANOpen master.
I have achieved proper engine command by reading and writing RPDO and TPDO directly into the process memory of the Hilscher board.
Now, I tried to set up the network through Sycon.NET (the Hilscher configuration tool) to map additional variables to the PDO, but the variables I want to capture don't appear in the list. I figure this is because the EDS metions PDO Mapping = 0 for these variables.
I would like to read the values of these variables every 20ms or so. Can I do this by polling the device through SDOs? If so, how?
You could do an SDO Upload on the object.
The message should look something like this(Object index: 0x1234, Sub index: 0x01):
Id: 0x680 + NodeId, DLC: 8, Data: 0x40 0x34 0x12 0x01 0x00 0x00 0x00 0x00
You can find further info on SDO in CiA DS301.
Related
I'm trying to configure my SX1278 Ra-2 LoRa module via STM32 Nucleo board and ran into a problem.
While I was initializing the LNA register (0xC) by writing (0x23) -> 0010(max gain) 0011(boost on), which is supposed to give me the max gain and boost, after reading that register I receive 0x3.
Is this normal?
While LoRa SX1278 is in sleep mode it will return 0x3, without showing 3MSB. However in Standby Mode it reads 0x23 as it is supposed to.
Have you set AgcAutoOn to 0? Otherwise it will automatically set the LNAGain bits.
Source:
page 60:
When AgcAutoOn=0, the LNA gain is manually selected by choosing LnaGain bits in RegLna.
page 95:
Note:
Reading this address always returns the current LNA gain (which
may be different from what had been previously selected if AGC
is enabled.
Page 96: set bit 3 to 0 in 0x0D to disable AgcAutoOn.
Page 95: for the Booston/max gain, you need to set bits 0-1 and 5-7. Because of your writing style I suspect you are only writing to the lower ones.
While LoRa SX1278 in sleep mode will return 0x03, without showing 3MSB, in Standby Mode it reads 0x23 as it is supposed to.
I have working C & Python3 code, based upon simple examples from the internet, where I can correctly send data from my Raspberry Pi4 to an Atmel SAM-E70 dev kit board. I've got a logic analyzer connected to look at the data being sent, and for every i2c_write_data_block() from my Python3 code, the smbus2 code sends the 7-bit address, followed by 0x00, followed by the byte stream that I want to send. My C code, sending the same byte streams, doesn't have the 0x00 between the address and the data. Finally, sending the byte stream using i2ctransfer() from the shell also works as expected: no extra byte.
Hypothetically, it could be that the smbus2 package is trying to use a 10-bit address, but I cannot find any documentation supporting this supposition. In fact, what I've found indicates that the I2C bus configuration is performed via config file(s) which would lead me to the believe that the language used to communicate on the I2C bus shouldn't matter - it would have the same configuration.
Has anyone else encountered this?
I noticed the same thing using the smbus2 i2c_write_data_block() function.
To avoid sending the 0x00 start byte, use the i2c_rdwr() function.
Example:
bus = SMBus(1)
address = 4
data = 'Some message'.encode()
msg = i2c_msg.write(address, data)
bus.i2c_rdwr(msg)
Am trying to initialize the NRF24L01+ registers using SPI but they always return 0x00.
According to the datasheet, Table 20 on page 51, all write commands will have a pattern of b001x xxxx, which i understood as having a 0x2x pattern.
In my snapshot below, i send the register value, for example register 0x00 will be sent as 0x20 indicating a write command to that register and then i send the value to be written on that register.
As you see on the MISO line, the value is 0x00 even when am trying to write a 0x08 which should be the default value according to page 57 of the datasheet.
I still dont know why its returning 0x00 even when i independently try to read the contents of that register later on without writing to it. I still get 0x00. The same applies to all other registers that am trying to re-init.
Anyone who has experienced this behaviour elsewhere or is it me that is having something wrong?
The NRF24 am trying to program here is this type from sparkfun
You are close. The datasheet shows write register as 001A AAAA and read as 000A AAAA, where the 5 A's represent the register you want to write to. The spec states that while the command is being sent (read, write, read payload, write payload, flush, activate, and so on), the device will return the status register. In your data, the device is responding with 0x0E, which is correct; decoded is is saying no errors and no data received or pending to transmit. If you want to see if the command you send was accepted, you need to first write the data and then read the data. For example, let's say we want to write the config register to enable the device as a receiver, 2 byte CRC with Rx interrupts enabled.
First, you would send 0b00100000 (0x20), 0b00111111 (0x3F). The device will respond with 0b00001110 (0x0e), 0b00000000 (0x00). This is what you are seeing. If you want to verify the configuration register, you need to then send 0b00000000 (0x00),which is the command to read the config register, then 0b00000000 (0x00), which is a dummy byte to clock out the data. The device will respond with 0x0e, which is the status, and then 0x3F assuming you configured as I did above.
Note that there are more commands than just reading and writing the registers, there are specific commands to fill and read the pipeline data.
Hope this helps.
I would like to read a block of data from my Arduino Mega (and also from an Arduino Micro in another project) with my Raspberry Pi via I2C. The code has to be in Perl because it's sort of a plug-in for my Home-Automation-Server.
I'm using the Device::SMBus interface and the connection works, I'm able to write and read single Bytes. I can even use writeBlockData with register address 0x00. I randomly discovererd that this address works.
But when I want to readBlockData, no register-address seems to work.
Does anyone know the correct register-address, or is that not even the problem that causes errors?
Thanks in advance
First off, which register(s) are you wanting to read? Here's an example using my RPi::I2C software (it should be exceptionally similar with the distribution you're using), along with a sketch that has a bunch of pseudo-registers configured for reading/writing.
First, the Perl code. It reads two bytes (the output of an analogRead() of pin A0 which is set up as register 80), then bit-shifts the two bytes into a 16-bit integer to get the full 0-1023 value of the pin:
use warnings;
use strict;
use RPi::I2C;
my $arduino_addr = 0x04;
my $arduino = RPi::I2C->new($arduino_addr);
my #bytes = $arduino->read_block(2, 80);
my $a0_value = ($bytes[0] << 8) | $bytes[1];
print "$a0_value\n";
Here's a full-blown Arduino sketch you can review that sets up a half dozen or so pseudo-registers, and when each register is specified, the Arduino writes or reads the appropriate data. If no register is specified, it operates on 0x00 register.
The I2C on the Arduino always does an onReceive() call before it does the onRequest() (when using Wire), so I set up a global variable reg to hold the register value, which I populate in the onReceive() interrupt, which is then used in the onRequest() call to send you the data at the pseudo-register you've specified.
The sketch itself doesn't really do anything useful, I just presented it as an example. It's actually part of my automated unit test platform for my RPi::WiringPi distribution.
I am trying to get raw values of ACCEL_OUT from MPU6050 (GY-521 module). I can read WHO_AM_I register and I can write to PWR_MGM_1 (0x6B) register and change it default value from 0x40 to 0x00 ( when I write to register, I can read 0x00). and interrupts are handled fair, I need to access raw data of sensors. but when I read ACCEL_OUT registers, for example (ACCEL_ZOUT_L) it just return 0x00. I spend a whole night and a whole day on this problem and nothing good happened at all.
Any advise would be great help.
Thnx.
I solved the problem, it was I2C NACK and STOP in read command.