From: List <li...@sw...> - 2008-05-19 18:48:49
|
Dear list, the silabs C8051F060 incorporated a DMA controller. While the DMA controller is running, a special procedure must be followed to access the xram (wait DMA0XBY ==0, set DMA0HLT, access xram, clr DMA0HLT bit). I wonder how much work it would be to teach this feature to SDCC? best regards Dani |
From: Maarten B. <sou...@ds...> - 2008-05-20 07:16:13
|
Dani, This totally depends on what you would want the compiler to do. Should this appear around every MOVX instruction or also around several when dealing with multibyte variables? Or even around iCodes (elementary instructions for the compiler)? Or bigger yet? In case the first is good enough this can easily be solved with a peephole rule: replace { movx %1,%2 } by { jb _DMA0XBY,. setb _DMA0HLT movx %1,%2 clr _DMA0HLT } If necessary you can also insert code to select the proper SFR page and return it to previous setting afterwards. Greets, Maarten > Dear list, > > the silabs C8051F060 incorporated a DMA controller. While the DMA > controller is running, a special procedure must be followed to access > the xram (wait DMA0XBY ==0, set DMA0HLT, access xram, clr DMA0HLT bit). > I wonder how much work it would be to teach this feature to SDCC? > > best regards > > Dani |
From: List <li...@sw...> - 2008-05-22 17:10:45
|
Hi Maarten, I'm not sure yet what I want :-) The problem is that during the dma the on-chip xram does not need any special threatment, while the off-chip xram does. I think multibyte variables must be supported. For performance reasons, it might be better to cluster movx instructions (like __critical {}). But this might lead to problems, when the dma engine might not be able to write its data to the xram and overflow. best regards Dani Maarten Brock wrote: > Dani, > > This totally depends on what you would want the compiler > to do. Should this appear around every MOVX instruction > or also around several when dealing with multibyte > variables? Or even around iCodes (elementary > instructions for the compiler)? Or bigger yet? > > In case the first is good enough this can easily be > solved with a peephole rule: > > replace { > movx %1,%2 > } by { > jb _DMA0XBY,. > setb _DMA0HLT > movx %1,%2 > clr _DMA0HLT > } > > If necessary you can also insert code to select the > proper SFR page and return it to previous setting > afterwards. > > Greets, > Maarten > > >> Dear list, >> >> the silabs C8051F060 incorporated a DMA controller. While the DMA >> controller is running, a special procedure must be followed to access >> the xram (wait DMA0XBY ==0, set DMA0HLT, access xram, clr DMA0HLT bit). >> I wonder how much work it would be to teach this feature to SDCC? >> >> best regards >> >> Dani >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Frieder F. <fri...@we...> - 2008-05-22 18:34:55
|
Hi Dani, List schrieb: > I'm not sure yet what I want :-) :) > The problem is that during the dma the on-chip xram does not need any > special threatment, while the off-chip xram does. Would it be correct to say: if you limit DMA to on-chip xram then according to section 6.3 of: http://www.silabs.com/public/documents/tpub_doc/dsheet/Microcontrollers/Precision_Mixed-Signal/en/C8051F06x.pdf no modification would be needed at all? Does your application allow for that? I guess section 6.3 probably fails to mention that no IRQ is supposed to occur between checking DMA0XBY and setting _DMA0HLT ? Greetings, Frieder |
From: List <li...@sw...> - 2008-05-23 06:11:20
|
The problem is that I "believe" to see sporadic errors with the DMA engine accessing on-chip xram. Sometimes the movx a,@dptr does not load the acc register. Silabs can't confirm such a bug, so I have to modify my rather complex firmware to nail the problem down. I'm still hoping that I'm an idiot and made a big programming mistake ;-) If section 6.3 would not be true regarding on-chip xram access, we would always need to stop the dma engine for xram access. If it is true, we only need to do this on off-chip xram. Interrupts of course give the problem an additional dimension with the options: switch off irq during DMA0XBY check switch off irq during xram access getting accessing over the dma controller is not atomic, however it might be possible to check the timer that triggers the adc cycle if we keep the dma engine switched off for multiple movx instructions and check the DMA0DOE, in such a case we would also need to switch off irq otherwise it is not garanteed to switch dma engine on within a given time to prevent data lost. alternatively we could rise the dma engine above all other irqs (which would not be an option for my firmware, as the dma engine irq must have a very low priority) best regards Dani |
From: List <li...@sw...> - 2008-05-27 18:52:55
|
Dear List, is there anybody who can please provide me an example using both ADC0 and 1 on the C8051F06x accessing on-chip XRAM? I think there is really a problem with my DMA controller setting. Sometime the MOVX A,@DPTR instruction is not correctly executed which leads to wrong ACC content after the instruction. I know the example from the Silabs IDE,but that uses the off-chip xram. best regards Dani |
From: Maarten B. <sou...@ds...> - 2008-05-27 22:10:27
|
Dani, I would be willing to help you, yet I do not have access to an F06x. What are you using yourself? A SiLabs C8051F060DK demokit or the smaller C8051F064EK evaluation kit or a design of your own? And how are you clocking it? Maarten > Dear List, > > is there anybody who can please provide me an example using both ADC0 > and 1 on the C8051F06x accessing on-chip XRAM? I think there is really a > problem with my DMA controller setting. Sometime the MOVX A,@DPTR > instruction is not correctly executed which leads to wrong ACC content > after the instruction. I know the example from the Silabs IDE,but that > uses the off-chip xram. > > best regards > > Dani > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: List <li...@sw...> - 2008-05-28 04:52:54
|
Great, thanks, I'm usind the C8051F060DK and a design of my own. Both of them have the problem. System clock is 11.0592MHz with an external clock. or double (DK) with internal clock divider by 2 activated. Dani Maarten Brock wrote: > Dani, > > I would be willing to help you, yet I do not have access > to an F06x. What are you using yourself? A SiLabs > C8051F060DK demokit or the smaller C8051F064EK > evaluation kit or a design of your own? And how are you > clocking it? > > Maarten > > > >> Dear List, >> >> is there anybody who can please provide me an example using both ADC0 >> and 1 on the C8051F06x accessing on-chip XRAM? I think there is really a >> problem with my DMA controller setting. Sometime the MOVX A,@DPTR >> instruction is not correctly executed which leads to wrong ACC content >> after the instruction. I know the example from the Silabs IDE,but that >> uses the off-chip xram. >> >> best regards >> >> Dani >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Sdcc-user mailing list >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user >> >> > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: List <li...@sw...> - 2008-06-26 15:51:42
|
dear all, anybody using a silabs C8051F060 with sdcc in dma mode should be aware that the following assembler sequence may lead to unpredictable results as the second movx a,@dptr may not be executed properly if the execution is parallel to the dma write cycle to the on-chip xram. movx a,@dptr inc dptr movx a,@dptr silabs was not able to confirm this problem to me, but the following patch worked fine for me (thanks to Maarten Brock), which inserts a nop before or after the inc dptr. use the compile option "--peep-file peepfile" and create a peep file with the following directives: replace { movx a,@dptr,a inc dptr movx a,@dptr,a } by { movx a,@dptr,a nop inc dptr movx a,@dptr,a } best regards Dani |
From: Maarten B. <sou...@ds...> - 2008-05-22 20:15:26
|
My guess is that Dani needs off-chip xdata access too, otherwise he would not ask for it. But if he doesn't know what he wants, I don't see how we could help much. And even without interrupts I don't see how checking DMA0XBY and then setting DMA0HLT is an atomic action where the DMA engine cannot get in between. IMO they should have made use of the JBC instruction to capture a combination of these two flags. Finally leaving interrupts on could be a good thing. If you enable the DMA overflow warning interrupt, you could (if fast enough) enable the DMA engine until the warning disappears and then halt it again and return from interrupt. Maarten > Hi Dani, > > List schrieb: > > I'm not sure yet what I want :-) > > :) > > > The problem is that during the dma the on-chip xram does not need any > > special threatment, while the off-chip xram does. > > Would it be correct to say: if you limit DMA to on-chip xram > then according to section 6.3 of: > http://www.silabs.com/public/documents/tpub_doc/dsheet/Microcontrollers/Precision_Mixed-Signal/en/C8051F06x.pdf > no modification would be needed at all? > Does your application allow for that? > > > I guess section 6.3 probably fails to mention that no IRQ > is supposed to occur between checking DMA0XBY and setting _DMA0HLT ? > > Greetings, > Frieder |