Ff Me Reading Game Info Problem
Rynn Bronaugh
I'm just starting to work with the ADS7038. I'm currently trying to read all 8 inputs using the manual mode, but it looks like the chip just keeps sending the same value from analog 0 and does not advance to read any other analog point.
Also this image is not very clear on timing. Is the t_SU_CSCK timing being met, this is the time from the CS falling edge to the first SCLK capture edge, in this case it would be the first rising edge. This has to be a minimum of 3.5ns.
2. would you use the FIX_PAT feature of the device, register DATA_CFG (address = 0x2) has an option to set a fixed pattern as the SDO data instead of the measured data. this was included to help with communication issues. Once this is set, the ADC will output a fixed data pattern as the ADC output data. Page 31 of the datasheet has the register content information.
It looks like I might have been mistaken when I thought I was writing to the registers successfully. I see in the data sheet that there are 4 different SPI protocols. I haven't done anything to set the SPI protocol. Do you think that might be the problem? I'm talking to the ADS7038 with a Zilog eZ80F91 processor and I'm talking to it through opto-isolators.
The default clocking scheme (SPI-00) in the ADS7038 datasheet shows in figure 8-9 that SDO is available to sample on the rising edge of SCLK. I'm not familiar with the Zilog but default value in the Zilog register SPI_CTL (CPOL = 0 and CPHA = 1) means that your uC is sampling SDO on the falling edge according to Table 111 in the manual.
So the solution appears to be to reset bit CPHA in register SPI_CTL in the uC at start-up so that the sampling edge is rising and SCLK idle is low. However that leaves you with the problem that SS will go high between bytes, again according to Table 111. Unfortunately it appears that you can never make a 24-bit read/write register command in order to take control of the ADS7038. It could be that the Zilog SPI is fundamentally incompatible with this ADC out of the box.
All is not lost however. If all the above is correct, you should consider changing the pin function of SS to a standard GPIO and toggle it manually before and after a 24 bit SPI transaction. If you cannot change the pin function of SS then disconnect it from ADS7038 altogether and substitute it for a standard GPIO which you are able to toggle manually. This manual toggling of SS is the very technique used in the ADS7038 demo code for manual conversions so is a perfectly sound solution from the perspective of the ADS7038.
The manual channel selection does not appear to work for me either. After a device reset, each individual channel works as expected but then if I move the channel to another MUX input, I just get high ADC values where I should get close to 0.
I think the cause is that the sample and hold capacitor holds charge from channel N. If channel N+1 is then selected by the MUX but N+1 is floating, the SAH cap does not discharge or charge to a new value so N+1 channel kind of inherits the sample from N.
There is a good point here that the analog input should not be left floating. For debugging i suggest using different known DC inputs for different channels, ex Ch0 = gnd, Ch1=1V, and so on. This helps to compare the expected output with the actual output.
Cynthia's point about the asymmetric clock notwithstanding, your scope plot doesn't seem quite right. Yes, the 1 bit is in the right place but why is green trace rising again after the eighth bit and why does the SCLK stop after 8 bits?
It's working now (yay!). I figured that the asymmetry is most likely caused by the opto-isolators and would be less significant at lower frequencies so I slowed it down by a factor of 4 and now everything is working; I can get it to generate the test pattern and I can read the analog inputs beyond ch0.
BTW Kier, the reason SCLK stops after 8 bits is that I was only showing the first 8-bit SPI frame so I could show a clear picture of the relationship if SDI to SCLK. There were 2 more 8-bit SPI frames for a total of 24 bits but they weren't shown on the scope.
Hi all! I install Dyndlood, make a kods for trees and its working great. Now i want to make a grass lods, and when i run dyndolod, it has same issue every time: Error reading grass tamriel -1;-1, unknown grass data file format. I'll reinstall all in this way: 1. Start sseloadgenx64, archive with winrar output and install like a mod in mo2. 2. Start ngio, install output grass folder like a mod in mo2. 3. Run texgen64, install output like a mod. 4. Run dyndolod and have an error message like on the screen. Can somebody help, wat am i doing wrong? Ty!
Do not make/post photos of your monitor, unless there is a problem with the monitor. -a-screenshot.org/windows.html
Do not post images of text, post the text instead as explained on the first post.
As explained, use the "Click on this link for additional explanations and help for this message" to open
Unknown grass data file format
There is a problem reading a grass cache *.CGID/*.GID file. It is most likely in the vanilla Skyrim LE format (Skyrim SE vanilla BSA ship with the Skyrim LE format, hence the vanilla grass cache files do not work).
Find the file in the ..\Data\Grass\ folder and delete it, or in case it is a vanilla *.GID file make sure it is being overwritten with a valid file.
The filename is of the form [worldspace]X[x]Y[y].CGID with leading zeros to pad up to 3 digits.
The mod Grass Cache Fixes comes with a BSA that overwrites the vanilla grass *.GID files which are typically not generated by grass cache generation, since they are in areas that have been removed from Skyrim.esm.
I'm on Skyrim AE (GOG version) and following the instructions on Grass Cache Fixes to generate grass LODs using Veydosebrom with the available pre-cache found here. DynDOLOD only runs for a few seconds before I get this error:
Use the "Click on this link for additional explanations and help for this message" to open
Scroll down to "Error reading grass [worldspace] [x,y]" and to "Unknown grass data file format".
Read both the explanations.
Hi Sheson, appreciate the help. I've searched the grass cache folder for the file corresponding to the error and it seems to be completely missing. After downloading the files several more times just in case something got corrupted in the download I am still at a loss as to how to resolve this. Unfortunately I am on AE so I am unable to generate my own cache using NGIO. What's odd is that others have downloaded the same file from Nexus and don't appear to have this issue and are able to use the pre-cache. I was wondering if there was any possible way to get DynDOLOD to skip those particular coordinates or some other workaround that would allow me to continue generating the LODs.
-grass-data-file-format
Find the file in the ..\Data\Grass\ folder and delete it, or in case it is a vanilla *.GID file make sure it is being overwritten with a valid file.
The mod Grass Cache Fixes comes with a BSA that overwrites the vanilla grass *.GID files which are typically not generated by grass cache generation, since they are in areas that have been removed from Skyrim.esm.
Still not quite sure how this can help resolve the issue. I already have Grass Cache Fixes installed and loaded, and have followed the instructions provided on it's Nexus page. I have uploaded the bug report and log file from DynDOLOD as well if they are of any use. Again, thanks for your time.
It is unclear if the tool is looking for *.cgid or *.gid files, since you did not upload the DynDOLOD debug log and did not mention it. If the grass cache file for the coordinates can not be found as a loose file, we have to assume that this means you instructed the tool to use *.gid files and it is reading the vanilla *.gid file from the BSA. As explained, in that case make sure it is being overwritten by a *.gid that is valid for Skyrim SE.
c80f0f1006