I need to change an i2c address of an amphenol nova sensor NPA201 (pressure) using an stm32F407-discovery board.
An application note provided by manufacturer raises some questions.
According to the table, the one must set cpu's i2c module to master-receiver mode, and immediately send a byte to sensor. Is it even possible to do so?
May be i need to read reference manual one more time, buy as far as i know such situation is not described there.
Has anybody done the changing address procedure before?
table
Information for changing the address of the sensor can be found here Please note you can only change it three times. The default i2c address is 0x27.
Related
I am trying to detect intrusions on a CAN bus configuration. To do this I want to try protocol conversion from CAN to IP (UDP) in order to use snort. I really don't know where to begin as I have not seen anything on protocol translation for a CAN bus at all. Is it even possible? Has anyone tried it?
I basically used a raspberry pi and several Arduinos to take temperature readings (from thermostats) and control hot/cold fans in order to regulate temperature. I know this is not a lot to go on, but as I said, I am just in the beginning phase of planning this protocol translation.
You can use cannelloni on your RPi. There are also stand-alone CAN-to-TCP/UDP converters like for example this one.
I am working on a project that requires me to use 5 TLC7524 DACs. They will all be receiving data from an 8 bit bus. For data transfer, the process is CS pin, WR pin, send Data. I was wondering if I could get away with grounding the CS pin on all of them and control them with just the WR pin.
Link to datasheet for TLC7524 -
http://www.ti.com/lit/ds/slas061d/slas061d.pdf
Usual way is select the DAC by /CS and the /WR signal is common for all of them.
In this way, you can connect it on FMC and create the /CS for each chip from the address (FMC is available on Nucleo144 boards, but not on Nucleo64 ones).
Also selected chips may have much higher current consumption (as they are active). For example SRAM chips are using much more current when enabled by /CS.
While unit testing a Modbus driver I'm writing I experienced the following:
I can read holding registers 0 to 1022.
I can't read holding registers 1022 to 13000. I get an illegal data address error code.
I can read holding registers 13000 to 25000.
I would have expected devices supporting Modbus to behave in one of the following two ways:
Every device supports the full range of addresses from 0x0000 to 0xFFFF.
Every device supports a range of addresses from 0x0000 to N, where N < 0xFFFF.
Do any of you more experienced people know:
Is Assumption 1 or 2 about the expected behavior of Modbus devices correct?
Are there other reasons beside being out of bounds for an address to be an illegal data address?
Both assumptions are false. It's completely up to the device to decide which registers to support. Some devices are nice and support a wide range of registers, even if they're unused. Most that I've used don't, though. They'll use groups of registers, like your device.
Also, not all Modbus devices support all the Modbus function codes. Just because it's defined by the Modbus protocol standard doesn't necessarily mean the device will support it.
The key thing is to stick to the addresses defined in the device's manual. The manual is usually required reading, otherwise you'll just be guessing at the ranges, units, and scaling.
I am reading linux device driver book of rubini,corbet and hartmen.I have doubt regarding dynamic allocation of major and minor device numbers.They say
The disadvantage of dynamic assignment is that you can’t create the device nodes in
advance, because the major number assigned to your module will vary.For normal
use of the driver, this is hardly a problem, because once the number has been
assigned, you can read it from /proc/devices.
1)What does it mean by advance here?
2)Why major and minor numbers must be read from /proc/devices when function alloc_chrdev_region provides major and minor numbers in the argument sent to it.can that argument sent, not be used directly?
Thanks in advance
1) Dynamic assignment would mean that you cannot create device nodes before the driver is loaded, for example having them as a static part of the filesystem when the system boots. Instead you could only create them once you discover what their major/minor numbers are this time.
2) The driver may know what it's major and minor numbers are, but the device nodes should be created by something in userspace. They are suggesting that if this information cannot be given in advance in parallel to both the kernel driver and userspace, then userspace will have to discover it at runtime from something such as /proc/devices.
When we assign a major number dynamically to a device driver, we are not aware with the Major Number till the alloc_chrdev_region function finishes execution or let's say that you don't get to know the Major Number before you insert the module into the kernel (and for this we use insmod). And so you cannot create a node for your driver (for which we use mknod) unless you load a device driver, this is referred to as advanced by the author.
We read /proc/devices for Major and Minor Numbers of one device driver when a different device/program needs them.
Consider the following Ladder Program that checks if a connection is enabled (A202.00) then send a message from the PLC to the PC.
The documentation (Omron CX-Programmer) has a severe lack of explanation of the program convention. What I do not understand is:
To send a message from a node to a node. I should need to specify the receiver ID. It seems the function block does not have an option where I can insert an IP address. Am I supposed to MOV an IP address to a DM address (D300) then use it? If that's the case how (IP address has dots in between 4 bytes..)?
Can someone please explain what is S (First source word), D (First destination word) and C (First control word). Aren't they just memory address? E.g. sending content of a memory adress to another memory address?
[EDIT]
What am I trying to do?
I am trying to interface a measuring gauge (controlled through Ethernet by PC/C# application) to a robotic system (no RS232 or serial, no TCP/IP, only has the simplest I/O points) with an Omron PLC. When gauge completes a measurement, the C# app sends a command to the Omron PLC which, according to the command received, switch ON or OFF an output which triggers a voltage flow to the robot's I/O port.
Should I use FINS? What functions/protocol from the PLC I need to know to do this? I do not know so I am testing every function from the documentation. So far, zero progress.
1) All addressing information is encapsulated in the five control words (C -> C+4). C- "First Control Word" is the pointer to the first word in this table of five words you must have stored somewhere in your PLC to set up the communication.
2) First source word points to the first word in your PLC you wish to send. First destination word points to the first address in the PLC/device you wish to send to. In the example , the first control word specifies that 10 words should be sent. You point to the first one and it will send that one plus the next nine addresses as well.
To do this you have to use FINS communication - the PC stores a memory structure similar to the PLCs (CIO, DM, etc) called Event Memory and these are the addresses in the PC you are pointing to. The PC gets a FINS node number and address just like a PLC would - no IP addresses are involved. (see : FINS Manual) FINS is old, however, and has been superceded by things like Sysmac Gateway.
There are much better ways of communicating between PLC/PC, however, depending on what you are trying to do. Are you trying to write an HMI? If so, what language are you using?
Edit :
If you're using C#, I highly recommend you look into Sysmac Gateway and CX-Compolet. This is probably the most flexible, simple, and extensible way to get .NET working with Omron PLCs. If it is at all possible, however, a better way might even be to have the measurement unit communicate directly with the PLC via hardware I/O (relays, DIO, etc).
CX-Compolet, Sysmac Gateway link:
http://www.ia.omron.com/product/family/63/index_l_u.html