Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by pabigot

  1. Also note the 12-bit samples are packed into 16-bit half-words, so unless you have the MCU intervene to pack them tighter you're actually talking a data rate of 2 MiBy/s.
  2. If you look at the TivaWare source, there are several cases where, unless CLASS_IS_TM4C123 and CLASS_IS_TM4C129 are defined externally to compile-time constants, the code determines whether it's running on a TM4C123 or TM4C129 at runtime by reading SYSCTL->DID0. It works, but it's an interesting design choice since the information was required to be known at compile-time use of SysCtlClockGet on a TM4C129 could have produced a compile-time error rather than a runtime brick-the-device behavior.
  3. My comments on libopencm3's lack of support for Tiva and EFM32 hardware (which is what I have) weren't based on the wiki; I cloned the repository and looked. As best I can tell after fetching the deltas since I assessed it in late March, STM32 is still the only platform that's getting any attention. The development model they had seemed to be to implement everything from scratch by transcribing content from data sheets or other sources, instead of leveraging the existing BSD-3-Clause CMSIS headers that STM makes available through STM32Cube packages. All in all, the whole project does
  4. Look at the Saleae offerings. If you mostly do digital, their Logic8/Logic16 might do what you want. If you also need analog, they have a new integrated solution that's just coming out that might be tempting. https://www.saleae.com/
  5. I bought an mbed on the theory I could make it work with a CMSIS-based development environment, but after looking into it a little bit closer am concerned it's outdated and expensive for what you get. I might still play with it sometime but the STM kits look like they're more capable and cheaper, if you're not interested in the mbed environment. To avoid linker script/makefile issues with ARM when you're using a POSIX/GNU environment, take a look at BSPACM. It handles all the lower-end (<$100) TI Tiva and Silicon Labs (EFM32) kits that I've found.
  6. This is why I object to attempts to be clever: any instruction that has no effect could in principle be removed too. If there is any instruction that will do what you describe it's going to be what the vendor specifies as NOP, because there's a boatload of code and years of developer experience that expects NOP in an instruction stream to produce the minimum delay that can be expressed. Sometimes that delay might fall into a stalled pipeline stage or get dropped after decode and so not extend the duration of an unfinished instruction. That's something experienced coders will be comfortable wit
  7. I think the clue finally dropped: so an example would be something where (1) you're iterating over an object that by design cannot have more than 255 elements (so it's appropriate to express the index bit length limit in its type), and (2) the code needs to run on two distinct platforms: one where an 8-bit iterator index is faster than the default word size (uint8_fast_t is roughly unsigned char or a non-standard type; is this PIC8?) and one where an 8-bit iterator index is no faster than or maybe even slower than the default word size (uint8_fast_t is unsigned int or a non-standard type). Oh,
  8. This is a very good point, one I usually forget because where I use size-specific types I'm almost always focused on enforcing and communicating to the maintainer the representation range and the number of octets used in storage. If you wish to express clearly in the code your intent that a code sequence manipulates only a specific value range, and you care about speed but do not care about data size, then use these versions. I suspect the only reasonable use of these types is in declaring local variables for calculations on size-constrained values, e.g. when scaling (and I should start usi
  9. The code is here; the analysis is here. The resolution of the prediction is I learned several things---among them, that MOV R8, R8 takes two cycles---but the null hypothesis holds. The conclusion is:
  10. OK, fine, though my recommendation of the JSF-AV document was intended as general advice rather than in the context of this specific issue. I'm still not gonna use or recommend using a size-qualified type for local variables used solely for indexing arbitrary objects. (I would endorse use of size_t, except that it's a pain when using msp430-elf-gcc.) FWIW, the claim in the JSF-AV appendix related to whether char is signed or unsigned is not good advice; char is signed for every GCC target I know, and probably for LLVM as well. Best to only use unqualified char for text (which JSF-AV may r
  11. The tests were run at the power-up speed of 16MHz.
  12. I see that happening more and more; I blame it on injudicious application of MISRA rule 6.3. It's absolutely the case that types with specific sizes should be used when the range is potentially beyond the native word size of the processor or data is exchanged over a communication link, including via a file. I have yet to see a cogent argument why specific-size types should be used in preference to "int" and "unsigned int" for indexes and offsets where the native word size is appropriate, or when you're manipulating a processor peripheral that is known to be that native word size.
  13. I don't get why every time I get into this sort of discussion I'm the one who gets to spend time doing the experiment to find the real answer, but what the heck. In the interests of best scientific practices, before I get started I'll define the experiment: Timing will be performed by reading the cycle count register, executing an instruction sequence, then reading the cycle counter. The observation will be the difference between the two counter reads. The sequence will consist of zero or one context instructions followed by zero or more (max 7) delay instructions The only context instruct
  14. The SharpLCD library code I find has __delay_cycles parameters no smaller than 100 on an MCU that's running no faster than 20 MHz, except for a couple that are based explicitly on the clock speed and the comment says they need to be at least 2us. So it looks like you do need something that's on the order of microseconds (as opposed to < 100ns), and that's long enough to be worth using the cycle timer. I'd use the same approach as BSPACM_CORE_DELAY_CYCLES. (Well, of course I would; I wrote it specifically for that sort of situation.)
  15. It gets interesting if you dig into it. The ARMv6-M Architecture Reference Manual in section A6.7.47 specifies that NOP is an "architected NOP" that is a hint instruction as defined in section A5.2.5. Hint instructions are what implement sleep/wake features (SEV, WFE, WFI, YIELD). The assembly code "NOP" expands to the 16-bit instruction 0xBF00. This specific instruction was introduced in ARMv6T2. (The phrase "architected" appears to mean that every ARM implementation must behave within the defined limits, as opposed to non-architected behaviors where a vendor may change the behavior, e.g
  16. Odd, I'd expect that statement you commented to not compile, since the compiler wouldn't know what i1 was (as you note, it's not in scope). Declaring a variable within a for statement as in this code is a C99 or C++ feature, and the scope of the variable is the for statement including its body. With C98 or earlier it's a syntax error. To the point of the original question: If you declare a variable in the enclosing scope (e.g., at the start of the function) you certainly may reuse it for multiple loops within that scope.
  17. Yes, you're misunderstanding that. The crystal is a physical device with a fixed frequency, and the EXP430F5529LP has a 4MHz one installed. The higher drive settings are used when a higher frequency crystal is installed. I don't really understand how you can get a 25MHz MCLK out of the 32 kiHz XT1, but if it works for you then what you're doing is probably not what you think you're doing. Here's one reason: The power-up configurations for SELS and SELM are 100b, for DCOCLKDIV. The bits for XT1 are 000b, and for DCOCLK they're 011b. When you use bitwise or to reconfigure the register
  18. You didn't say, but I assume that if you don't remove the stabilization loop it never passes. If that's true, try moving the P5SEL assignment that enables XT2 up above the test for whether XT2 is stable.
  19. Apparently not. From the ARM CMSIS core_cmInstr.h header (ARM GCC flavor): /** \brief No Operation No Operation does nothing. This instruction can be used for code alignment purposes. */ __attribute__( ( always_inline ) ) __STATIC_INLINE void __NOP(void) { __ASM volatile ("nop"); } So this is the first "nop" I've ever encountered that explicitly notes its use might not produce a delay. Good to know, and for pipelined architectures obvious (at least once it's pointed out). I could imagine that an unadorned asm("nop") as described by @@Lyon in that thread might not work if the comp
  20. Egads. Yes, I suppose it may work. The standard "intrinsic" in CCS is _get_SP_register() and msp430-elf-gcc should provide the same. mspgcc provides __read_stack_register() (it might not have the alias, in which case energia should probably add it). Any toolchain should have something that does this for you without having to introduce undefined behavior.
  21. Yes, I think you shouldn't be surprised. This is part of why I prefer to use the CMSIS register interface: I don't have to guess what intermediate helper functions (are supposed to) do. Instead I have to understand the hardware's underlying capabilities and interface, which is initially more effort but in the long run more rewarding. By not supporting CMSIS TI makes this unnecessarily difficult, and I'm probably going to continue to complain about it for as long as I'm using the otherwise nice devices.
  22. (gdb) p/x 1441792 $1 = 0x160000 At a guess, it's returning exactly what you passed in, which is not a speed in Hz.
  23. I think it's probably right: C defines the behavior of arithmetic on unsigned int very carefully. (Beware, though, that unsigned char does not behave as nicely as it can promote to a signed type, and once something becomes signed all bets are off.) http://www.thetaeng.com/TimerWrap.htm is my go-to site whenever I start having doubts about whether I'm handling counter comparisons correctly.
×
×
  • Create New...