I'm working on connecting the LXT972M PHY Transceiver to LPC2368 chip. I've already done the RMII to MII converter, but I can't figured how to implement that bidirectional MDIO signal in VHDL. As I just spotted it must be managed by some additional signal, but which? Is it really necessary to using that MDIO?
Related
I have got Arduino MEGA 2560. What I would like to do is to send a signal to Arduino via serial port to light specified LED up. However, I cannot find any documentation about this. What steps should I follow?
I think first, I need to compile the driver of Arduino and add it to Linux kernel. Second, I have to find some header files to use them in module. Then, I have to find functions to start serial communication and to light LEDs up. However, these are just my thoughts.
Any advice will be appreciated.
The arduino-mega (the one with ATmega2560) documentation is here:
https://www.arduino.cc/en/Main/ArduinoBoardMega2560#documentation
The serial communication via UART:
https://www.arduino.cc/en/Reference/SoftwareSerial
Since there are other ways for serial communication with the ATmega please read the documentation [above] and compare that to your exercise sheet.
I think such a kernel module is already available - and used by the arduino-ide.
Okay, what I want to do, as a training exercise, is to implement something like this
client --ethernet--> Modem1 --GPIO--> Modem2 --ethernet--> My Home Router
Where the client connects to Modem1 using an ethernet cable.
Modem1 is a Raberry PI, converting the signal and relaying it via the GPIO
Modem2 is a Raberry PI, receives the data from the GPIO, and send it via the ethernet cable to my home router
I want to implement the Modems, but have little idea where to start.
I have read up a little on ethernet programming, but still can't find answers to the "simple stuff" like.
How do I implement Modem1 so that when its connected to the client, the client discovers it as an internet connection.
On the Modem2 end, how do I make "My Home Router" send packets meant for the "client" to Modem2, so that Modem2 may forward them.
and possibly things I haven't though of....
So, how, concretely, can I implement this? preferably in c.
I'd venture to say you might be able to write some sort of custom GPIO intermediate layer.
Read Ethernet->Encapsulate->Write GPIO->|->Read GPIO->Decapsulate->Write Ethernet
(and vice versa)
The problem then becomes: How can both modems act as "Ethernet proxies"?
Modem1 acts as a proxy for the router. Modem2 acts as a proxy for the client. If your Raspberry Pi can spoof MAC addresses, you might be able to fool Ethernet peers into communicating with your modems' Ethernet port. The reason why you need to spoof MAC addresses is that in TCP/IP networking, there is the ARP table, which maps remote IP addresses to the MAC address that can route IP packets to/from them. This is what allows your client to communicate to your router over TCP/IP.
Another potential pitfall is where your modem communication introduces delays that interfere with the Ethernet layer's handling of the protocol. For example, the Ethernet protocol may have real-time constraints that could be shattered if you introduce delays...
But let's assume anything is possible in a perfect world...
You'll need to write code for reading/writing Ethernet messages (I've seen open source code for reading/writing Ethernet packets over raw sockets in Linux)
You'll need to write a custom driver for your GPIO comms.
This means implementing a carefully thought-out protocol to manage pins state, start-of-message, end-of-message, data-payload, checksum, whatever...
Finally, you'll need to write a top-level communications layer that implements:
Ethernet-to-GPIO process:
a) read from Ethernet port, encapsulates Ethernet packet into a custom message (or message fragments)
b) communicate this custom message, using your custom GPIO protocol driver, to the external GPIO peer
GPIO-to-Ethernet process:
a) Read from GPIO, using your custom driver code
b) Decapsulate Ethernet packet
c) Write Ethernet packet to Ethernet port.
these two processes run forever...
Again, all hinges on whether or not your modems can insert themselves in an peer-to-peer connection without disturbing the natural flow of the Ethernet protocol...
As for the 'C' part...
If you use open source libraries (or code snippets) for reading/writing raw Ethernet via raw sockets, that is most likely written in C.
Your GPIO code will read write from the GPIO pins in one of two ways: from a memory mapped H/W address, or using ioport calls on that H/W address.
Receive raw Ethernet frames in Linux
Send a raw Ethernet frame in Linux
Good luck
Does loop back interface generates interrupt on NIC/Hardware
The loopback interface is a virtual network interface. It doesn't correspond to any actual hardware, and packets transmitted through it therefore do not generate hardware interrupts.
It's possible that linux has some concept of a "soft interrupt", i.e. an inter-thread/process signalling mechanism, and that packets over the loopback will cause these. Older Linux versions definitely had these "soft interrupts", but I'm not sure if the 2.6 series does, and I'm not sure if packets over the loopback do or ever did generate them.
I wish to read the EUI64 address from an AT24MAC602 memory chip interfaced to an Atmega128rfa1 MCU over the Two wire interface. I tried to modify the I2C master drivers which are available for other platforms to suit my need. However, I wasn't able to carry out these modifications successfully as the program stopped responding as soon as the slave address was written to the twi bus with Write flag set. I failed to uncover the underlying reasons for the same.
As Contiki OS is quite popular, i thought someone might have already come up with contiki specific libraries for reading writing over TWI interface for Atmega128rfa1 MCU. If so, please provide pointers to the twi drivers or documentation for the same, or suggest factors that should be considered for developing such drivers. Thank you.
If you don't have any luck finding/creating a driver for the TWI peripheral, you might consider emulating it by configuring the SDA/SCL pins as general I/O and then implementing the TWI protocol yourself. If you're just doing a one-time read of a chip ID then speed probably isn't a big concern, so this could work if you get desperate. Google should throw up a few examples of emulated TWI.
I am trying to use the low level c-api of DBUS to implement a server-client over sockets. My question is .. is it necessary that a bus should be used always for dbus communication. And does a BUS just means an extra instance of dbus-daemon.
Yes, you need a bus for DBus communication. The bus is a communication channel, nothing more. More buses do not mean more instances of the Dbus daemon, it only means more communication channels.
In a system, you usually have one DBus daemon with one or more buses. Each bus is used for some class of messages (defined in your application).
2 applications can communicate via DBus, bypassing the daemon, by specifying the name of the client to which you want to send the signal/method (the DBus standard allows it). However, I don't think there is a DBus binding that offers this feature. But if you want to use the raw C API of the DBus, you can implement it yourself. You can check this discussion for more information on the topic.
Not sure about C API, but you can have client and server connecting directly using my node.js dbus implementation. Here is an example