Visit our LabVIEW Wiki LabVIEW Embedded Portal
Tags |
(This content has not been tagged yet)
|
![]() |
May 19 2005, 04:48 PM
Post
#1
|
|||
|
Active Member Posts: 21 Joined: 27-August 04 Member No.: 633 LV:8.0
|
Hello Fellows;
I am having a few problems and I am wondering if anyone has encountered similiar things or knows why... I have a setup with a 7831R FPGA board and 8145 RT board. Basically one portion of the program gets data from the fpga and sends it to the realtime board using interrupts and synchronous variable... On the realtime system, the data is received and put into a realtime fifo for processing elsewhere. I have about 3 types of data packages that are sent from the fpga. One consist of 48 elements, another of 128 and one of 16384. All of then are unsigned 32bits numbers. The first and the last one appear to come through without a problem even at high speed. The moment try sending the package of 128 units of unsigned 32bits numbers, a very high peak noise is introduced into all the other data streams. I have even wired constants to all data streams and the same problem occurs. Slowing down doesn't help. I put in code to check the data just before it's written to the synchronous display and it's error free. I have recreated the fifos and memory blocks on the fpga for no avail... The interesting thing is that if I transmit just one data stream at a time, things work fine. The moment I start alternating, the problem returns. Sending the data using interrupt only for notification, regular display and binary handshaking works fine but it's slow. My suspicions are perhaps I am exceeding the rate at which a synchronous display can be written and read ? Any one knows ??? Walters SpinX Technologies -------------------- Man, know thyself...
|
||
|
|
|||
| Ad |
May 19 2005, 04:48 PM
Post
#
|
||
|
|
|
||
|
|
|||
May 25 2005, 06:50 AM
Post
#2
|
|||
|
4 more posts to go! Member Posts: 6 Joined: 18-February 05 Member No.: 1636 LV:7.1.1
|
The communication rate with interruption probably not exeed 1 Mo / s, it's very slow... What's your data sampling rate ?
This post has been edited by PitchNancy: May 25 2005, 06:51 AM
|
||
|
|
|||
May 25 2005, 10:20 AM
Post
#3
|
|||
|
Active Member Posts: 21 Joined: 27-August 04 Member No.: 633 LV:8.0
|
The whole thing is event driven. For example it the infra laser fires up, the 2 photo multipliers fire up and generate 16834 samples or for each segment that a motor goes through generates timing pulses...
Even slowing down this events to rediculous slow speed didn't make a difference; or putting delays in between transmitting each U32 number via synchronous variable... I am also reading about 2 dozen indicators off the FPGA frontpanel Which suggest that if the problem is bandwidth it must happen just momentarily... The corruption is consistent and always at the same place... My thinking though is that for the 7831R, using a synchronous display must definitely put a constrain on the speed and or bandwidth effectively reducing both or one or the other... Wally QUOTE (PitchNancy @ May 25 2005, 06:50 AM)
-------------------- Man, know thyself...
|
||
|
|
|||
Feb 3 2006, 01:13 PM
Post
#4
|
|||
|
Active Member Posts: 21 Joined: 27-August 04 Member No.: 633 LV:8.0
|
Well,
This problem was solved by breaking the communication routine into two. It became clear that the communication channel whatever the cause could not sustain the data trasfer rate in due in part to the larged number ofront panel objects to be read from the fpga. The sepration allowed the silencing of certain parts when needed. This was an interim solution while waiting for DMA transfer which are here now in LV8.0 Wally The whole thing is event driven. For example it the infra laser fires up, the 2 photo multipliers fire up and generate 16834 samples or for each segment that a motor goes through generates timing pulses...
Even slowing down this events to rediculous slow speed didn't make a difference; or putting delays in between transmitting each U32 number via synchronous variable... I am also reading about 2 dozen indicators off the FPGA frontpanel Which suggest that if the problem is bandwidth it must happen just momentarily... The corruption is consistent and always at the same place... My thinking though is that for the 7831R, using a synchronous display must definitely put a constrain on the speed and or bandwidth effectively reducing both or one or the other... Wally -------------------- Man, know thyself...
|
||
|
|
|||
![]() ![]() |
| Time is now: 8th January 2009 - 09:54 PM |