Activity
From 10/22/2011 to 11/20/2011
11/15/2011
- ML 03:30 PM Software Development: RE: OMAP I2C
- Yes, it works (thanks):
- JP 03:24 PM Software Development: RE: OMAP I2C
- Mark,
I probably should have used O_RDWR instead of O_RDONLY. I am surprised it worked with just O_RDONLY.
The SENDRECV is important, at least for my device. I am reading a device register and the protocol is that I need to send th... - ML 03:17 PM Software Development: RE: OMAP I2C
- Interesting. We were using Qnx's demo which uses DCMD_I2C_RECV rather than DCMD_I2C_SENDRECV so that was part of the solution.
It is also calling open with O_RDWR rather than O_RDONLY - not sure if that is a problem.
Also the call t... - JP 01:27 PM Software Development: RE: OMAP I2C
- I am attaching a test program that was used on a board to read the factory config information using i2c0.
The output of the i2c_get program is:
11/14/2011
- JP 05:13 PM Software Development: RE: OMAP I2C
- Can you try to get the sample program that the qnx engineer used?
Thanks.
- ML 09:47 AM Software Development: RE: OMAP I2C
- An engineer from QNX hooked a scope to I2C0 lines on their EVM board and sent the sendrecv command. They were able to get a signal on the lines, proving that their driver works with the utilities. They said this indicated that the BSP wa...
11/11/2011
- JP 03:04 PM Software Development: RE: OMAP I2C
- IFor what it is worth, it should be noted that the i2c accesses in the startup code and in the i2c_get utility are done without interrupts. The i2c resource manager is probably using interrupts. It is possible that something needs to be ...
11/03/2011
- JP 02:08 PM Software Development: RE: FPGA Driver
- I have posted a new BSP which has a fixed FPGA driver and fix to the timer routines so the clock period can be changed via ClockPeriod().
Please see http://support.criticallink.com/redmine/attachments/download/840/qnxbsp-20111103.zip ...
11/01/2011
- JP 09:12 AM Software Development: RE: OMAP I2C
- Mark,
I2C0 is not something that needs to be turned on. It is used internally in the startup code to read configuration information on the L138 module, so if you are booting into QNX, then i2c0 has been used.
QNX provided i2c drive... - ML 09:00 AM Software Development: RE: OMAP I2C
- It looks like neither I2C driver is started by default.
We are trying to use I2C0
There is an error generated if we include the line:
10/28/2011
- JP 02:44 PM Software Development: RE: FPGA Driver
- Mark,
The files under /dev/fpga are not intended to be executed. They are intended to be opened and then read from or written to. They are created by the fpga-omapl1xx resource manager. As shown in the examples on the wiki page, you c... - ML 02:27 PM Software Development: RE: FPGA Driver
- Tried that - now I'm having a very strange, possibly unrelated problem where the files created under /dev/fpga are created without the executable bit (e.g. 660 rather than 770). Even if I change the permissions they will not execute. N...
10/27/2011
- JP 05:04 PM Software Development: RE: FPGA Driver
- Mark,
These is a mistake in the fpga driver as provided. It is printing out the virtual addresses for the cores in the fpga instead of the physical addresses. The virtual addresses are not real useful. The example in the wiki page shows: - ML 03:35 PM Software Development: RE: FPGA Driver
- Understood. I have a memory block in the FPGA that I was able to examine using mmap_device_memory().
The offset was a reference to the startup script:
@
#######################################################################
##... - JP 03:29 PM Software Development: RE: FPGA Driver
- Mark,
The 5 fpga device files (cmd, image, state, version, and devices) are for loading an image into the fpga and getting information about that loaded image. Think of them as fpga administrative tools.
I think what you are askin... - ML 02:51 PM Software Development: RE: FPGA Driver
- I have the FPGA driver loaded, with the FPGA mapped into 0x66000000.
If I want to access the FPGA for a user application how do I map it in? Just use the h/w address? The FPGA devices seem specific to the 5 commands you've created. Sho...
10/26/2011
- ML 03:57 PM Software Development: RE: Pin MUX
- Just saw a signal out of the port - thanks. It may have been a conflict with the I2C or something else we tried along the way that broke it. Either way this was a big help - thanks.
- JP 03:19 PM Software Development: RE: Pin MUX
- Mark,
I have tried using a scope on an INDIO board (80-000268RI-2 rev. B, serial number 110765) with a module (L138-FG-225-RC, serial #110441) and have the following results.
What I did:
* Started a new workspace
* Imported the... - ML 07:45 AM Software Development: RE: Pin MUX
- We are using RS-232 at TTL levels, so that is not a problem.
We had done all the steps you outlined and we are not seeing output from the pins using an scope.
10/25/2011
- JP 04:32 PM Software Development: RE: Pin MUX
- Mark,
I do not know of any qnx code that has been used with this port. I have been talking with the hardware guys and it seems that this port is an expansion port. This means there needs to be additional hardware added depending on wh...
10/24/2011
- RG 04:26 PM Software Development: RE: ClockPeriod
- John,
The timer_load callout only gets called when you change the system tick period, so it will only be indeterminate (and expected to behave that way) for a single tick. And with either fix you need to reset the timer count otherwi... - JP 03:55 PM Software Development: RE: ClockPeriod
- Rob,
I think the method I described was a way of giving the timer control over the reload so it could be done gracefully.
Your method sounds like it would be fine for a situation where you have some setup changes to do and don't re... - RG 03:44 PM Software Development: RE: ClockPeriod
- Hi John,
I need to do more testing, but it looks like I have a fix. You cannot change the timer's period while it is running, so I modified the timer_load callout to stop the timer first and zero the counter before changing the perio... - ML 03:25 PM Software Development: RE: Pin MUX
- We were able to toggle other GPIO lines that come out the connectors on the back, but unable to see any activity with GP0[8], nor GP1[2] or GP1[3], or in fact any pin on J504.
We are using a scope to look at the pins.
I've tried all th... - JP 11:32 AM Software Development: RE: Pin MUX
- Mark,
I did not understand the details of uart 2 on our kit before. As I understand it now, it is connected as a half-duplex RS-485 interface. If you are expecting to see rs-232 serial port activity, this is not going to work. If you ... - ML 10:55 AM Software Development: RE: Pin MUX
- It may be more of a hardware problem - we have the industrial IO board 80-000268RI-2 serial 110759 and we see no RS-485 signal out of J504 that makes any sence. We've also tried Linux and failed to get output there too.
- ML 10:21 AM Software Development: RE: Pin MUX
- Here is a snapshot of my last attempt (attached)
Devices configured:
EMAC (RMII)
EMIFA/EMIFB
MMC/SD1
UART0,1,2
SPI0 (SCS 0 and 1 only as 2-5 collide with UART 0)
SPI1 (SCS 0 and 1 only as 2-5 collide with UARTS 1&2)
I2C0
The... - JP 09:48 AM Software Development: RE: Pin MUX
- Mark,
Please send you pinmux (both the .pin and the .h files) and startup script files. You can just attach them to a forum message reply using the Files and Add another file links.
The startup script files will need to make sure t... - ML 07:47 AM Software Development: RE: Pin MUX
- We aren't having any luck, John will try to call, and we've sent along the files.