I can't seem to find a good comprehensive list of available ioctls for netbsd.
I am looking to do some operations on harddisk (getting size, physical sector size, model). I have the code working in linux. It looks something like this, I removed errors etc to make it more compact:
ioctl(fileno(driveptr[i]),HDIO_GET_IDENTITY,&hd);
ioctl(fileno(driveptr[i]),BLKGETSIZE64,&drivesize[i]);
ioctl(fileno(driveptr[i]),BLKPBSZGET,&psztemp);
Is there an equivalent to these ioctls in netbsd?
regards
The driver source for a given type of disk interface (or any other kind of device driver) is probably the best canonical place to find device specific ioctls.
NetBSD at a systems level, like many unix-based systems, tries hard to avoid being hardware specific, even in terms of providing detailed hardware specific information to user level. The goal of unix, after all, is to provide a system that is uniform across a wide variety of hardware platorms, not to provide detailed low-level access to specific hardware. The very best you can get in terms of hardware specific details is the information printed by the drivers at boot time about the hardware as it is probed and attached.
At a more generic level you can basically only get disk and partition labels -- i.e. information pertinent to the way the system presents disk devices to userland. Unfortunately the only driver manual page that documents these is sd(4) (cd(4) has some more detail about more ioctls specific to cd-rom devices). scsi(4) documents bus-level ioctls for SCSI and ATAPI interfaces.
On x86 platforms there's "sysctl machdep.diskinfo" (and the equivalent C level interface via sysctl(3)) to get details about what the BIOS reported about the disks it knew about at boot time, but that may be incomplete.
Related
Background
I'm very new to electronics/IoT dev. I'm trying to create a solution to be able to read my wife's Car's CAN Bus signal (messages) and store it to an SD card. I hope to analyze the data and build a dashboard based on the car's telemetry.
This specific question is in relation to a chip (STM32F1) on an IoT board (MXChip AZ3166) I already own, which I hope to incorporate into my overall solution as the data acquisition layer.
For reference the:
Chips is the: STMicroelectronics STM32F103C8T6, 32bit ARM Cortex M3 Microcontroller
and the IoT board is the: (MXChip AZ3166 IoT DevKit)
Reading the MXChip AZ3166 board's spec and after doing some research, I have found out that the MXChip AZ3166 comprises two main chipsets:
Vendor
Part Number
Ref Link
STMicroelectronics
STM32F103C8T6
https://uk.rs-online.com/web/p/microcontrollers/1023545
MXChip
EMW3166
https://www.mxchip.com/en/products/module/54
Main Question
The product specification mentions the STM32F1 features Comprising of motor control peripherals plus CAN and USB full speed interfaces, it also states it has 1x CAN Channel. Does that mean I can interface the MXChip AZ3166 board featuring this chip via the GPIO pins to the CAB bus in my wife's car and receive the CAN Bus signals (I presume adhering to the
ISO 11898-1 CAN data communication protocol).
How would I find out which pins to connect to the CAN Hi & CAN low connections on the cars CAN Bus?
Concerning power, how would I determine that the CAN signal received doesn't fry the MXChip Board with a stated max Operation voltage of 3.3v?
Yes you'll want an MCU with a built-in CAN controller for communicating on a CAN bus. However, the CAN standard only covers the physical and data link layers. You need to know the application layer in order to meaningfully interact with a bus.
The application layer on a car may or may not be proprietary. It may even be encrypted. If you don't know what protocol is uses, then no can do. Reverse-engineering CAN protocols is hackish, hard and dangerous. Plugging into a CAN bus where you have no clue about timing considerations etc is also very dangerous.
But cars usually have an "on-board diagnostics" (OBD) port used for service purposes, with standardized application layers, through which you may have access to various parts of the car. There's lots of different standards for OBD and older ones didn't even use CAN. It depends on the car model.
In case of the OBD port the pinouts are standardized and you can find them on the Internet. Otherwise it is very simple to find out which signal that's CANH and CANL with an oscilloscope. CANH goes 2.5V +1V and CANL 2.5V -1V. A more hacky solution is to measure this with a multimeter, but it's perfectly possible since one signal with be slightly above 2.5V and the other slightly below.
CAN is standardized so if you have a CAN bus on the board, you connect there. In some cases there may be 12V supply wired together with the signal and that's the only one which could fry something.
Overall, please note that the project you describe here is very difficult and not a beginner task. It sounds as you have next to no experience of electronics/embedded systems, so I would recommend picking a far simpler project.
Furthermore, modifying car electronics or installing your own electronics in a car is illegal in most parts of the world. Third party type approvals with EMC tests are mandatory (and very expensive). If your car is involved in an accident and they find custom electronics without type approval in it, you could be facing serious legal consequences.
When a manufacturer designs a hardware device, they obviously have someone who is in charge of writing a driver for that device for different platforms.
While I know that there are probably more than one "type" of driver for different types of devices, a driver for a device by it's nature must be very different from a normal application or script.
I've always wanted to pick apart a driver just to find out how it allows an OS to interface with hardware, but my programming knowledge is lacking.
Out of curiosity, I'd just like to know:
How does a device driver work, exactly?
When designing a driver for a device, what things do programmers consider?
What languages are drivers written in?
What is the overall process for designing a driver?
I suggest that you read (at lease the first chapter) "Linux Device Drivers". It will answer your basic questions and will allow you to study how to develop device drivers for Linux OS if you want to.
You can find it here: http://lwn.net/Kernel/LDD3/
When designing a device driver, programmers look at the functionalities of the device that are to be implemented and write the driver accordingly
I prefer C / C++ for writing a device driver
but have seen driver in assembly language also
overall process is dependent on device itself
My and my fellow students are deciding on a choosing a simple microcontroller to do very basic image processing. We are basically trying to implement template matching to find a set of objects in specific portions of the image. We'd like to use a connect a webcam to the microcontroller to do the job take the pictures and look for the objects. We also require basic wireless communication (e.g. bluetooth or wifi).
I don't think we will have the luxury of using state-of-the-art microcontroller, but something thats been around for a while (due to budget and stuff). Could anyone please advise on which specs of the microcontrolelr would be the most relevant for the above task (e.g. CPU, MIPS, etc).
Thanks a lot!
For this kind of a task, I would say the amount of RAM is the most relevant spec.
A microcontroller with an external memory interface allows you to extend the data space with additional SRAM to hold your image data.
Also note, that memory is needed for any protocol stacks you need to implement (Bluetooth, TCP/IP even more so).
You probably want to have total RAM in tens of kilobytes, preferably 100+ kB.
It is also nice to have plenty of program memory available when learning and experimenting. Later on you can try to optimize and squeeze your code into a more confined device.
As for the architecture, choose something you can easily find development tools and examples for.ARM, AVR and PIC are all good candidates among others.
Also find out what interfaces you need to use to
control the camera (e.g. I2C or SPI)
read pixel data (e.g. parallel or analog)
Connecting directly to a webcam's USB interface would not be a straightforward task, as the microcontroller would need to act as a USB host.
Good luck with your project!
You may need a microcontroller with following features:
USB 2.0 Host controller
1.2MB of memory for buffer 640*480*2(bytes per pixel)*2(double buffer)
(you may use lower resolution if there are not enough memory)
Wifi controller
CPU power strong enough for your task
Ready open source code
It seems that broadcom controllers may be useful here.
Also, you can by off-the-shell Wifi router with usb port and use it for your project
(i.e. Linksys E3000 )
If I was told I needed to create a driver for some product (say, a game controller), how would I go about creating one? Is this something you could do normally in C/C++?
And what about firmware for external deviced connect to USB? How is this created usually? Is this also done in C/C++, or some lower level language?
Thanks!
Device drivers for desktop computer operating systems are generally written in either C or C++. The operating system you would target will have some form of framework or device driver development environment. Often these development kits can be obtained free of charge.
There are books available for Windows, Linux, and MacOS X (and others) that detail the process of creating a device driver.
If your driver is related to a device on a specific hardware bus (PCI, PCI-X, USB, SCSI, SATA, etc.) you can also get books on that specific technology. An understanding of that hardware system can greatly facilitate the design of your driver.
Another good resource is the open source code for similar devices to yours. You can obtain that from the Linux kernel source or FreeBSD source and study how certain aspects of your type of device are implemented.
EDIT: I nearly forgot to mention that you will also need data sheets, schematics, and/or theory of operation information about the device itself.
I'll add to Amardeep's good answer with the following books that will help you think about the context device drivers operate in, and how they're structured:
Linux:
http://www.amazon.com/Understanding-Linux-Kernel-Third-Daniel/dp/0596005652
Windows:
http://www.amazon.com/Programming-Microsoft-Windows-Driver-Model/dp/0735618038/ref=sr_1_1?ie=UTF8&s=books&qid=1277439434&sr=1-1
Mac OS:
http://www.amazon.com/Mac-OS-Internals-Systems-Approach/dp/0321278542/ref=sr_1_1?ie=UTF8&s=books&qid=1277439467&sr=1-1
You do it in any language that can talk to the interface. If it requires poking ports or addresses directly then you use assembly or C. If there's a higher-level interface such as libusb then you can use almost any language you like.
Is it possible to get location data out of Google Gears, Google Gelocation API or any other web location API (such as Fire Eagle) in such a format that it appears to other software as a GPS device?
It occured to me reading these answers to my question regarding WiFi location finding, on Super User, that if I could emulate a GPS unit, many of these web services could act as a 'poor-mans' GPS to otherwise less useful software that requires it.
Is GPSD an option?
Preferably OSX & Python, but I would be interested in any implementation.
There is a very similar thread on a Python mailinglist that mentions Windows virtual COM ports and discusses Unix's pseudo-tty capabilities. If the app(s) you want to use let you type in a specific tty device file, this may be the easiest route. (Short of asking the authors to provide a plugin API for what you're trying to do, or buying yourself a $20 bluetooth GPS mouse.)
Are you using OS X?
There is a project macosxvirtualserialport on Google code that provides a graphical wrapper around some of the features of a utility called socat. I'd recommend taking a look at socat if you see potential in the pseudo-tty route. I believe you could use socat to link a pipe from a Python program to a pseudo-tty.
Most native Mac apps will be querying IOServiceMatching for a device with kIOSerialBSDRS232Type, and I doubt that a pseudo-tty will show up as an IOKit service.
In this case, unless you can find a project that has already implemented such a thing, you will need to implement a driver as described in this How to create virtual COM port thread. If you're going to the trouble of create a device driver, you would want to base it on IOKit because of that likely IOServiceMatching query. You can find the Apple16X50Serial project mentioned in that post at the top of Apple's open source code list (go to the main page and pick an older OS release if you want to target something pre-10.6).
If your app is most useful with realtime data (e.g. the RouteBuddy app mentioned in the Python mailinglist thread can log current positions) then you will want to fetch updates from your web sources (hopefully they support long-polling) and convert them to basic NMEA RMC sentences. You do not want to do this from inside your driver code. Instead, divide your work up into kernel-land and user-land pieces that can communicate, and put as little of the code as possible into the kernel part.
If you want to let apps both read and write to these web services, your best bet would probably be to simulate a Garmin device. Garmin has more-or-less documented their protocol in the IntfSpec.pdf file included with their Device Interface SDK. Again, you'd want to split as much as you could into user-space code.
I was unable to find a project or utility that implements the kernel side of an IOKit-based virtual serial interface, but I'd be surprised if there wasn't one hiding somewhere out there. Unfortunately, most of the answers I found to that question were like this, with the developer being told to get busy writing a kext.
I'm not exactly sure how to accomplish what you're asking, but I may be able to lend some insight as to how you might begin to get it done. So here goes:
A GPS device shows up to most systems as nothing more than a serial device -- a.k.a. a COM port if you're dealing with Windows, /dev/ttySx if you're in *nix. By definition, a serial port's specific duty is to stream data across a bus, one block at a time. So, it would then follow logically that if you want to emulate the presence of a GPS device, you should gather the data you're consuming and put it into a stream that somehow acts like an active serial port.
There are, however, some complications you might want to consider:
Most GPS devices don't just send out location data; there's also information on satellite locations, fix quality, bearing, and so on. Then again, nobody's made any rules saying you have to make all that data available. There's probably more to this, but I'll admit that I need to do more research in this area myself.
I'm not sure how fast you can receive data when dealing with Google Latitude, etc., but any delays in receiving would definitely result in visible pauses in your "serial port"'s data stream. Again, this may not be as big a complication as it seems, because GPS devices are known to "burst" data across the bus anyway, but I'd definitely keep an eye on that. You want to make sure there's always a surplus of data coming across, not a shortage.
Along the way you'll also have to transform the coordinates you receive into valid GPS sentences, as well. You can find specifications for those, but I would definitely make friends with the NMEA standard -- even though it is a flawed standard, it's the one everyone seems to agree on anyway.
Hope this helped you, at least a little bit. Are there anymore details specific to your problem that you think could be useful in answering this question?
Take a look to Franson GPS Gate which allows you to connect to Google Earth among other things (like simulating GPS and so on). Is windows only though but I think you could get some useful ideas from it.
I haven't looked into it very much, but have you considered using Skyhook's SDK? It might provide you with some of what you are looking for. It's available for every major desktop and mobile OS.