Can someone please tell me what is the temperature unit in MPU 9250 linux driver?
I've looked at the source here https://github.com/NoelMacwan/Kernel-10.4.1.B.0.101/blob/master/drivers/staging/iio/imu/inv_mpu/inv_mpu_core.c#L1112 and in the accompanying README file and I have not got a clue, what sort of temperature I get from the driver.
Related
Good day all!
I have an issue in code that I cannot find.
See here
Is it possible to setup GDB to see what the UART is getting in incoming serial data?
Thanks!
I'd suggest you to modify UART driver for Linux kernel and inside of this driver dump the incoming data. The GDB works in user space but you need to do this on the lower level - in UART driver. GDB has no access to registers of the physical device as the UART is.
I'm having trouble with an industrial Linux computer I'm working with to achieve communication over an RS485 bus with multiple connected devices. What I've encountered is that the IO pins used by the RS485 USART driver are set to different levels at startup instead of going to the RS485 idle/tri-state. As a result, the other devices on the bus are blocked for more than 30 seconds while the device boots up, triggering all sorts of external problems. The course of events can be viewed in the attached image, where I've measured the output voltages with an oscilloscope during startup.
My guess is that the actual driver is not started until the voltage levels reach their tri-state levels (e.g. ~2.2V for this device). After that everything works as expected.
I've tried to find any config-files to set the default IO level of the pins at boot (thinking this may be set by the bootloader) to no avail.
Also, I've tried to apply a startup-script to run "early enough" to set DATA- high, but the device in question does not provide any interface to control these pins as regular GPIOs as far as I can tell.
Any help, tips or insights would be much appreciated!
EDIT: I am not an experienced Linux developer, so please highlight if I've left out any important details.
Some specs:
ARM920T rev 0 (v41) CPU
Proprietary distribution of Linux 2.6
Uses Busybox
Atmel USART drivers
Extract from boot log:
Linux version 2.6.28.10 (root#) (gcc version 4.1.2) #94 PREEMPT Tue Oct 29 10:22:19 CET 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
/...
.../
RS485 mode for port /dev/ttyS3 enabled
/...
... (I'm guessing the ~30 secs elapse here)
.../
atmel_usart.3: ttyS3 at MMIO 0xfffcc000 (irq = 9) is a ATMEL_SERIAL
atmel_serial.3: Putting the RS485 RTS pin down
/...
...
.../
Full boot log: https://drive.google.com/file/d/0B2XYl1mNCa8jNUZ5V0Nic1hkU0U/view
Similar issue:
Possibly a similar issue is discussed here: UART initialisation: Prevent UART to pull RTS high
But I'm not sure how to proceed with the suggested solution.
This is little more than wild speculation, but it might be worth adding a start-up script that echoes a NULL character to the device (e.g. /dev/ttyS1 or whatever) as early as possible during start-up. This might be enough to kick the driver into initialising the hardware.
You could also try to locate the driver in the Linux source to look at how it starts up.
Probably you have access to the source code, so you can investigate who and when mess with the that GPIO. Just grep the kernel source for the atmel gpio controller port addresses to figure out what happen. If you are lucky may be there will be kernel command line option that you can pass from the bootloader to set the line to what you need in advance.
this answer may work if you can find required things mentioned below
of your board!
Once I also had a same issue on PWM. There I found that my bootloader was responsible for the same, I changed in bootloader configuration and it started working fine.
Check your BSP provided by board vendor or third party (If you have the source), If your bootloader is U-boot you can find it inside U-boot-(source)/include/configs/(your-board).h there you can find configuration for RS484. As per your datasheet for the board you can check for other things which are muxed on the same pin and disable those if not required for boot time and enable RS485.
enabling/disabling can be done by changing the values 0, 1 or 2 as per your configuration and also you can simply disable anything just by commenting // out the line.
I am creating my own midi-instrument and would like to know how to create a PC driver program for this instrument. Does anyone have any pointers or resources I could look at to help me complete this task?
All i have found so far is
1) https://msdn.microsoft.com/en-us/library/windows/hardware/mt187811(v=vs.85).aspx --> USB drivers
Just make your device conform to the USB MIDI device class specification, and you do not need to write any driver for the PC.
Check out the Driver samples for Windows 10. The Sample KMDF Function Driver for OSR USB-FX2 might be closer to what you need, if you want to write a USB device driver.
I am trying to export a pin (no. 110) using the following in linux:
echo 110 > /sys/class/gpio/export
When I try to do so, I getthe error message
ash: write error: Device or resource busy
As per my knowledge the pin is not being used by any module, but I may be wrong. I had the hardware line probed and the voltage is changing, the processor seems to be driving something to the line.
The pin according to the user manual is not multiplexed and is "commonly available".
The pin according to the user manual is not multiplexed and is "commonly available".
Apparently you are referring to a SoC manual.
Such a statement will only imply that the pin does not have a dedicated application by an integrated peripheral (as shipped by the SoC manufacturer).
That statement is invalidated when the SoC is designed into a circuit and/or installed on a board.
The document that you really need to consult is the board manual or the board schematics.
That should be the accurate documentation as to how the board designer used the available GPIO pins in that specific application.
When I try to do so, I getthe error message ...
Fortunately for you, the device driver that does use that pin (that you want to use) has properly performed the GPIO reserve/request call to prevent a hijack.
This prevented that other driver from breaking and/or a device/board malfunction.
As per my knowledge the pin is not being used by any module, but I may be wrong
How did you attain this "knowledge"?
Did you scan the .dts and .dtsi files used for your board?
Did you check the source code of every device driver used by your board?
I want to access my Motherboard's ISA Bus to read temperature sensor values and set cooling fan speeds.
I could not find any practically helpful information but the hint to use "GiveIO", a unviersial I/O driver which unfortunately is not compatible with windows 7.
If there is no avoiding of coding a driver, any useful information on how to get startet would be highly appreciated.
There is an open source hardware monitor at http://code.google.com/p/open-hardware-monitor that seems to do what you want. It uses the WinRing0 driver for hardware access.
To directly access the hardware under Windows, one must write a device driver.