Activity
From 09/25/2011 to 10/24/2011
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.
10/20/2011
- JP 05:22 PM Software Development: RE: ClockPeriod
- The QT_TIMER_LOAD value of 0x30 is just an offset into the system page or some structure. It is not the actual load value.
- JP 05:20 PM Software Development: RE: ClockPeriod
- Rob,
It looks like there is a callout function that does not really do what it is supposed to. I suspect the kernel is expecting the timer to change but nothing is happening at the lower level. The timer_load values you show seem cons... - RG 01:32 PM Software Development: RE: ClockPeriod
- Hi John,
The pidin program does not display the info we're interested in, so I modified my clock_period program to display the timer_load value (not to be confused with the timer_load callout) from the syspage. Here are the results:
... - JP 10:06 AM Software Development: RE: Pin MUX
- You will probably need to modify the omapl138_psc_init() to include a line like:
omapl138_psc_enable (PSC_MODULE_UART2);
Hope this helps.
- We are trying to use the MityDSP L138 UART2 on the PROFIBUS dev kit with Qnx. We are connecting via J504.
I saw mention of removing jumper JP500-502 and installing JP503, but those do not appear to be on our board.
We've updated the c...
10/18/2011
- JP 02:48 PM Software Development: RE: ClockPeriod
- Rob,
With regards to the syspage, I was hoping to see values change after changing the ClockPeriod. Sections relating to time and clocks seemed like good candidates. If the x86 shows changes in one way and the omap shows changes in a ... - RG 02:37 PM Software Development: RE: ClockPeriod
- John,
I just tried the above mentioned change, and as you suspected it did not fix the problem but was worth a try.
Regarding the pidin info, could you let me know what section of the syspage you would like to see. I did capture th... - RG 02:38 PM Software Development: RE: QNX BSP Timers
- John,
We have tried using ClockCycles(). I think it may be working for us but will check with the other developers to make sure.
Thanks,
Rob
10/17/2011
- JP 10:06 AM Software Development: RE: QNX BSP Timers
- Rob,
Have you tried using ClockCycles()?
John - JP 10:02 AM Software Development: RE: ClockPeriod
- Rob,
I see your point.
We have not provided the arm clock handling routines so in that sense, this would seem to be the arm-specific part of QNX. My understanding though, is that the kernel gets things like device specific handling...
10/13/2011
- RG 12:33 PM Software Development: RE: ClockPeriod
- John,
Actually, the point I was trying to make is that changing the system tick using ClockPeriod confuses the OS concept of time, which shouldn't happen. Using the attached program this is what happens:
# ./clock_period
ClockPer... - JP 09:16 AM Software Development: RE: ClockPeriod
- Rob,
I don't have experience trying to change the clock period. The documentation does seem to indicate that making the period very small can result in significant overhead in the system from all the interrupts. (see clock_setres() a... - JP 08:54 AM Software Development: RE: QNX BSP Timers
- Rob,
I don't know of a feature like this. I have always just used the CLOCK_REALTIME.
John
10/11/2011
- Hello,
I am having problems changing the system clock period using the QNX BSP. When I try to change it using the ClockPeriod function, it sets a value that confuses QNX as to the correct time. For example, if I try to change the pe... - Hello,
I have a need for a timer that supports a higher resolution than QNX CLOCK_REALTIME. It will be used for high accuracy timestamps, but probably will not need to drive an interrupt.
Is a feature like this already supported i...