[P1100 Usb Ews Device Driver Free Download
Hanne Rylaarsdam
We have some software that is writing two blocks of data out to an FPGA using SPI port 2 that is exposed to user space as spidev1.0. I can see that spidev1.0 exists in the /dev directory in embedded Linux as it should. The way this works is, initially, we have two blocks of data that is written out through the SPI port. Once this is done the FPGA will then toggle GPIO line 128 and that generates an interrupt. We have an interrupt handler in place that uses the embedded Linux poll() function to wait for the interrupt to occur and then send a block of data out to the FPGA. This happens on each interrupt.
When we run our software, and using a logic analyzer, we see one block of data is sent out to the FPGA using SPI port 3 as it should, but it takes a long period before the second block is written. Also, the interrupt handler detects an interrupt and sends out a block of data as it should, but then nothing else seems to happen, and occasionally the embedded Linus OS locks up and we have to power cycle our device.
spidev is the generic user space interface to the SPI driver in the kernel. toradex,evalspi is used to activate spidev while the compatible ecspi property would activate the iMX SPI driver specific to iMX7. spidev will use the iMX SPI kernel driver which does use DMA. What exact version of Linux image are you using? What is the output of cat /etc/issue and uname -a?
But, if we use a buffer size for the SPI write that is 198 words, or 396 bytes, the write works as it should, and we see interrupts occurring at a rate of around 13.5 milliseconds.
The longer time between interrupts is due to the fact that the FPGA FIFO is receiving the data it needs at the proper rate and does not need to make interrupt requests for data as often. I do occasionally see the error output above from the SPI driver only once on startup, but the data output from the SPI port seems to be correct.
@Gage05 It seems the problem you report has been fixed in mainline kernel atleast. A quick way to try would be to replace the spi-imx.c SPI driver with the one from here and check. Can you please also check this once at your end and confirm that this fixes the issue for you? I checked at my end using the test code you provided and the mainline kernel driver does not trigger the RX DMA error. In the meanwhile, I will be looking into which exact patches we need to backport to fix this. The issue is probably related to the DMA timeout being hardcoded in the downstream NXP kernel while the mainline kernel calculates this dynamically.
Actually, I tried the driver code that you linked to this post above. When I built it into the embedded Linux OS and performed my initial testing it appeared to be working great and the issue no longer occurred. I could specify any buffer size and the long delays we were seeing in writing data out using SPI were gone.
We saw that SPI communication worked fine for a time, but after a while everything became desynchronized and the communication no longer worked. When viewing the SPI clock line, and MOSI data line on a logic analyzer these lines were not doing what they were supposed to. Power cycling the device corrected the problem, but the desynchronization would eventually occur every time while using the SPI port.
Well, it turns out that the issue with the current SPI device driver is a problem for us. With the current SPI device driver interrupts are occasionally missed and the output we see from the SPI port is not correct as a result. There are inconsistencies in the output.
What is the CPU load when your application runs? At least with the mainline kernel driver I was not able to reproduce the issue with the test Qt application you had provided or spidev test code. Can you also try by disabling DMA by adding the below to ecspi3 node in your carrier board dts file?
In looking at the SPI port device driver code I can see that the: I/O Error in DMA RX error seen is in the spi_imx_dma_transfer function in spi_imx.c at the point where wait_for_completion_timeout is called to wait for data to be received. The timeout is occurring and generating the output that we are seeing.
The new SPI device driver code is better in one way. It allows us to choose buffer transfer sizes that, before, were causing issues. Now these buffer transfer sizes seem to work better and there is no longer a pause between writing out sections of the buffer over the SPI port.
I started looking into this issue now. I do not have a setup to reproduce the rx side of things you have, though the issue seems to be easily reproducible for tx on our/NXP downstream kernel. The DMA implementation seems to be not correct.
If the driver listed is not the right version or operating system, search our driver archive for the correct version. Enter HP LaserJet Pro P1100/1560/1600 into the search box above and then submit. In the results, choose the best match for your PC and operating system.
Once you have downloaded your new driver, you'll need to install it. In Windows, use a built-in utility called Device Manager, which allows you to see all of the devices recognized by your system, and the drivers associated with them.
In Windows 8, swipe up from the bottom, or right-click anywhere on the desktop and choose "All Apps" -> swipe or scroll right and choose "Control Panel" (under Windows System section) -> Hardware and Sound -> Device Manager
HPIJS is a monolithic driver that supports many different printers. Common printers are divided into different device classes. Each device class shares common printer attributes such as print modes and paper sizes. HPIJS will automatically map the DeviceModel parameter to one of the devices classes.
The following device classes are currently supported by HPIJS. Each device class supports 300x300dpi unless specified otherwise. The DeviceModel parameters listed for each device class are case sensitive.
The 3320 series handles pen alignment parameters differently than normal HP inkjet printers. Most inkjets store pen alignment parameters in the printer, and any pen alignment values would be used by the printer firmware. For the 3320, pen alignment parameters are stored in the printer, but any pen alignment would be performed by the device class.
The DJ3320 device class stores pen alignment parameters in the printer. In uni-di mode, the pen alignment parameters are not available. This could be an issue with two pen color print modes - Draft Color and Normal Color (KCMY). This is not a problem for two pen Photo mode (mostly CMY). Pen alignment parameters are not needed for single pen print modes (specifically: PenSet=1).
In Draft and Normal modes the DJGenericVIP device class will detect photo paper and automatically print in Photo mode. HiRes is another photo mode which supports the maximum resolution of the printer. HiRes mode does not do auto media detection. Resolution setting 600x600 is available for Normal modes. Resolution setting 1200x1200 is available for HiRes mode.
Some newer printers support a FastDraft print mode that prints at 300x300 resolution. The Draft Color and Draft Grayscale modes produce higher quality output than FastDraft. Those printers in this class that do not support a FastDraft mode will exhibit no difference in FastDraft and the regular Draft modes.
Note, some DeviceModel parameters listed above for each device class are not the full Model string returned by a IEEE 1284 Device ID query. When HPIJS maps the DeviceModel to a device class, the match is wild-carded and trailing characters are ignored.
For example, a Device ID query on a Deskjet 990Cxi will return "DESKJET 990C". If DeviceModel="DESKJET 990C", HPIJS will match to "DESKJET 99", ignore the "0C" and select the DJ9xxVIP device class. See the proxy table for each device class (specifically: dj9xxvip.h) for a list of model strings and how they are wild-carded.
I moved my computer downstairs... after a few weeks I decided to move my printer down and set it up. I had it working perfectly a few weeks ago before the move... however now I can't get CUPS to detect or add my printer. At first when I moved my printer downstairs the CUPS web interface had my previous setup still there and had my printer detected / added. However, printing jobs would just stay in the queue and never print. I did some googling and someone mention to remove the printer and re-add it. Well I tried to to that and got stuck on trying to re-add it. CUPS will not identify my printer now. Funny thing is I just now remember I had a similiar issue a few months back and I remembered now I fixed the queue issue just by unplugging the power to my printer and leaving it off for 5min then replugging it in. I have tried all the steps on the wiki and I can't seem to figure this one out. dmesg does output that it is detecting my printer. I have my printer hooked up via a mini parralel to USB cord. If you have any other questions for me please shoot
If it matters I am using XFCE as my DE... I also do not remember using the CUPS interface to intially add the printer... I do not exactly remember how I did it... but the web interface looked completely new to me and I am rather sure that is not how I initially went about doing it... perhaps I used some GUI frontend for it...
/dev/usb/lp0 does exist on my computer. The dialog is no longer greyed out and the printer is listed as Idle under the CUPS manage printer interface but however if try and print the printer just spits out blank pages after blank pages until I go into the CUPS manage job interface and cancel the job manually.
EDIT: Weird... now the two options under Add Printer HP Printer and HP Scanner are no longer available under Local Printers... I was thinking perhaps if I added it manually with the DeviceURI under that it would work... I tried to do that but I put a space in the name of my printer... CUPS spit out an error saying that spaces in printer names were not allowed... I hit OK and attempted to readd it without the space and now the option for HP Printer is no longer available and additionally there is now a noticable hang / lag when I click Add Printer before the options show up.
795a8134c1