Jump to content
 

Orunmila

Member
  • Content Count

    213
  • Joined

  • Last visited

  • Days Won

    26

Orunmila last won the day on July 8

Orunmila had the most liked content!

Community Reputation

49 Excellent

About Orunmila

  • Rank
    Teacher

Recent Profile Visitors

1,230 profile views
  1. I would also suggest you take a look at this because you seem to be writing to the port register bits which will cause read/modify/write errors. Is it possible that the pin is actually toggling really fast?
  2. When that happens it usually indicates something wrong with the connection to the device. The strengths of the pin drivers are not the same on the different programmers. Perhaps you have marginal amounts of capacitance on the lines?
  3. I was not able to create a satisfactory workaround on the A1 or A3 Silicon. We were able to get Rev B2 Silicon which resolves the problem. The official workaround on A1 silicon is not to use the peripheral but instead to bit-bang the I2C. From the Errata:
  4. Thanks for pointing out the mistake, I have updated the post to show 2.0 LSB which is the correct Offset error for this device
  5. Orunmila

    Ms

    If you load that project it should load with the working version.
  6. Orunmila

    Ms

    Here is the project I generated, sorry for the random name 🙂 wdqwd.zip
  7. Orunmila

    Ms

    I tested it and from v1.80.0 of the PIC10/12/16 library onwards this seems to be broken. If you open the "Versions" tab and find the previous version it still works fine. You can switch to the old version in the IDE. It looks like this on my machine. Right-click on the 1.78.1 version and select Mark library for load and then press the load button at the top next to where it says "Versions" it will appear. After doing this I bet it will work just fine. It builds. I will attach the project for you also.
  8. Orunmila

    Ms

    Sounds like a bug in the latest MCC, have you tried an older version?
  9. I had a similar choice on the CO2 valve for my fishtank, but if my sw had any glitch the tank would be carbonated like soda and everything would die from the ph drop, so I decided to leave the mechanical regulator in the line for a backup if the electronics fail for some reason. You never know what happens when the power goes out or a battery dies at the wrong time...
  10. I used to do a fair amount of optimization using linear programming, it was a bit of a pain to code up so I had hoped this would make that easier ...
  11. Provided nothing went wrong in your analysis that bit being set means that somewhere something did a software reset, you just have to figure out where this happened. N9WXU gave some possible causes of the RESET instruction being used, but it could really be anywhere. I have even seen this happen with a bad function pointer jumping to a location which contained const data. As a last resort you can search through the program memory for the RESET instruction (you can do this in MPLAB using the memory views) and set a breakpoint at every location containing the reset instruction. That way you should be able to catch it in the debugger and figure out where the reset is coming from.
  12. This is really cool! Can this tool generate C code that I can use in my applications or does it just solve the problem for me?
  13. Glad you found it helpful JG2018, Let me try and answer your questions. This part is just math and the magic of logarithms. The important identity here is that logx(y) = log10(x)/log10(y), and we know that log2(x) will give us how many bits we need to represent x, but our calculators do not do log2 instead they do log10 , which means we have to take log10(x) / log10(2) to get the number of bits we need to represent the number. The short answer is yes because the leakage contributes to a measurement error, and we measure the ADC error as a proportion of LSB size as we described above. How the leakage contributes is a lot more involved and depends on the construction of the ADC and the methods it uses for sampling. Section 7 above shows the simplified circuit diagram of the ADC input path and you can see where Microchip places the leakage current specified in the datasheet. If you calculate the network currents when this circuit is attached to your circuit under measurement you can determine how much of an effect the leakage will have to your measurements. If the source impedance is small the bulk of the current you feed into the pin will end up going into the sampling capacitor and the leakage will have a small effect, but of course the higher your source impedance is the lower the current into the sampling capacitor and the more of an effect the leakage current will have. We can use the PIC18F47K40 example above since the leakage current is indicated in the simplified diagram in section 7 above. If we have 10k of source impedance and we have an additional 1k of internal impedance on the ADC charge path we have at 3V approx 272uA charging the capacitor. The pin leakage is specified at max to be 125nA, which means that 125nA/272uA is the proportion of the charge current lost to our measurement. In this example it contributes 0.0459% error. For a 10-bit ADC this would mean roughly 0.45 LSB of error (calculated as 0.0459% of the full range which is 2^10). That explains the comment in the device datasheet that if your source impedance is more than 10k this will result in an additional error of more than 0.5 LSB which means it will start contributing to your measurement error. To see how this turns into a larger error we can do the same math with a source impedance of 100k instead. This divides the current by 10 and consequently increases the error to 4.59 LSB of error. This means you can still take the measurements but you will potentially have almost 5 LSB of additional error to contend with. And you cannot calibrate out the leakage as it varies with voltage and temperature and the spec already has it varying from 5nA to 125nA depending on these parameters and also the process variation.
  14. Looks like it gave the segfault upon running? And yes that is what I would expect because on a PC your code is trying to write to memory which should not permit writes. On an embedded system the behavior will depend a lot on the underlying system. Some systems will actually crash in some way, others, like XC8 based PIC microcontrollers, actually copy the read-only section into RAM so the code will actually work. This is why this is so dangerous, the behavior depends on the target and the toolchain and when this is one day tried on another system it could be a real challenge to figure out the mistake because it is so easily masked.
×
×
  • Create New...