Hi, I am using the C6713. I need to transfer a 2D array to EMIF, the situation
is same as figure A-36 in http://focus.ti.com/lit/ug/spru234c/spru234c.pdf . The
channel is now configurated as initiate by INT5, and I wish it can synchronize
the arrays by INT4.
How to configure the EDMA to synchronize the arrays by an external interrupt
event trigger? Does it same as configurating the event-triggered transfer
request?
Thanks
Array Synchronized EDMA
Started by ●March 19, 2007
Reply by ●March 20, 20072007-03-20
Edwin-
> Hi, I am using the C6713. I need to transfer a 2D array to EMIF, the
> situation is same as figure A-36 in
> http://focus.ti.com/lit/ug/spru234c/spru234c.pdf . The channel is now
> configurated as initiate by INT5, and I wish it can synchronize the
> arrays by INT4.
>
> How to configure the EDMA to synchronize the arrays by an external
> interrupt event trigger? Does it same as configurating the event-
> triggered transfer request?
Are you just asking how to change the synchronization to use INT4 instead of INT5?
Or are you asking:
-how to use both INT4 and INT5 (like an AND condition) to
initiate an overall DMA transfer?
-use INT4 to transfer one dimension of the array, and INT5
to transfer the other dimension?
What you're trying to do is not clear to me.
-Jeff
> Hi, I am using the C6713. I need to transfer a 2D array to EMIF, the
> situation is same as figure A-36 in
> http://focus.ti.com/lit/ug/spru234c/spru234c.pdf . The channel is now
> configurated as initiate by INT5, and I wish it can synchronize the
> arrays by INT4.
>
> How to configure the EDMA to synchronize the arrays by an external
> interrupt event trigger? Does it same as configurating the event-
> triggered transfer request?
Are you just asking how to change the synchronization to use INT4 instead of INT5?
Or are you asking:
-how to use both INT4 and INT5 (like an AND condition) to
initiate an overall DMA transfer?
-use INT4 to transfer one dimension of the array, and INT5
to transfer the other dimension?
What you're trying to do is not clear to me.
-Jeff
Reply by ●March 20, 20072007-03-20
Sorry for confusing you. Actually my application is to send the RGB data signal
to television through EMIF. The horizontal sync (HSYNC) and vertical sync
(VSYNC) pulse are connected to the INT4 and INT5 respectively.
Therefore, when the VSYNC arrived, the EDMA channel should be initiated. And each array should be sent out when the HSYNC arrived.
In the other words, when the first HSYNC arrived, the channel should transmit array[0], second HSYNC arrived, transmit array[1], third HSYNC arrived, transmit array[2] ... When VSYNC arrived again, the transmission should start over and transmit array[0], array[1], array[2] ......
Thanks
Edwin-
>
>> Hi, I am using the C6713. I need to transfer a 2D array to EMIF, the
>> situation is same as figure A-36 in
>> http://focus.ti.com/lit/ug/spru234c/spru234c.pdf . The channel is now
>> configurated as initiate by INT5, and I wish it can synchronize the
>> arrays by INT4.
>>
>> How to configure the EDMA to synchronize the arrays by an external
>> interrupt event trigger? Does it same as configurating the event-
>> triggered transfer request?
>
>Are you just asking how to change the synchronization to use INT4 instead of INT5?
>Or are you asking:
>
> -how to use both INT4 and INT5 (like an AND condition) to
> initiate an overall DMA transfer?
>
> -use INT4 to transfer one dimension of the array, and INT5
> to transfer the other dimension?
>
>What you're trying to do is not clear to me.
>
>-Jeff
Therefore, when the VSYNC arrived, the EDMA channel should be initiated. And each array should be sent out when the HSYNC arrived.
In the other words, when the first HSYNC arrived, the channel should transmit array[0], second HSYNC arrived, transmit array[1], third HSYNC arrived, transmit array[2] ... When VSYNC arrived again, the transmission should start over and transmit array[0], array[1], array[2] ......
Thanks
Edwin-
>
>> Hi, I am using the C6713. I need to transfer a 2D array to EMIF, the
>> situation is same as figure A-36 in
>> http://focus.ti.com/lit/ug/spru234c/spru234c.pdf . The channel is now
>> configurated as initiate by INT5, and I wish it can synchronize the
>> arrays by INT4.
>>
>> How to configure the EDMA to synchronize the arrays by an external
>> interrupt event trigger? Does it same as configurating the event-
>> triggered transfer request?
>
>Are you just asking how to change the synchronization to use INT4 instead of INT5?
>Or are you asking:
>
> -how to use both INT4 and INT5 (like an AND condition) to
> initiate an overall DMA transfer?
>
> -use INT4 to transfer one dimension of the array, and INT5
> to transfer the other dimension?
>
>What you're trying to do is not clear to me.
>
>-Jeff
Reply by ●March 20, 20072007-03-20
Edwin-
> Sorry for confusing you. Actually my application is to send the RGB data
> signal to television through EMIF. The horizontal sync (HSYNC) and vertical
> sync (VSYNC) pulse are connected to the INT4 and INT5 respectively.
>
> Therefore, when the VSYNC arrived, the EDMA channel should be initiated.
> And each array should be sent out when the HSYNC arrived.
>
> In the other words, when the first HSYNC arrived, the channel should transmit
> array[0], second HSYNC arrived, transmit array[1], third HSYNC arrived,
> transmit array[2] ... When VSYNC arrived again, the transmission should
> start over and transmit array[0], array[1], array[2] ......
In this case you can use VSYNC interrupt to set a "Vsync_occurred" flag, and HSYNC
interrupt to make a DAT_xxx call, and either a) if the flag is zero, increment the
row counter, or b) if the flag is 1, reset the flag and reset the row counter to
zero.
What is the RGB interface to EMIF? Just plain memory? A FIFO?
-Jeff
> Edwin-
> >
> >> Hi, I am using the C6713. I need to transfer a 2D array to EMIF, the
> >> situation is same as figure A-36 in
> >> http://focus.ti.com/lit/ug/spru234c/spru234c.pdf . The channel is now
> >> configurated as initiate by INT5, and I wish it can synchronize the
> >> arrays by INT4.
> >>
> >> How to configure the EDMA to synchronize the arrays by an external
> >> interrupt event trigger? Does it same as configurating the event-
> >> triggered transfer request?
> >
> >Are you just asking how to change the synchronization to use INT4 instead of INT5?
> >Or are you asking:
> >
> > -how to use both INT4 and INT5 (like an AND condition) to
> > initiate an overall DMA transfer?
> >
> > -use INT4 to transfer one dimension of the array, and INT5
> > to transfer the other dimension?
> >
> >What you're trying to do is not clear to me.
> >
> >-Jeff
> >
>
> Sorry for confusing you. Actually my application is to send the RGB data
> signal to television through EMIF. The horizontal sync (HSYNC) and vertical
> sync (VSYNC) pulse are connected to the INT4 and INT5 respectively.
>
> Therefore, when the VSYNC arrived, the EDMA channel should be initiated.
> And each array should be sent out when the HSYNC arrived.
>
> In the other words, when the first HSYNC arrived, the channel should transmit
> array[0], second HSYNC arrived, transmit array[1], third HSYNC arrived,
> transmit array[2] ... When VSYNC arrived again, the transmission should
> start over and transmit array[0], array[1], array[2] ......
In this case you can use VSYNC interrupt to set a "Vsync_occurred" flag, and HSYNC
interrupt to make a DAT_xxx call, and either a) if the flag is zero, increment the
row counter, or b) if the flag is 1, reset the flag and reset the row counter to
zero.
What is the RGB interface to EMIF? Just plain memory? A FIFO?
-Jeff
> Edwin-
> >
> >> Hi, I am using the C6713. I need to transfer a 2D array to EMIF, the
> >> situation is same as figure A-36 in
> >> http://focus.ti.com/lit/ug/spru234c/spru234c.pdf . The channel is now
> >> configurated as initiate by INT5, and I wish it can synchronize the
> >> arrays by INT4.
> >>
> >> How to configure the EDMA to synchronize the arrays by an external
> >> interrupt event trigger? Does it same as configurating the event-
> >> triggered transfer request?
> >
> >Are you just asking how to change the synchronization to use INT4 instead of INT5?
> >Or are you asking:
> >
> > -how to use both INT4 and INT5 (like an AND condition) to
> > initiate an overall DMA transfer?
> >
> > -use INT4 to transfer one dimension of the array, and INT5
> > to transfer the other dimension?
> >
> >What you're trying to do is not clear to me.
> >
> >-Jeff
> >
>
Reply by ●March 21, 20072007-03-21
Do you mean I cannot configure the EDMA channel as "event-triggered
synchronization"? Is it no register to handle the hardware event triggered
synchronization?
May be I have got confused in the EDMA Reference Guide, some points in the guide I really do not understand. The interrupt events seem can be used to trigger both the "Transfer Request" and "Synchronization", does both of them are enabled in the "Event Enable Register"? Then how can the EDMA controller knows the interrupt is for "Transfer Request" or "Syncrhonization" purpose?
The RGB data is 24-bit wide, and connected to a D/A converter. This part is work, I have successfully display a 1 dimension picture to the screen(every line are same). In the 1D case, I just give the address of the 1D-array to the channel, and enable the event4 in the "Event Enable Register". The HSYNC trigger the transfer, therefore the screen displays the same array every times the HSYNC arrived.
Thanks
Edwin
>In this case you can use VSYNC interrupt to set a "Vsync_occurred" flag, and HSYNC
>interrupt to make a DAT_xxx call, and either a) if the flag is zero, increment the
>row counter, or b) if the flag is 1, reset the flag and reset the row counter to
>zero.
>
>What is the RGB interface to EMIF? Just plain memory? A FIFO?
>
>-Jeff
>
May be I have got confused in the EDMA Reference Guide, some points in the guide I really do not understand. The interrupt events seem can be used to trigger both the "Transfer Request" and "Synchronization", does both of them are enabled in the "Event Enable Register"? Then how can the EDMA controller knows the interrupt is for "Transfer Request" or "Syncrhonization" purpose?
The RGB data is 24-bit wide, and connected to a D/A converter. This part is work, I have successfully display a 1 dimension picture to the screen(every line are same). In the 1D case, I just give the address of the 1D-array to the channel, and enable the event4 in the "Event Enable Register". The HSYNC trigger the transfer, therefore the screen displays the same array every times the HSYNC arrived.
Thanks
Edwin
>In this case you can use VSYNC interrupt to set a "Vsync_occurred" flag, and HSYNC
>interrupt to make a DAT_xxx call, and either a) if the flag is zero, increment the
>row counter, or b) if the flag is 1, reset the flag and reset the row counter to
>zero.
>
>What is the RGB interface to EMIF? Just plain memory? A FIFO?
>
>-Jeff
>
Reply by ●March 21, 20072007-03-21
Edwin-
> Do you mean I cannot configure the EDMA channel as "event-triggered synchronization"? Is it no register to handle the
> hardware event triggered synchronization?
"Synchronization" means the external event will cause *each* EDMA word transfer. You don't want that for VSYNC and
HSYNC events.
> May be I have got confused in the EDMA Reference Guide, some points in the guide I really do not understand. The
> interrupt events seem can be used to trigger both the "Transfer Request" and "Synchronization", does both of them are
> enabled in the "Event Enable Register"? Then how can the EDMA controller knows the interrupt is for "Transfer
> Request" or "Syncrhonization" purpose?
Why don't you try what I suggested? Starting EDMA for each row DMA "manually" using a DAT_xxx call in ISR code is a
reliable way to debug it and get both HSYNC and VSYNC working. Then you can try to add external event trigger for
HSYNC. But since you need to incorporate VSYNC in some way, making it "fully automatic" is not as easy at it seems,
as you have discovered.
> The RGB data is 24-bit wide, and connected to a D/A converter. This part is work, I have successfully display a 1
> dimension picture to the screen(every line are same). In the 1D case, I just give the address of the 1D-array to the
> channel, and enable the event4 in the "Event Enable Register". The HSYNC trigger the transfer, therefore the screen
> displays the same array every times the HSYNC arrived.
Does your test pattern show a different value for every pixel? What controls the rate that you write to the D/A
converter? How does EDMA know the converter is ready for more data? If you have not verified each pixel yet, then I
think you may have another timing issue that you've not uncovered yet.
-Jeff
>>In this case you can use VSYNC interrupt to set a "Vsync_occurred" flag, and HSYNC
>>interrupt to make a DAT_xxx call, and either a) if the flag is zero, increment the
>>row counter, or b) if the flag is 1, reset the flag and reset the row counter to
>>zero.
>>
>>What is the RGB interface to EMIF? Just plain memory? A FIFO?
>>
>>-Jeff
> Do you mean I cannot configure the EDMA channel as "event-triggered synchronization"? Is it no register to handle the
> hardware event triggered synchronization?
"Synchronization" means the external event will cause *each* EDMA word transfer. You don't want that for VSYNC and
HSYNC events.
> May be I have got confused in the EDMA Reference Guide, some points in the guide I really do not understand. The
> interrupt events seem can be used to trigger both the "Transfer Request" and "Synchronization", does both of them are
> enabled in the "Event Enable Register"? Then how can the EDMA controller knows the interrupt is for "Transfer
> Request" or "Syncrhonization" purpose?
Why don't you try what I suggested? Starting EDMA for each row DMA "manually" using a DAT_xxx call in ISR code is a
reliable way to debug it and get both HSYNC and VSYNC working. Then you can try to add external event trigger for
HSYNC. But since you need to incorporate VSYNC in some way, making it "fully automatic" is not as easy at it seems,
as you have discovered.
> The RGB data is 24-bit wide, and connected to a D/A converter. This part is work, I have successfully display a 1
> dimension picture to the screen(every line are same). In the 1D case, I just give the address of the 1D-array to the
> channel, and enable the event4 in the "Event Enable Register". The HSYNC trigger the transfer, therefore the screen
> displays the same array every times the HSYNC arrived.
Does your test pattern show a different value for every pixel? What controls the rate that you write to the D/A
converter? How does EDMA know the converter is ready for more data? If you have not verified each pixel yet, then I
think you may have another timing issue that you've not uncovered yet.
-Jeff
>>In this case you can use VSYNC interrupt to set a "Vsync_occurred" flag, and HSYNC
>>interrupt to make a DAT_xxx call, and either a) if the flag is zero, increment the
>>row counter, or b) if the flag is 1, reset the flag and reset the row counter to
>>zero.
>>
>>What is the RGB interface to EMIF? Just plain memory? A FIFO?
>>
>>-Jeff
Reply by ●March 21, 20072007-03-21
> "Synchronization" means the external event will cause
*each* EDMA word
> transfer. You don't want that for VSYNC and
> HSYNC events.
It's really different from what I thought! I thought it can transfer the whole 1D array when one external event occured!
> Why don't you try what I suggested? Starting EDMA for each row DMA
> "manually" using a DAT_xxx call in ISR code is a
> reliable way to debug it and get both HSYNC and VSYNC working. Then you can
> try to add external event trigger for
> HSYNC. But since you need to incorporate VSYNC in some way, making it "fully
> automatic" is not as easy at it seems,
> as you have discovered.
I know nothing about DAT module, therefore I don't really get your meaning, and I afraid there is not much time left for me to finish the project. But now I get some idea, you mean it is better to handle the "transfer request" and "synchronization" by my own ISR. I will try this in these days.
> Does your test pattern show a different value for every pixel? What controls
> the rate that you write to the D/A
> converter? How does EDMA know the converter is ready for more data? If you
> have not verified each pixel yet, then I
> think you may have another timing issue that you've not uncovered yet.
Yes, I tested it with some vertical colour bars and different colour pattern. The D/A converter is very high speed and support up to 240MHz while I only write at about 6MHz, therefore the hardware part should be ok.
> transfer. You don't want that for VSYNC and
> HSYNC events.
It's really different from what I thought! I thought it can transfer the whole 1D array when one external event occured!
> Why don't you try what I suggested? Starting EDMA for each row DMA
> "manually" using a DAT_xxx call in ISR code is a
> reliable way to debug it and get both HSYNC and VSYNC working. Then you can
> try to add external event trigger for
> HSYNC. But since you need to incorporate VSYNC in some way, making it "fully
> automatic" is not as easy at it seems,
> as you have discovered.
I know nothing about DAT module, therefore I don't really get your meaning, and I afraid there is not much time left for me to finish the project. But now I get some idea, you mean it is better to handle the "transfer request" and "synchronization" by my own ISR. I will try this in these days.
> Does your test pattern show a different value for every pixel? What controls
> the rate that you write to the D/A
> converter? How does EDMA know the converter is ready for more data? If you
> have not verified each pixel yet, then I
> think you may have another timing issue that you've not uncovered yet.
Yes, I tested it with some vertical colour bars and different colour pattern. The D/A converter is very high speed and support up to 240MHz while I only write at about 6MHz, therefore the hardware part should be ok.
Reply by ●March 21, 20072007-03-21
Edwin-
> > "Synchronization" means the external event will cause *each* EDMA word
> > transfer. You don't want that for VSYNC and
> > HSYNC events.
>
> It's really different from what I thought! I thought it can transfer the
> whole 1D array when one external event occured!
You can transfer the whole array -- this is "Transfer Request", as you mentioned.
But you said "synchronization", which is a different option (Event Triggered
Synchronization), and not what you want.
> > Why don't you try what I suggested? Starting EDMA for each row DMA
> > "manually" using a DAT_xxx call in ISR code is a
> > reliable way to debug it and get both HSYNC and VSYNC working. Then you can
> > try to add external event trigger for
> > HSYNC. But since you need to incorporate VSYNC in some way, making it "fully
> > automatic" is not as easy at it seems,
> > as you have discovered.
>
> I know nothing about DAT module, therefore I don't really get your
> meaning, and I afraid there is not much time left for me to finish
> the project. But now I get some idea, you mean it is better to handle
> the "transfer request" and "synchronization" by my own ISR. I will try this
> in these days.
Ok that sounds good. It should be easier, and you will have control over each step.
> > Does your test pattern show a different value for every pixel? What controls
> > the rate that you write to the D/A
> > converter? How does EDMA know the converter is ready for more data? If you
> > have not verified each pixel yet, then I
> > think you may have another timing issue that you've not uncovered yet.
>
> Yes, I tested it with some vertical colour bars and different colour pattern.
> The D/A converter is very high speed and support up to 240MHz while I only
> write at about 6MHz, therefore the hardware part should be ok.
Ok, it does sounds like the row timing is correct (although I'm not clear what is
controlling the word rate for each row).
-Jeff
> > "Synchronization" means the external event will cause *each* EDMA word
> > transfer. You don't want that for VSYNC and
> > HSYNC events.
>
> It's really different from what I thought! I thought it can transfer the
> whole 1D array when one external event occured!
You can transfer the whole array -- this is "Transfer Request", as you mentioned.
But you said "synchronization", which is a different option (Event Triggered
Synchronization), and not what you want.
> > Why don't you try what I suggested? Starting EDMA for each row DMA
> > "manually" using a DAT_xxx call in ISR code is a
> > reliable way to debug it and get both HSYNC and VSYNC working. Then you can
> > try to add external event trigger for
> > HSYNC. But since you need to incorporate VSYNC in some way, making it "fully
> > automatic" is not as easy at it seems,
> > as you have discovered.
>
> I know nothing about DAT module, therefore I don't really get your
> meaning, and I afraid there is not much time left for me to finish
> the project. But now I get some idea, you mean it is better to handle
> the "transfer request" and "synchronization" by my own ISR. I will try this
> in these days.
Ok that sounds good. It should be easier, and you will have control over each step.
> > Does your test pattern show a different value for every pixel? What controls
> > the rate that you write to the D/A
> > converter? How does EDMA know the converter is ready for more data? If you
> > have not verified each pixel yet, then I
> > think you may have another timing issue that you've not uncovered yet.
>
> Yes, I tested it with some vertical colour bars and different colour pattern.
> The D/A converter is very high speed and support up to 240MHz while I only
> write at about 6MHz, therefore the hardware part should be ok.
Ok, it does sounds like the row timing is correct (although I'm not clear what is
controlling the word rate for each row).
-Jeff
Reply by ●March 23, 20072007-03-23
I did the following thing in the HSYNC ISR:
if (Y {
Uint32 id;
DAT_open(DAT_CHAANY, DAT_PRI_HIGH, 0);
id = DAT_copy((void *)&src[Y][0],(void *)0xA0000000,4*no_of_pixel);
DAT_wait(id);
DAT_close();
}
Y++;
This method really can the thing I want, the colour pattern can be displayed, and no need to configure any EDMA channel at all, very simple!
However, since the transfer request is still depended on the CPU (interrupt->ISR->DAT->EDMA), two problems are introduced. (1) The CPU wastes resource at DAT_wait() and cause the CPU utilization increased to 75%. (2) Sometimes the CPU seems cannot handles the ISR in same speed (not sure), some lines are shifted to the right (delayed?).
The second problem I had seen before, at that time I configured the EDMA and made the transfer request by CPU (set ESR) in HSYNC ISR, and every times the channel transmitted the same array. This problem was eliminated after changed to "event triggered transfer request" instead of "CPU triggered".
That's why I really need the transfer be fully automated! Is it really cannot configure the channel transfer one array in the 2D array when a event is triggered? If so, I may need to think another way...
if (Y {
Uint32 id;
DAT_open(DAT_CHAANY, DAT_PRI_HIGH, 0);
id = DAT_copy((void *)&src[Y][0],(void *)0xA0000000,4*no_of_pixel);
DAT_wait(id);
DAT_close();
}
Y++;
This method really can the thing I want, the colour pattern can be displayed, and no need to configure any EDMA channel at all, very simple!
However, since the transfer request is still depended on the CPU (interrupt->ISR->DAT->EDMA), two problems are introduced. (1) The CPU wastes resource at DAT_wait() and cause the CPU utilization increased to 75%. (2) Sometimes the CPU seems cannot handles the ISR in same speed (not sure), some lines are shifted to the right (delayed?).
The second problem I had seen before, at that time I configured the EDMA and made the transfer request by CPU (set ESR) in HSYNC ISR, and every times the channel transmitted the same array. This problem was eliminated after changed to "event triggered transfer request" instead of "CPU triggered".
That's why I really need the transfer be fully automated! Is it really cannot configure the channel transfer one array in the 2D array when a event is triggered? If so, I may need to think another way...
Reply by ●March 23, 20072007-03-23
Why can't you use a frame (or block) synchronized ?
See
Appendix A
I may be missing something completely !
- Andrew E.
n...@yahoo.com.hk wrote:
>I did the following thing in the HSYNC ISR:
>
>if (Y >{
> Uint32 id;
> DAT_open(DAT_CHAANY, DAT_PRI_HIGH, 0);
> id = DAT_copy((void *)&src[Y][0],(void *)0xA0000000,4*no_of_pixel);
> DAT_wait(id);
> DAT_close();
>}
>Y++;
>
>This method really can the thing I want, the colour pattern can be displayed, and no need to configure any EDMA channel at all, very simple!
>
>However, since the transfer request is still depended on the CPU (interrupt->ISR->DAT->EDMA), two problems are introduced. (1) The CPU wastes resource at DAT_wait() and cause the CPU utilization increased to 75%. (2) Sometimes the CPU seems cannot handles the ISR in same speed (not sure), some lines are shifted to the right (delayed?).
>
>The second problem I had seen before, at that time I configured the EDMA and made the transfer request by CPU (set ESR) in HSYNC ISR, and every times the channel transmitted the same array. This problem was eliminated after changed to "event triggered transfer request" instead of "CPU triggered".
>
>That's why I really need the transfer be fully automated! Is it really cannot configure the channel transfer one array in the 2D array when a event is triggered? If so, I may need to think another way...
>
>
>
See
Appendix A
I may be missing something completely !
- Andrew E.
n...@yahoo.com.hk wrote:
>I did the following thing in the HSYNC ISR:
>
>if (Y >{
> Uint32 id;
> DAT_open(DAT_CHAANY, DAT_PRI_HIGH, 0);
> id = DAT_copy((void *)&src[Y][0],(void *)0xA0000000,4*no_of_pixel);
> DAT_wait(id);
> DAT_close();
>}
>Y++;
>
>This method really can the thing I want, the colour pattern can be displayed, and no need to configure any EDMA channel at all, very simple!
>
>However, since the transfer request is still depended on the CPU (interrupt->ISR->DAT->EDMA), two problems are introduced. (1) The CPU wastes resource at DAT_wait() and cause the CPU utilization increased to 75%. (2) Sometimes the CPU seems cannot handles the ISR in same speed (not sure), some lines are shifted to the right (delayed?).
>
>The second problem I had seen before, at that time I configured the EDMA and made the transfer request by CPU (set ESR) in HSYNC ISR, and every times the channel transmitted the same array. This problem was eliminated after changed to "event triggered transfer request" instead of "CPU triggered".
>
>That's why I really need the transfer be fully automated! Is it really cannot configure the channel transfer one array in the 2D array when a event is triggered? If so, I may need to think another way...
>
>
>
