• Replies 17 replies
  • Subscribers 888 subscribers
  • Views 14766 views
  • Users 0 members are here
Options
Related

adc periodic framework using both adc0, and 1, and their timing between them

rupertm

Dear Forum,

 

I have a few questions about the configuration and use the of the periodic framework for the adc.  I am needing to setup and run both adc's at the same time.  From the looks of it and from a few trials it seems like you can only setup one framework for a specific adc.  What Im hoping to do is to be able to have some adc start signal start both adc at the same time.  Is there a way to do this?  Can this also be done with the sample and hold circuitry enabled?  Basically Im needing to capture 6 channels all at the same time. 

Second question is with the configuration, of the "length of data-buffer" in the properties of the periodic framework.  I have 4 channels Im sampling, and have 100 sampling iterations, that will produce 400 sample registers that will be filled.  But when I set that up and run  I get the BSP_CFG_HANDLE_UNRECOVERABLE_ERROR (0); withing the void g_sf_adc_periodic0_err_callback_internal(void * p_instance, void * p_data).  Since I have this setup as 12 bit samples, Im guessing these are all stored as 16bit unsigned ints.  Not 32 bit.  So then is the "length of data-buffer" a size defined as 8 bits or is it actually 16 bit for data space.  It acts like its 8 bit, cause if I increase the size in the above example from 400 to 800 it works just fine.  Or is it that you cant have "length of data-buffer" equal to the exact number of storage locations required.    

Third thing I noticed as I was testing out the adc's was cross talk.  I saw at most 20 bits of cross talk.  My test setup was simply 8 pots, connected between 3.3v and ground on a SK board plugged into the j20 connector.  The wipers of the pots were fed back into ADC000-003, and ADC100-103.  Basically the first 4 channels of each adc.  Im thinking this must be simply a setup or some kind of code issue.  But the cross talk should in no way be this bad right?  I could find no reference to cross talk in the user manual ver 1.2 from aug 2016.  Is it maybe called something different? 

Thank You
Matt

Parents
  • Hi Matt!
    For the first question - I'm affraid that SSP doesn't support multiple ADC units under single framework. The workaround would de overriding the ADC Preiodic Framework function APIs to adjust them to your needs or develop your own ADC periodic scan driver.

    2nd question - The init function returns SSP_ERR_INSUFFICIENT_SPACE if number_adc_of_channels_used * sample_count * 2 > length_of_data_buffer

    3rd question - Just to clarify... What do you mean by "20 bits of cross talk"? You mean that one channel affects other so the reading changes by 20, right?

    KR, Jakub
  • in reply to JakubJasik

    Thank you Jakub!

    For multiple adc units, could I just add another framework?  Or in my case needing to fire all the adcs at the same time would it simply be better to go in and do my own framework code?

    Ah that was what I was kind of thinking but had not seen a formula for the length_of_data_buffer.  So the *2 is what I was missing.  

    Yes Im seeing upto 20 counts of cross talk from the input on one adc to the input on another.  Basically when I have one adc own to zero volts on the input and I set the one next to it, or even a few over Im seeing at least 20 counts.  I think yesterday afternoon I was seeing even a few more then that.  I sure hope this is not a hardware issue and maybe has more to do with how the framework code is switching the muxing internally.  Im guessing there is a settling time on the muxes that is not being met by the current framework code.  Im sure thinking this has to be a software setup/usage thing in the framework code somewhere.  I cant imagine that something like this got missed by the factory guys.  Its just way to many counts.     

     

    Attached is what the daughter board looks like that I attached to the SK board for simple testing out of the adc's.  I just drew on the SK schematic how the pots hookup.  Power and ground Im using from the connector. 

    Thanks again Jakub!

    Matt

  • in reply to rupertm

    Hi Jakub,

    What is also interesting in the setup for length_of_data_buffer, when I do that and set the memory space to 2x it looks like the upper half of that memory is not being filled with the callback.  Each time the call back runs, only the lower portion of the memory is updated.  See below.

    Thanks

    Matt

  • in reply to rupertm

    Oh that second image somehow over wrote the first.  He is the correct first image.

  • in reply to rupertm
    Hi Jakub and forum,

    Ok, After more experimentation I can say Im constantly seeing cross talk. I have only tested in combinations of the the first 4 and 7 channel combinations. 0-3, 0-6 on a s7g2-sk board using adc unit 0. I only have pots wired to Ch0-3 as shown in the schematic above. All other input are as they are wired on the board. I test by applying 3.3 volts to each adc input through the pot, one by one leaving the other inputs at ground. Now one thing I have not tried would be disconnecting and replacing the power that is on the connector J20 (+3V3) and switching over to the analog power(+3V3ANA) from the board. Looks to be available on the Arduino shield connector j24.8 after R115 is populated with a zero ohm resistor. Ill try this tomorrow. But when running on the main power the results are below.

    When looking at Ch0-3
    Ch0 reading 4095 puts 22 counts on Ch1
    Ch1 reading 4095 puts 22 counts on Ch2
    Ch2 reading 4095 does not seem to effect its neighbors.
    Ch3 reading 4095 puts 22 counts on Ch0
    When not in use the above channels were pulled to ground and not left floating.

    When looking at Ch0-6
    Ch0 reading 4095 puts 22 counts on Ch1
    Ch1 reading 4095 puts 22 counts on Ch2
    Ch2 reading 4095 does not seem to effect its neighbors.
    Ch3 reading 4096 puts ch4->3647, ch5->3368,ch6->3176 (when at 0v on ch3 ch4->366,ch5->717,ch6->834)

    Has anyone else see any adc cross talk issues? Any of you Renesas folks seen anything like this? More importantly, does anyone have any ideas on how to fix this or is this actually with in the performance spec?

    With respect to the The init function returns SSP_ERR_INSUFFICIENT_SPACE error. Yes, if you specify # of channels* counts*2 it will not produce the error. However it will also not run properly. You need to add +1 to that calculation for memory space. If you dont, you will see like what is shown in the above image. Half the memory space is used the upper half is left unused. The ssp1.2.0 user manual describes this in section 6.2.1.1 but does not specify that you need +1 more storage locations to get it filled and used properly. I think its assumed one may specify several times that space required. Running at the minimum does not appear to work.

    Thank for any help!
    Matt
  • in reply to rupertm

    Hi Matt!
    I have tried to investigate the problem. I have noticed the cross talk on SK-S7G2 and DK-S7G2 (haven't tried other boards). For now I don't see any solution to fix that and also haven't seen any notice in the documentation. On the other hand, the cross talk is about 0.5% of the resolution, for some of the applications this might be negligible...

    Speaking about user buffer capacity - I have also noticed that. My advice for now is to leave a space for one extra sample in the buffer...
    KR, Jakub

Reply
  • in reply to rupertm

    Hi Matt!
    I have tried to investigate the problem. I have noticed the cross talk on SK-S7G2 and DK-S7G2 (haven't tried other boards). For now I don't see any solution to fix that and also haven't seen any notice in the documentation. On the other hand, the cross talk is about 0.5% of the resolution, for some of the applications this might be negligible...

    Speaking about user buffer capacity - I have also noticed that. My advice for now is to leave a space for one extra sample in the buffer...
    KR, Jakub

Children
No Data