Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by pabigot

  1. I did notice this behavior with the rev 1.4 EXP430F5529LP (which has a red underside). The rev 1.5 EXP430F5529LP (white underside) can be powered from a plugpack. I didn't pursue this clue further as it's the 1.5 ones I plan to deploy around the house (someday...), but this behavior is confirmed by slau533a, though no workaround is mentioned. I suppose if you break out a USB cable and connect the 5V/GND to the correct BoosterPackXL pins it could work, though not being an EE I worry that there might be some power conditioning/boost/buck converters that would get bypassed.
  2. Got a common build infrastructure for Tiva TM4C123, TM4C129, and EFM32TG/EFM32GG working, based on gcc-arm and the CMSIS startup and linker scripts. Not convinced it was worth the effort, yet.
  3. Yes; mine turns out to be an A1 die revision, which at least doesn't have quite as many ugly errata as the A0 revision. For $20 per board I think we can expect to be beta-testers.
  4. The approach I'm taking will probably only work with arm-gcc (maybe CodeSourcery too). It uses an external MCU-specific file to provide the contents of the vtable so the startup file is shared, and the same external memory.ld file I used in MSP430 so the linker script is shared. It uses CMSIS 4.0 standard global handler names, instead of TI's names; driverlib/sensorlib should work, but the TivaWare examples will probably need to be edited. It also sucks in more of the standard arm-gcc CRT infrastructure than TI's setup, increasing base code size by about 1 kiB, which is something that both
  5. Agreed on the later. For the former, I think Energia really needs to take a look at what they've done, unless TI has indemnified Energia against IP claims. You're braver than I am; I won't even quote your workaround let alone use it myself. I'll be doing a clean startup infrastructure from the ARM CMSIS GCC files instead, BSD-3-Clause licensed and attributed.
  6. I took a look at libopencm3, which does appear to be active but doesn't seem to have any existing support for Tiva, and only blank headers for Stellaris. Then I looked at TivaWare 2.1.0, which I'm bludgeoning into behaving more like what I want (this concept that every application should have its own startup_gcc.c and linker script is poor toolchain design). While this wasn't hard and I'm busy developing programs and becoming basically familiar with Tiva C, while doing that I notice that both the linker script and the startup_gcc.c file from TivaWare have a software license that explicitl
  7. pabigot

    Tiva version 2.1

    You're supposed to be able to figure out the silicon and die revision from the printing on the top of the chip, but mine don't have the correct markings either. You can read the chip revision in the DID0 register, though. #include "inc/hw_sysctl.h" /* ... */ { unsigned int did0 = * (uint32_t*)SYSCTL_DID0; UARTprintf("Hello, world: %x: %c%x\n", did0, 'A'+((did0 & SYSCTL_DID0_MAJ_M)>>8), (did0 & SYSCTL_DID0_MIN_M) ); } From this mine are both B1. It also appears the available ROM functions do vary depending on revision (e.g. some EEPROM routines weren't in RA1); see drive
  8. Shift of a single bit is "fast", but shifting multiple bits is linear in the number of bits (not so much c+n, but c*n): IMO the msp430 does a pretty poor job of shifting in general. The time also depends on which instruction is used: the standard one-bit shift operation in a loop, or either the constant (1-4 bits) or register (1-15 bits) CPUX instruction. The latter are slightly faster and take less code. Multiplication is not that slow. The user's guide for the FR57xx MPY32 has full results available no more than 4 cycles (16-bit; 11 cycles for 32-bit) after initiating the operation. Othe
  9. FWIW, there's a driver for the Sharp Memory LCDs in bsp430 too; see this source file. There's also a bridge from it to u8glib. This was mostly proof-of-concept and to give me something to use if I suddenly needed a white-on-mirror display for something (dunno what y'all are using for this effort, but TI's boosterpack is pretty hard to read).
  10. I haven't noticed any rules for priority across peripherals at all. Timers, DMA, ADC, USCI, ports, all can be different priority on different MCUs. So again, if it's important, you have to be aware of what will happen on the particular chip you're targeting.
  11. For Energia it appears so as @@spirilis has described. For the MSP430 more generally the priority is determined by how the interrupt handler is implemented. If two or more pins on the same port trigger at the same time, the interrupt routine would be executed. If any of the corresponding bits in PxIFG remain set when the routine is exited, then the ISR will be immediately re-entered (if interrupts remain enabled). This repeats until PxIFG is cleared. If you determine the pin for the interrupt by reading PxIV (in newer chips) then the lower numbered pins will be processed first (automatical
  12. Yes, the WeMo apparently does use STUN. See Vulnerability Note VU#656302. As that report suggests, there are a huge number of security issues (including information leakage) that are part of the IoT, many of which aren't of great interest to the companies commercializing the products or end users who aren't used to security analysis. Some of the threat vectors are obscure, but no less real for that. (I consider myself just knowledgeable enough to know there are risks I'd need to work with experts to identify and solve.) I'd pass on adding this capability myself; if I did do it, I wou
  13. What @@spirilis said about 16-bit operations needing to be aligned is correct and applies to word operations regardless of addressing mode. The insight with the stack pointer specifically is that, at any moment when interrupts are enabled, the MCU must be able to push the program counter and status register onto the stack as words to execute an interrupt. Thus the stack pointer must at all times be 16-bit aligned. Also as noted, word access to odd-byte-aligned data gets the wrong answer. Sometimes when working with mapped structures (e.g., network packet headers) you might find the struct
  14. #include <string.h> int strcmp(const char *s1, const char *s2); int strncmp(const char *s1, const char *s2, size_t n); Assuming your toolchain has a proper libc. (edit) In case you don't have man pages: the return value is negative if s1 is lexicographically less than s2, positive if it's greater, zero if they're equal.
  15. Absolutely, which is why I said if you have an implementation give it a try. If you don't CoAP exists only on paper (and in draft form), in which case alternative solutions that exist in software should be considered and explicitly rejected before jumping on the CoAP bandwagon. If you end up having to write something yourself and don't need interoperability, take the ideas from CoAP and develop a simpler protocol that doesn't try to solve everybody's problem. Nothing's wrong with cross-layer operations, when they're optimizations to a well-architected system. A layered/partitioned a
  16. IMO CoAP is a mess and is at best superficially RESTful, but I've pointed that out enough on the IETF working group reflector in the past four years that if you want details you should go there. If you've got somebody who'll give you an implementation, and that implementation is interoperable with any others that you care about, then it's worth trying. I really don't recommend trying to figure out or implement the protocol on your own. If you do need to understand it, you might find some help in this page which is my failed attempt to clarify the domain concepts to the point where it cou
  17. pabigot

    Mailbag

    It may be mine was expedited because I'd bought over $500 worth of other stuff from them in the last four weeks. Between TI, Adafruit, Pololu, and Sparkfun my research budget for this year has been completely blown; on the other hand, I've got the pieces necessary for a half dozen complex projects.
  18. pabigot

    Mailbag

    Fedex just dropped off two EK-TM4C1294XLs. Maybe I'll have a chance to even try them out sometime in the next week.
  19. Just FYI: based on a customer survey I got a couple days ago, I'm expecting Saleae to announce a new product real soon now. The questions implied that it might be scope-ish in nature. I don't use my Logic8 any more, but that's only because the Logic16 is all around better; I've got it up pretty much any time I'm working at low level on a micro-controller. But then I don't do enough analog stuff to get much value out of a scope.
  20. As spirilis notes, gcc supports this (well, the msp430-elf one should; I suppose mspgcc does but I never use it). Note, though, that the value of BIT0 is 0x01, not 0x00 as you have it above. Finally, the choice is a matter of style and maintainability. I don't get your "crazy antiques" reference, but here's an alternative perspective that might convince you to reconsider (not only for MSP430 but for other systems as well): First, mostly nobody uses the MSP430 16-bit port interfaces; there's no real value in doing so unless you're manipulating bits in both halves at the same time,
  21. I was just about to post a question about why my new BOOSTXL-BATTPACK drained energy at 1000x the rate the launchpad it was connected to consumed it, when I decided to try due diligence and see if the question had been answered before. Lo, there it is, in the PS #2 to your blog. Conclusion: This boosterpack is useless in unmodified form (and if I wanted to solder 0603 resistors I'd be building my own hardware instead of buying it off the rack). Oh well: there'll still be an example for it in the next BSP430 release.
  22. I think the role of this board in IoT is as the border router: you could put two ISM-band radios on the booster-pack headers, and translate from the OTA format to IP/eth to talk to the real-world through a wired connection. I'm planning to use a BeagleboneBlack for that purpose in my experiments with 802.15.4. I tried a RedWire IoT kit with a router+sensors last summer, and gave up for two reasons: Contiki being unreliable on not-particularly-open Freescale hardware, and a seriously underpowered ARM chip in the router that couldn't provide information on what was happening in the radio or
  23. Somewhere recently I saw a statement that the MSP430 internal pull-ups are around 30K. Based on my limited EE knowledge, that might have been the problem: too strong for the circuit (e.g., I2C). I don't remember where I saw that, or whether it's documented in the datasheet somewhere (one would think...). Generally I use internal resistors only on buttons.
  24. The documents may not have been released, but the board is supported in TivaWare_C_Series-2.1.0.12573 released 07-FEB-2014 No board support in openocd yet, though one would hope it'll be pretty easy to add.
  25. Bought a lemur4 two years ago; works great. They even upgraded me to a faster processor because I bought just before Ubuntu 12.04 came out and they had to delay shipment by a week or two. I'll probably go with them again next laptop, but that won't be for another year or so I think.
×
×
  • Create New...