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
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!
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.
Oh that second image somehow over wrote the first. He is the correct first image.
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
Hello Karol, I have question with respect to the Length of data-buffer. I need 8 adc input. So Im using the first 7 and then #19. These were setup in the driver under the periodic framework. When I go and define the length of data-buffer I need to define at least 40 so that I do get errors. There are 12 memory locations that are then required but not used. Lots of wasted space. Is there a way with the the periodic framework to not need the extra unused space between 7 and 19 on the adc channels? Im thinking that dtc is not able to do anything other then a linear memory space move and cant do just the used memory space. Is that correct or is there a way to do it with out wasting the space? Thanks Matt
So I was just doubling checking things today and walking though the adc setup. I was using E2 studio to verify the registers for the adc were getting the proper timing values set when I stumbled across something that looks like its missing. In the IO registers ADSSTR00-06 hold AN000-006, ADSSTRL holds AN016-21 are for storing the samplestate values. From the looks in the debugger ADSSTR06 is not displayed. Im thinking its getting set, but it just does not show. Maybe a bug in the debugger tool?