 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : A few under-the-hood questions
| Author | Message | ||||
| BrantB Newbie  Joined: 27/10/2017 Location: CanadaPosts: 40 |
As I mentioned in one of my other threads, I am quite new to the Micromite ecosystem, but not new to designing and programming. I am really trying to dig into it (MMX, mostly), and so far I am loving it. (Hats off to Geoff and Peter for what they have done, and continue to do!  )Given my past experiences (in other environments), I cannot help but be quizzical about some of the inner workings. Bad things happen when one makes assumptions. So, I have a small series of questions about how certain things function, and what has or has not been implemented. Rather than pepper the forum with multiple threads, I thought it better to collect everything in a single posting. Here goes... SD Cards (specifically, writing to) The convenience of such easy SD Card access in MM(+/X) is amazing; truly a difference-maker. Although my experiments have so far been simple ones, the results have been terrific. I do have a question about the write routines, though. How/When does the writing actually take place? Is data only written out to the card when a file handle is explicitly closed, or is it written out when a block of 512 bytes (a sector) has accumulated in the file buffer? (Um ... I presume there must be a file buffer, internally, yes?  ) If there is some intelligent caching built in, does it account for file/sector alignment (i.e., if a file begins part way through a sector)?Any insight here would be greatly appreciated. I would like to understand what I have to be responsible for, in terms of not wearing out the SD Card (i.e., writing one byte at a time) versus having too much unlogged data at risk (as well as chewing up RAM). USB Memory Sticks (indirectly related to SD Cards) Preface: I readily acknowledge that it is very easy for me to think I understand something ... and even if I am correct in my understanding, that there may still be a world of difference between the ease of understanding it and the effort required to implement it. So, I don't ask this one tritely. I believe the PIC32 MZ's have multi-mode USB support (Host, Slave, On-The-Go). If so, am I correct in thinking that it would (should) be possible to implement reading/writing USB memory sticks in a similar fashion to SD Cards? To the uninitiated (me  ), it seems that the file system interface is/was the heavy lifting, and that part has already been done for SD Card support). Does Microchip not provide example libraries (Harmony?) for things like OTG, etc.?Again, I cannot stress enough that as someone without the necessary C/C++ skills to be able to actually contribute directly to MM/MMX development, it is totally unreasonable for me to expect someone else to just dive in and do it. That's not my intention. But I felt it would be a worthwhile question to ask, as I have not come across such a discussion in other threads. (Granted, I have not read every single thread - but, I can tell you that I have read through a bunch!  )Keypads (debounce? multi-key?) The MM manual talks about the (super simple) built-in keypad interface, and in a nearby section, it also talks about switch sensing. For the switch sensing, it talks about using a capacitor for debounce (a concept which I fully understand). That section makes it pretty clear to me that there is no internal debounce algorithm built-in. Fair enough. An external cap for discrete switches is not a big deal. But what are the implications for the Keypad function? I am assuming the function works in the typical fashion, where rows (or columns) are "stimulated" in a sequence, and the columns (or rows) are "sensed" during the scan cycles - is that right? If so, that more or less precludes using external debounce circuitry, doesn't it? The way I see it, the caps won't have sufficient time to charge up for the sensing ... or, they will have to be of such a small value as to be of little practical use ... etc. Am I missing something? Especially since the Keypad function throws an interrupt when a key is pressed, is it safe to assume that there is actually some digital debounce taking place internally in MM? (I would think so, otherwise the interrupt would fire multiple times during the bounce). I am asking this in advance of testing, because I want to know how to properly wire up my test/development circuit. One last Keypad question: I presume it does not sense parallel presses (example scenario: hold the 1 and 3 button down while powering up to enter a special debug mode)? Cheers! Brant |
||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
The file system is buffered (512 byte sector size) and the buffer is flushed when full or on close. If you want to guarantee that the data is written to the SD card you need to close then reopen the file. Both the MM+ and the MMX use the FatFs library and you can find more on it at: http://elm-chan.org/fsw/ff/00index_e.html. USB memory sticks can be supported but it is not trivial. It is not worth the complications that this would bring on the MM+ but the MMX has more flash and matherp might implement it in the future. Yes, the KEYPAD function sequences through the rows and detects keypresses on the column lines. It cannot detect two or more keypresses at the same time (this is inherent in the keypad) and if that happened it will return rubbish. Finally, yes, the keys are debounced with a 40mS debounce time. I hope that this helps. Geoff Geoff Graham - http://geoffg.net |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
Great info. Thanks - helps a lot. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
