I'm working with board support package (BSP) in VxWorks that uses pciAutoConfig() to configure the PCI bus. When I add an Ethernet controller card to the bus the pci display routines do not show the card.
Using a bus analyzer I discovered that the Ethernet adapter actually consists of a PCI-to-PCI bridge with two Ethernet controllers behind the bridge. It appears that the BSP is not properly dealing with the PCI-to-PCI bridge that the Ethernet controller contains.
My question is, what library and configurations should I look at to configure the PCI-to-PCI bridge? I'm thinking these calls will go in sysHwInit(), where the existing pciAutoConfig() calls are.
pciAutoCfgCtl() has a PCI_BRIDGE_PRE_CONFIG_FUNC_SET parameter that points to a user defined function to configure the bus. Is this the only method? Or is there something in the VxWorks libraries that can do this for me?
I think looking at the BSP-specific PCI auto-configuration routines is the way to go.
Is the PCI-to-PCI bridge on your network card being enumerated properly? Do the primary and secondary windows make sense? Is there enough overall PCI memory space to include the space required for the secondary bus on which the Ethernet controller chips are located? If not you may need to increase the PCI_MEMIO32_SIZE_SET value.
If the enumeration of the bridge on the adapter card is not correct you should be able to manually configure the bridge by adding code to the BSP's sysPciAutoconfigPreEnumBridgeInit() routine.
Does the BSP provide a sysPciAutoconfigInclude() routine which will enumerate the Ethernet controller devices on the network adapter by default? If not you will have to add the Ethernet controller devices to it otherwise they will be ignored during the enumeration cycle.
Related
I am bit confused about two emulated device hw/net/virtio-net.c and hw/virtio/virtio-net-pci.c present in QEMU source.
It looks to be that virio-net-pci.c is NIC emulation based on virtio specs but I didn't get what hw/net/virtio-net.c is used for ?
Apart from that I see, hw/net/vhost_net.c but didn't understand under what scenario this has been used ?
Conceptually, virtio devices in QEMU's implementation come in two parts: the "transport" and the "backend". The "backend" is the part that does the actual job (network, block device, random-number generator, etc); the "transport" is the part that is the interface to the guest (PCI, MMIO, s390 CCW...). This allows us to provide the virtio devices in multiple different ways without code duplication.
hw/net/virtio-net.c implements the 'net' backend. hw/virtio/virtio-pci.c implements the PCI transport. hw/virtio/virtio-net-pci.c implements a PCI device that provides a PCI transport to a virtio net backend device (and is a fairly small file because it's just gluing together the common transport and common backend code).
hw/net/vhost_net.c is, unsurprisingly, the implementation of the vhost-net support as described in the RedHat blog post that KagurazakaKotori gave you a link to. You can pass the guest a virtio network device without having to use vhost-net -- you can use any of the QEMU network backends.
My dad wants me to make kind of a smart home.
I would like to interface with KNX (a home automation protocol) using the GPIO on a Raspberry Pi 3. Ideally, I would like to build a web interface for it, but I don't have a clue how to interface with KNX in the first place.
Any suggestions?
It wont make sense for you to interpret and understand the KNX bus communication protocol directly. There is a massive specification behind the KNX bus which deals with so many problems from device addresses to collision detection. It would take years to master it and unless you develop KNX devices you really should not spend your time on it. You will be better off by doing the following:
Buy a KNX/IP gateway/interface such as https://www.mdt.de/en/products/product-detail/system-devices/system-devices/ip-interface.html
Understand that KNX bus traffic can be routed/tunneled to your home LAN/WIFI
Play around with one of the KNX libraries on GitHub. For example for C#: https://github.com/search?l=C%23&q=knx&type=Repositories&utf8=%E2%9C%93
If you want, have a look at my experimental .NET Core project which starts a radio streaming process when someone touches a button (in the bathroom in my case). It runs on any operation system (so Raspberry and Linux are fine) and you can find it here: https://github.com/ThomasZeman/KnxNetCore
check this website : http://michlstechblog.info/blog/raspberry-pi-eibknx-ip-gateway-and-router-with-knxd/ that might help. also there are special knx 2 ip devices sold by electronic stores
You can't connect the KNX bus to anything on the pi. The KNX bus has its own electrical specs, and you need specialized hardware to connect to it.
Such hardware is available, but probably a KNXnet/IP device (such as the Siemens N148) is a better option.
I see two options for you:
A) use an IP interface (e.g. the ones from MDT) and access the IP interface from your raspberryPi (e.g. with http://calimero-project.github.io/)
B) use a TPUART controller, which makes KNX TP telegrams accessible (r/w) to UART - see http://www.konnekting.de/konnekting-lernen/l1-knx-mit-arduino/
I'm interested in interfacing an STM32-based flight controller with external sensors based on the SPI (Serial Peripheral Interface) protocol. I have a couple of FCs (Flip32 F3, shown in attached photo; EMAX Skyline 32) that have a section of pins marked 5V/GND/RST/SCK/MISO/MOSI, which I presume are there to support ISP (In-System Programming); i.e., these pins allow the FC to act as a slave device for a programmer device that acts as the master. Other boards, such as the multiFlite NANO-B-FC, provide pin headders explicitly for SPI (other attached image), with CS (Chip Select) instead of RST.
Am I correct in these assumptions: i.e., the first kind of pinout (RST/SCK/MISO/MOSI) does not support an external SPI sensor, and the latter (CS/SCK/MISO/MOSI) does?
Flip32 F3 flight controller; ISP pads upper-left:
MultiFlight Nano-B flight controller pin header schematic:
I don't know these boards, just had a look at some pics on the internet.
The Flip32 F3 seems to have an Atmel ATMEGA microcontroller on board. (as an auxiliary MCU) I would assume that the 6 pins you found are the ISP interace for that MCU.
Just use a multimeter in continuity test mode and check if the 6 pads are connected to the ISP pins of the ATMEGA.
The board's main MCU STM32 is more likely programmed through the SWD (serial wire debug) interface. That's a pin-reduced JTAG alternative. Just google for it.
Here are some details if you are interested in Atmels ISP:
http://www.atmel.com/images/doc0943.pdf
If the firmware supports it (or you write one that supports it) you should be able to use the ISP interface as a normal SPI interface which it basically is.
ISP is usually done through a simple serial interface like JTAG, SWD or in the AVR case SPI.
Best way to find out: Read the datasheet of your ATMEGA.
I am planning to make some microcontroller boards which would do miscellaneous tasks. For example measuring analog voltages or controlling other instruments. Each board needs to be controlled/downloaded it's data from one place. For that purpose I would use an ethernet interface and do the comnunication over that. So my question is: which would be the most suitable method of achieving that. My ideas are: run a webserver on each module and communicate with POST/GET, or run a telnet server on boards and communicate with a telnet client. The security and speed/latency is not an concern but the data integrity is.
I don't need a html based gui for modules because I will implement an application which will communicate wizh the modules periodically, gets the data from them and stores in a database. And the database is what I will use later, for examining the data for example.
An other example:
I have a board which measures measures temperature. There is a server on the board itself run by the mcu. It is connected to a router via the ENC chip. I have my pc also connected to that router. I have an application which connects to the server run by the Atmega328 and collects the data then stores to a database. It repeats this let's say in every hour. I would use an Atmega328 and an ENC28J60 ethernet interface chip. What do you recommend?
Is it possible to read the bits directly off the physical ethernet connection interface from a standard computer ethernet interface?
e.g., suppose I want to use the ethernet jack of a laptop as a differential logic probe(using a standard ethernet cable). Could I just potentially write a driver to get at the bits or is there a limit to how low a driver can go?
Essentially does the physical layer just send the bit stream to the device driver or does it do any decoding which will effect the interpretation of the bits or cause the device to malfunction(such using a different encoding scheme).
I guess what it boils down to, is, can we use the ethernet port as any standard digital differential communications link by writing a suitable driver or are we limited to the the ieee spec(8b/10b, etc...).
To answer shortly, probably not.
Here are some of the reason why:
On a hardware link layer, there is actually no electrical connection between the computer and the ethernet cable, it is electrically isolated by small transformer and is current and not voltage driven signal, so this will be the first problem to overcome, as you would have to send a fairly precise current over two lines rather than a voltage on a single line.
Ethernet transformers
PHY Hardware Interface: Then the next step, is that this is simply not controlled by the CPU where your code is being executed but by an ethernet PHY Chip interface, and there you have no (easy) way of flashing and controlling it. Some different PHY chip allows you different level of access, but I doubt you would find any that would allow you direct control over the transmission interface and even if it did, it would have to be implemented into the driver which is as well unlikely.
Ethernet PHY Controller
Perhaps some other solutions
as the comments above, if you want to have direct IO control on a computer, the best solution is over a serial or parallel port, perhaps you can find ethernet to serial or usb to serial port and then play with that but this would be digital signals.
Another thing you may want to use is the microphone input, as this accepts analog signals and you can have direct control over it, though be careful not burning your computer. (I've seen some bank card magnetic band using that on cellphones).
You can use libpcap/WinPcap to do this. Nevertheless you are not completely free in the choise of what you write/read on the wire. e.g. preamble and SFD must stil be there. This is so fundamental (because of noise resistance), that typical hardware just does not support anything different.
If you want to control completely everything, go to embedded hardware, find a board that uses a PHY that can give you that information and a processor that is capable of handling the data rates.