I am attempting to use libMPSSE to perform I2C communications. The example code listed in the attached document connects to a 24LC024H EEPROM device.
The address for the device used in the example as defined in it's documentation is 1010XXX_ where the X's are configurable. In the examples associated diagram you can see the values are configured to be 1. It also states that the R/W bit (_) should not be included meaning the address passed to the library should be 10101110. The address actually used in the example code is 0x57 which is 01010111.
I do not see how we got from A to B here. I cannot figure out how to format the address of the device I am trying to communicate with nor can I find any documentation spelling it out. The only documenation on the address parameter says:
Address of the I2C slave. This is a 7bit value and it
should not contain the data direction bit, i.e. the
decimal value passed should be always less than 128
This confusing since the data direction bit is usually the LSB.
I was updating my question to clarify what the address should be and a coincidence in the editor cause the answer to smack me in the face.
By "should not be included" they do not mean that the bit should be zero but rather by completely nonexistent. To them this means shifting the address bits down to remove it as the LSB. It also implies that the MSB should always be zero even though it's not explicitly defined anywhere.
Related
For a work project, I have to read a bunch of holding registers from an IFM CR1203 PLC that is programmed using CODESYS 3.5.
The PLC will be running a slave instance and the device reading the holding registers will be a PC running a custom application programmed in Javascript to be a client. I have already programmed MODBUS TCP/IP functions for the custom application that is tested and works (For a previous project I had to do the same for a different PLC programmed using a different platform).
My current issue is that I need the raw memory address of the first holding register to do this, but I can't find it on the CODESYS IDE. CODESYS uses an addressing system that makes it easy for different CODESYS-based devices to communicate. Here is a link that explains how it works: CODESYS MODBUS register location guide
The only thing that looks like it can work is from the link above:
<memory position> : <number> ( .<number> )* // Depends on the target system
But I don't fully understand what all that means.
I also can't find any documentation on the PLC or CODESYS that explains this topic in enough detail. Here is a snippet of dummy code used for testing that shows the CODESYS addresses:
Can someone please explain to me how I can convert the value %IW0 to a raw memory address, for example, 0xFFFF?
I use Machine Expert (Codesys 3.5.16) and in their documentation says:
The I/Os are mapped to Modbus registers from the master perspective as follows:
%IWs are mapped from register 0 to n-1 and are R/W (n = Holding register quantity, each %IW register is 2 bytes).
%QWs are mapped from register n to n+m -1 and are read only (m = Input registers quantity, each %QW register is 2 bytes).
So in your example they should be address 0 and 1.
In an Operating Systems course, the instructor introduced PSW and PC when he talked about Interrupt Handling.
His explanation was
PC holds the address of the next instruction to be fetched
PSW contains execution status information
But later I searched online and found that PSW = PC + status register. This makes me quite confused.
On the one hand, I am not sure what "execution status information" refers to. On the other hand, if PSW has the functions of a PC, why do we still need it?
Appreciate any explanation.
This isn't really standardized terminology. Most architectures have some register that plays the role of a status word, containing bits to indicate things like whether an add instruction caused a carry. But different architectures give it different names, and what exactly is included can vary widely. I'm not aware of any architecture that includes the program counter as part of their status word, but if they want to do that, well, who's going to stop them?
This is the kind of thing where you just have to look at the definition given by whatever book or article you are reading (or infer it from context), and realize that a different author may use the word differently.
In general, interrupts are hardware level subroutine calls. They do the same thing as a subroutine call (change the algorithm that the processor is executing) however they do it without warning the "executing code" that they are now operating.
In order to not damage the "executing code" all information that it was using must be stored. This includes the Program Counter (usually saved to the stack by the interrupt hardware in the same way that a subroutine call does) and all of the registers that the interrupt function will alter- these must be saved by pushing them onto the stack. The registers etc must be restored before the return from interrupt (RETI) instruction - the PC is restored by the RETI itself.
The PSW (often called the flag register) is a very important register and must generally be saved first. It contains bits like Zero (the last calculation resulted in a zero result) Carry (the last calculation resulted in a carry ie the result number is bigger than the register can hold) and several other flags. I suggest that you read the data sheet of an 8 bit microcontroller for an idea of what these flags might be. suffice it to say that these flags are needed in order to perform conditional jumps. And whilst they will often be ignored you can't take that chance.
You are probably correct in Your instructor using the term PSW to mean all all of the registers.
The subject of interrupts contains concepts that are common to subroutine calls in general (e.g. don't leave data that you don't want overwritten in a register before entering a subroutine). And later on in operating systems, the concept of context switches that occur during multi-tasking.
Peter
I want to write to the holding registers an actuator of mine has, but I've only recently started using pymodbus and I'm a little uncertain about some of its commands. As far as I've understand the primary write command looks like this:
write_register(address, value, **kwargs)
But I'm uncertain about how I "define" which kind of register I write too. Unlike other modbus libraries I've used, in pymodbus I can't define which kind of register I write too. As far as I understand of modbus there's coils, input registers and holding registers. I've read that you can't write to input registers, but how can I be certain I write to holding registers? If I write 1 in address in the write_register will that always be a holding register with that address?
Thank you in advance.
You need to know a little bit more about your actuator. Do you have a datasheet about it? If yes, you need to find a map registers where all the addresses are given for registers where the actuator's information are stored. Here an example where you can find this kind of registers map : SIMEAS Pxxx Com-Modbus Datasheet.
Be careful, sometimes you need to add or subtrace 1 to your register address because the guys who implement this did in this way. Read your datasheet carefully.
So if you need to write something in a particular register, you need the correct address of the register, the value you want to write in the correct format, and the client of the library ModbusClient.
You should have something like this :
client = ModbusClient(host='YOUR_IP_ADRESS', port=xxx)
client.connect()
client.write_register(REGISTER_ADRESS, PAYLOAD, UNIT)
Hope this will help a little. You can also go further by reading the Pymodbus documentation.
I'm implementing a small PCI driver for academic purposes, and one thing I'm not clear about if we actually have to provide driver.conf? Different materials which I read (including http://blog.csdn.net/hotsolaris/article/details/1763716), say that for PCI the driver config file is optional, however in my case it seems that pci_config_setup() is successful only with driver.conf provided:
name="mydrv" parent="/pci#0,0/pci8086,2e11"
Then I do:
% add_drv -i 'pciXXXX,YY' mydrv
and it adds in the system with no warning or error messages.
So I assume that some properties of a PCI device can't be derived automatically by the system, e.g. parent bus?
I would appreciate if anybody could shed some light on this. Thanks.
If you look at a random selection of very small files under /kernel/drv for actual physical hardware, you'll see that they almost always only contain the line
ddi_forceattach=1;
Pseudo drivers will have a driver.conf(4) file which reflects their parentage in the system. I really recommend reading that manpage, it goes into good detail about what's required here.
I am studying a simple web server using c, and came up with some of these questions. How does IPv6 used in TCP? To use IPv6, do we have to use some form of modified version of TCP?? If we have to used the modified version of TCP, what do we have to change?? I think I read about Little Endian, as well as Big Endian, but I am not sure if there should be some special cases for IPv6.
As you'll probably be wanting the more gory details of the API changes, it's here: http://www.faqs.org/rfcs/rfc2553.html
Mostly it's a couple of longer address structures to pass in that can take a longer number and a new Family and Protocol name specified so the API can destiguish which struct you are using. Byte ordering is the same.
The actual TCP SYN, SYN/ACK, ACK stuff and all that is identical, it is literally a different IP layer frame with a longet number and other changes.