I am building a network utility for OS X. I've gone through Apples documentation, but I cannot find the framework that allows my app to monitor incoming bytes. Can anybody point me in the right direction? Thank you for your time!
To get statistics on a network, you can use the sysctl system call. This is fairly thinly documented; there's another answer on StackOverflow that gives a brief example, and for more detail, I'd recommend looking at the netstat source code.
I think for something like this could be done with
http://www.wireshark.org/ or http://www.tastycocoabytes.com/cpa/
In Linux you could simply listen to the file that is associated with your network card.
But I don't think this can be done an easy way on OS X. But indeed there must be some way, thinking of LittleSnitch.
You can use libpcap, which is a portable library for doing packet captures used by tcpdump, Wireshark, and more. It's not an official Apple library, but it's BSD-licensed so you shouldn't have any problem using it.
Related
I'm trying to get the video feed from usb camera attached to my Raspberry. Since it's not the dedicated one I can't just use raspivid or the raspicam that comes with uv4l to make changes to config that actually gives some effect at contrary to v4l2-ctl.
When I connect to the WebRTC server through the browser client it actually works at decent framerate. I don't yet understand how that technology works, but before jumping into it I was wondering if someone could tell me if it's possible to somehow (with client made in python or some other opencv magic) get that video feed.
Thanks in advance
I'm still interested if what I've talk about is possible, so if anyone with knowledge stumbles upon this thread, please let me know.
I've kinda solved my issue by using the mjpg-streamer experimental instead, it can be found here:
https://github.com/jacksonliam/mjpg-streamer
Now I'm getting over 8 fps, but it seems much more constant and really seems like I don't need more, compared to uv4l that gave me 3.5 fps with stutters.
I am building a temporary controller that needs to monitor 20 separate button pushes along with another 15-20 analog and digital signals.
It also needs to output at least 20 different digital signals.
Which Netdurino will let me get all these different ports together on a single device?
It seems like the Netduino Go with multiple shield bases (image) is the way to go.
Can anyone confirm that this is the hardware solution I am looking for with the most analog and digital ports available?
Thank you,
Keith
Seeing as you're settled on the Netduino platform, I'd suggest you ask either on the Netduino forums or in their live chat room http://forums.netduino.com/index.php?/chat/
Alternately, https://electronics.stackexchange.com/ might yield better answers than stackoverflow.
Note that in the forum post you link to for the shield base, they indicate that only one shield base is supported per Netduino (at the time of writing, this may have changed):
Another noob question: How many shield bases can one connect to a NGO? Is more than 1 a viable option?
Currently just one. But with the final release I'm hoping on more :)
I've been looking for a detailed description for how USB protocol and cabling works for a long time with no luck. I am looking for a detailed yet not overcomplicated explanation of how things work on the software and hardware side of USB. Links and explanations would be appreciated. I've really run out of ideas, so it would be great if you can help me out.
This is what I do know:
USB hardware carries 4 lines- 5V power, ground, and 2 full duplex lines.
When connecting, the device can ask for a specified amount of current.
The transfer speeds for USB are quite fast compared to traditional serial connections.
When connecting, a device will output descriptors to the host describing itself. These descriptors will also be used for data.
What I don't know:
How does a program in C/C++ write directly to a USB port? Does it write to an address in the port?
How do some devices describe themselves as HID?
How do drivers work?
Everything else...
Thank you!
Identification
Every device has a (unique) Vendor and Product ID. These are provided (sold) by usb.org to identify a device. You can use a library like libusbx to enumerate all connected devices and select the one with the Vendor and Product ID you are looking for.
HID Descriptors
The point of HID descriptors is actually to do away with drivers. HID descriptors are a universal way of describing your device so you don't need to waste time on a driver for every system/architecture/etc/. (Same concept as the JVM.)
Reports
You will use either the input, output, or feature reports to read or write to your device. You send a stream to your device on the input or feature report. This is typically 8 bytes I believe. Only one of which is a single character you wish to write. The HID descriptor contains all the information you need to put together a report. Although I'm struggling to find a related link to clarify this.
Potential Libraries
In an effort to be open-minded here are all the libraries I am familiar with and some info about them.
libusb-0.1
First off is libusb-0.1. This used to be the go to and was built in to many Linux kernels and Windows I believe. It is very easy to use and there is a lot of documentation. However, the owner never updated and it wasn't edited for many years. It supports only synchronous transfers. (If an error occurs, the program can wait infinitely while it expects a transfer.)
libusbx
Next is libusbx. This is what most people would suggest today and I agree. It was published by those frustrated by the owner of libusb-0.1. The code is much more lightweight, up-to-date, and importantly does not require root privileges like libusb-0.1 and libusb-1.0 (Discussed in a second). It supports synchronous or asynchronous transfers.
libusb-1.0
Then there is libusb-1.0. This was the first update to libusb-0.1 in some number of years. It is not compatible with libusb-0.1. This was published the same day as libusbx as a retaliation (I assume) and an attempt to rectify the lack of updated content and conserve a user-base. It supports synchronous or asynchronous transfers.
hid.h
Finally, there is the hid library. This was built on top of libusb as another layer of abstraction. But honestly, I think it's just really confusing and it just adds more overhead than necessary.
Some Good Resources
Understanding HID Descriptors
Control Message Transfer Documentation (Very Good Link IMO)
Rolling Your Own HID Descriptor
Good Visual of HID Reports for Transfers
Great List of bmRequestType constants (You will need this or similar)
A simple terminal app for speaking with DigiSpark using libusbx and libusb-0.1
I know this isn't exactly what you are looking for, but maybe it will get you started!
This website has a general overview of how USB devices work:
https://www.beyondlogic.org/usbnutshell/usb1.shtml
Particular sections give answers to things from the list of things you don't know yet about USB.
E.g. to find out how USB devices identify themselves, read about USB descriptors:
https://www.beyondlogic.org/usbnutshell/usb5.shtml#DeviceDescriptors
To learn how a C/C++ program can talk to a USB device, see examples on using the libusb library:
https://github.com/libusb/libusb/tree/master/examples
To learn how USB drivers work, see a tutorial from Bootlin:
https://bootlin.com/blog/usb-slides/
I have a kernel 2.6.31 booting from a USB stick using Intel 915 based KMS to get to graphics mode. It appears to be setting itself to the native resolution and its booting nicely into framebuffer console with a beautiful Tux logo!
Question is, how do I access the inteldrmfb? How do I get it into /dev? Will udev do this for me?
What is the API for programming the framebuffer directly?
Thanks,
FM
Try the directfb library?
edit:
The kernel API is documented in linux/Documentation/fb. See Documentation/fb/framebuffer.txt in the kernel git tree, for starters. Doesn't seem to have changed for a long time. Probably still accurate. Kernel<->user APIs tend to be stable.
http://www.linux-fbdev.org/HOWTO/index.html. May be useful, but it's probably not as useful as the kernel docs.
Probably, as you say, the library source would be the best reference on how to do things.
If you're not seeing /dev/fb0, even though you have the module loaded, then maybe you need to configure udev for it? Or just mknod yourself.
I have been doing desktop programming for a while but want to get started with interfacing with hardware. Specifically, I would like to learn how to use serial ports to take an external event and alert my application (so for example, I can turn on a camera when motion is detected by an external sensor).
Please tell me how to get started, what type of sensors, what books (or online resources) are available. I tried Bing and Google but I need more pointers.
Serial interfaces are fairly simple to work with. But they do require some sort of a decoder on the other end (such as a UART.) Another option would be using the parellel port. The advantage of using a parallel port is you start with a break out of the I/O pins. You can typically control 8 devices with a very simple to build interface.
Most platforms gave a simple way to gain access to the LPT ports without too much effort and again they are very easy to interface.
Quick results for tutorials...
Parallel Port Programming
Parallel port output circuit
A tutorial on Parallel port interfacing
LPT Port Info...
Parallel Port (PC)
LapLink Cable
Printer Cable
IEEE 1284-B
IEEE 1284-C
Centronics (36 pin)
I would recommend you the book Linux Device Drivers 3rd Edition
Although I haven't programmed any hardware interface yet, I think this book will get you ready to start hacking.
There really aren't a lot of one-size-fits-all tips for this. You're going to need to look at the documentation for your device, it should specify the protocol of what it will send over the serial port and what commands you can send in return.
Make sure you understand things like what means to have a text encoding like ASCII or UTF8. Most any device that sends and expects text will use an ASCII encoding.
I'm not sure what OS or language you're using, but be aware that you're sending raw binary data through a serial port, so for example if you're using C# you would want to wrap your serial port data stream with a StreamWriter or StreamReader with the correct text encoding.
If you can find an old modem online or craigslist that might be a good start. The serial comms specs for those are pretty well documented.
After that I would just start investigating things that you are interested in - your interest in the project will drive the learning and progress more than anything IMO.
I think this site has some fun things to try:
http://blogs.msdn.com/coding4fun/
You should get a data acquisition hardware and interface with that.
http://www.dataq.com/products/hardware/
If you just want to learn how to use the serial port, get another PC with HyperTerminal (included free with Windows), and use it to send and receive data from your development machine over the serial port. This will give you very manual control over what's sent to your development box, so you can get some confidence that what you're reading and writing is correct. Once you've got the basics of serial I/O down, you can move on to your camera/motion sensor/etc.
You don't mention what OS or development environment you're using, but in VS 2005/.NET 2.0, there is actually a SerialPort class. If you're doing raw Windows API, MSDN has an article at http://msdn.microsoft.com/en-us/library/ms810467.aspx which covers the basics. If you're using another OS, sorry I'm not that familiar (I know, boo hiss on me).
The most important thing is just remember to set your communication parameters on both sides of the connection the same. There are four parameters that govern if both sides can understand each other : baud rate, bits-per-byte (usually 8), parity bits (even parity, odd parity, none, or always 1 or 0), and stop bits. HyperTerminal also lists a "Flow Control" option, I recommend setting it to "None" until you get comfortable. Xon/Xoff flow control is a fairly common way of making the other side pause while you process a bufferfull of data.
Buy a microcontroller and build a simple robot, cnc mill or something. Atmel AVR and/or PIC is the most common from what i understand.
Also gives a lot of electronics experience