Jump to content
43oh

jpnorair

Members
  • Content Count

    718
  • Joined

  • Last visited

  • Days Won

    18

Reputation Activity

  1. Like
    jpnorair got a reaction from bluehash in KickSat -- Your personal spacecraft in space!   
    Yes, although the parts in question were 1-series MSP430s.  The MSP430 was part of a radio tag that was being mounted onto canisters of Plutonium and Uranium recovered from Eastern-Bloc nuclear weapons and submarines.  The project was from the Department of Energy, managed by Argonne National Lab.  If I remember correctly, the expected mean-time of failure was 17 years, given typical conditions for that application.
     
    I know this, because I was one of the guys who sold DoE/ANL on the tag platform.    The ANL team was great, and they published a lot of their work.
  2. Like
    jpnorair got a reaction from sven222 in Buildng millis() function with watch dog interrupt   
    Is flipflop supposed to divide by 2?  It is a variable declared on the stack, so unless there is some hack or feature of WDT interrupt I don't know about, it is not going to work the way you want.
     
    Easier way to divide by 2 is to just have millis++ in the interrupt (nothing more) and then have get_millis() { return (millis >> 1); } or something like that.
  3. Like
    jpnorair reacted to chicken in Products using MSP430   
    MSP430F5435A and CC2560 in the remote control of the new Amazon Fire TV

    http://www.ifixit.com/Teardown/Amazon+Fire+TV+Teardown/23856#s61356
  4. Like
    jpnorair got a reaction from tripwire in How slow can MSP430 run?   
    The quick and dirty way to do it is to use the highest clock speed supported by the lowest core voltage.  This information is always in the datasheet.
     
    A lot of it comes down to minimizing on-time of peripherals, which tend to have flatter power vs. clock than the CPU has.  Edit: in particular, powering the Flash memory.
  5. Like
    jpnorair reacted to pabigot in MSP430 vs Silicon Labs efm32   
    Culprit explained here.
     
    I believe it should be possible to use the energyAware Profiler with external boards. My intent is to do this, but I haven't gotten there yet. Probably next week, though. (Edit: See details in EFM32 AN0027 on Energy Optimization.)
     
    Still worth having a uCurrent on your desk; cost you about $60, plugs into your multimeter. High ratings from Adafruit, though they don't have them in stock right now.
  6. Like
    jpnorair got a reaction from pabigot in MSP430 vs Silicon Labs efm32   
    I use a LOG114 EVM board and a scope to measure low currents on MCUs.  It's quite ideal for this, because it can measure transitions from the uA range to the mA range in us.  Also, for me it has always reported measurements that are bang-on to reference.
     
    I would expect the EFM32 to have higher sleep current than RF5969 does, when RAM is being retained, because they are both built on a similar 130nm low-leakage process yet the EFM has more RAM.  More RAM = more transistors = more leakage.
  7. Like
    jpnorair got a reaction from abc in MSP430 vs Silicon Labs efm32   
    The rest of the post should explain that.
     
    To clarify: MSP430 doesn't run code as efficiently as CM3 does.  The more code that runs, the more advantage a low-power CM3 has.  If I run a scheduler or whatnot, that has a tangible impact on power usage.  Moreover, running a timer tends to require the ACLK domain is on, which IIRC doesn't allow lower than LPM3.  If you have a pure asynchronous app, you can use LPM3.5 and maybe even LPM4.
     
    If you are trying to build a sophisticated app with low power, it's like spinning plates to an extreme degree, but for networking "IoT" kinds of things I've had better results using STM32L than I have had with any MSP430.  EFM32 is technically superior to STM32L, so I have to imagine it would work nicely.
  8. Like
    jpnorair got a reaction from abc in MSP430 vs Silicon Labs efm32   
    EFM32 has historically been quite expensive, which has prevented most designers I know from using them.
     
    Anyway, EFM32 definitely has great features for using with a low power RTOS.  If you are simply throwing code onto asynchronous interrupts, MSP430 might work better for you.  I should also add that FRAM doesn't really have the same advantage when any sort of timer-based wakeups are used as a critical part of the system (e.g. an RTOS scheduler timer), due to the way the timing and clocking system is architected with the FRAM MSP430s.  If you have a system with line interrupts, FRAM can be pretty great, albeit expensive.
     
    EFM32 is also more efficient than MSP430 during code execution by a landslide.  So if you are doing 1/1000 duty cycle or more on your MSP430, you will get a decent energy saving by switching to the EFM32, even if you are comparing against Wolverine parts.  I guess it goes back to the same point in the last paragraph: if you are stuffing code onto asynchronous interrupts, that's where MSP430 is technically becomes a good option.
  9. Like
    jpnorair got a reaction from Automate in Opinions on LoRa (wireless - long range, low power, sub 1GHz)   
    It is a good product.  Semtech has a long history of producing excellent low-power RF transceivers.  Companies like Semtech do not usually just embark on wild projects like LoRa without someone contracting them to do so, and I don't have confirmation on this, but I am pretty sure that SigFox is who contracted Semtech to design LoRa and the associated transceivers.  So, there is an installed base that you can refer-to, which shows at least that the technology works quite well.
     
    The main downside of LoRa is that there is not a ton of information about it, so it is going to be difficult to achieve multi-vendor interoperability if you are using the LoRa modulation.   I'm not even sure what it is, but based on the limited descriptions I would guess it is some sort of M-FSK -- in fact, I think it is 64-FSK.
     
    The second downside of LoRa is that narrowbanding often works better than DSSS does in the lower bands like 169, 433, etc.  For 862, 866, and certainly US-915, DSSS is either a wise choice or a fundamental requirement, so for these upper bands LoRa makes a lot of sense.
  10. Like
    jpnorair got a reaction from Automate in Opinions on LoRa (wireless - long range, low power, sub 1GHz)   
    In review, it looks like LoRa uses a proprietary sort of CSS modulation (chirp spread spectrum), although it could be implemented as a sort of MFSK as well -- difficult to say.
     
    The basic premise is sound: with good coverage, you don't need mesh routing.  Mesh routing is mostly academic, very few production systems use it.
     
    At 1kbps, which is roughly the data rate he is using, a sensitive FSK device such as CC1200 or ST SPIRIT1 can actually achieve superior range to LoRa if a good error coding scheme is used.  With sophisticated error correction -- maybe not possible on MSP430 but certainly no problem for ARM CM3 -- I have observed 1 mile range in open outdoor conditions with 433 MHz, regular FSK set to a higher data rate, and using even less transmit power (for example, 1mW vs 100mW of AngelBlocks).  For AngelBlocks, the advantage of the LoRa implementation is that the US 915 MHz band is an interference nightmare.  Without sophisticated frequency hopping or a good spread-spectrum technique, the message just isn't going to get through.
  11. Like
    jpnorair got a reaction from abc in UART and alternatives   
    I2C is a good option, certainly more flexible than CAN-bus, but if you don't know what you are doing and have no time, you might want to entertain the offer from Spirilis.
     
    You might be worried about power consumption, due to the I2C pull-up resistors.  Here's a solution: have the pins go to HiZ input when they are not being used.  You can set an edge-detect interrupt to manually detect the START condition, and then quickly wake-up and enable everything as I2C before the START condition is over.
     
    The easiest option, however, is to use SPI with two-way chip select.  The fundamentals are the same: switch to master or slave, on the fly, depending on the device that requests access.  You could even do this on a single pin if you are clever, but it still needs 4 or 5 pins vs 2 for I2C.  If you have the pins to spare, it is going to be much easier, though.
  12. Like
    jpnorair reacted to PedroDaGr8 in Wera Screwdriver Sale   
    Was browsing GarageJournal and came across this. KC Tool Co is having a sale on some Wera Screwdrivers:



    Wera Precision Screwdriver Set A $20.99
    Wera Precision Screwdriver Set B $20.99


    Wera Kraftform PLUS 900 series Set $34.99



    Wera Kraftform PLUS 300 Series Set $26.99

    Plus some others:
    Sale Link

    These screwdrivers seem like the perfect sets for your usual electronics hobbyist. Wera is one of the top screwdriver makers in the world (Wiha, Wera, PB Swiss, etc. etc.) Note I emphasized the PLUS on two of the kits because they look the same as the non-plus versions. They Kraftform 300 sets have the laser etched tips that supposedly help the bits bite better into screws.
  13. Like
    jpnorair got a reaction from igor in UART and alternatives   
    I2C is a good option, certainly more flexible than CAN-bus, but if you don't know what you are doing and have no time, you might want to entertain the offer from Spirilis.
     
    You might be worried about power consumption, due to the I2C pull-up resistors.  Here's a solution: have the pins go to HiZ input when they are not being used.  You can set an edge-detect interrupt to manually detect the START condition, and then quickly wake-up and enable everything as I2C before the START condition is over.
     
    The easiest option, however, is to use SPI with two-way chip select.  The fundamentals are the same: switch to master or slave, on the fly, depending on the device that requests access.  You could even do this on a single pin if you are clever, but it still needs 4 or 5 pins vs 2 for I2C.  If you have the pins to spare, it is going to be much easier, though.
  14. Like
    jpnorair reacted to tripwire in Products using MSP430   
    KickSat is currently due to launch this weekend, on 30th March. Assuming all goes to plan there should be over a hundred MSP430s in low earth orbit, for a few days at least
     
    http://forum.43oh.com/topic/1249-kicksat-your-personal-spacecraft-in-space/
    http://en.wikipedia.org/wiki/KickSat
    https://www.kickstarter.com/projects/zacinaction/kicksat-your-personal-spacecraft-in-space/
     
    EDIT: Launch delayed again
     
    EDIT2: KickSat is in orbit! The individual sprites aren't deployed from the cubesat yet. I think the plan is to do that on April 30th (430 day )
  15. Like
    jpnorair got a reaction from dubnet in Over the air programming   
    Just a note: CRC is not totally fail-safe.  There is a hamming distance that a given code is guaranteed to protect against, over a known payload size.  Most implementations of CRC over a variable-length payload are actually broken, though, and their hamming distances are effectively 1.  Better to use fixed-length packets or a header with independent CRC protection.  The problem is that, if the length byte is in error, the resilience of the CRC goes way down.
     
    Other notes:
    The CCITT variant of CRC16 is lousy.  It's the one with polynomial usually represented as 0x1021 ( x^16 + x^12 + x^5 + 1).  This is what is implemented in many MSP430 cores as a peripheral, so it is wasted die area as far as I am concerned. The IBM CRC16 poly is good for payloads up to 256 bytes.  It is 0x8005 (x^16 + x^15 + x^2 + 1).  The CC1101 implements this in HW. You can implement CRC32 by a 1KB lookup table, and compute the checksum over the entire FW image if you like.  
    I'm giving you this advice as a guy who has seen catastrophic failures in HW due to OTA FW transfer using broken CRC implementations!  It is amazing what a single bad bit can do: in this example I'm thinking of, it resulted in bricking, but I know folks who have had HW catch on fire!  
  16. Like
    jpnorair got a reaction from greeeg in Over the air programming   
    Just a note: CRC is not totally fail-safe.  There is a hamming distance that a given code is guaranteed to protect against, over a known payload size.  Most implementations of CRC over a variable-length payload are actually broken, though, and their hamming distances are effectively 1.  Better to use fixed-length packets or a header with independent CRC protection.  The problem is that, if the length byte is in error, the resilience of the CRC goes way down.
     
    Other notes:
    The CCITT variant of CRC16 is lousy.  It's the one with polynomial usually represented as 0x1021 ( x^16 + x^12 + x^5 + 1).  This is what is implemented in many MSP430 cores as a peripheral, so it is wasted die area as far as I am concerned. The IBM CRC16 poly is good for payloads up to 256 bytes.  It is 0x8005 (x^16 + x^15 + x^2 + 1).  The CC1101 implements this in HW. You can implement CRC32 by a 1KB lookup table, and compute the checksum over the entire FW image if you like.  
    I'm giving you this advice as a guy who has seen catastrophic failures in HW due to OTA FW transfer using broken CRC implementations!  It is amazing what a single bad bit can do: in this example I'm thinking of, it resulted in bricking, but I know folks who have had HW catch on fire!  
  17. Like
    jpnorair got a reaction from larsie in Over the air programming   
    For embedded RF, the best way to do it is to have double the Flash necessary, and then just load the new firmware into the other half of flash.  Once it is fully loaded, restart.  Your bootloader can be tiny, it just needs to jump to the newer half.  One thing, however, is that you will need two builds of the firmware: one built to start at offset A and the other at offset B.
     
    Another thing you need is a radio layer that is robust against data errors.  built-in CRC on the 1101 isn't sufficient unless you are using fixed-length packets. If you are using variable length packets, you need to find a way to protect the header with its own CRC, and even then you might want an internal CRC32.
  18. Like
    jpnorair got a reaction from basil4j in Optimising math   
    I'm replying only to this statement, but in the spirit of the topic.
     
    MSP430 has an average ALU by MCU-standards.  Shifting is fast.  Addition is pretty fast too.  Multiplication, however, occurs through a peripheral and it is quite slow.  It is faster than using a software multiplier, but it is still pretty slow because it does not work through registers.
     
    Anyway, often it is much faster to add than to multiply.  In particular, one algorithm I wrote once had enormous, enormous, ENORMOUS improvement by taking logarithm (I made a table), then doing additions, then doing antilog (again, a table).
     
    OK, that was just a vignette, but maybe it applies to you, too.
  19. Like
    jpnorair reacted to pabigot in Why is MSP430's Stack Poniter(SP) always alligned to even address?   
    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 structure declaration annotated with __attribute__((__packed__)) which indicates that the native alignment requirements might not be satisfied (e.g., if some idiot defines a structure that begins with three uint8_t followed by uint32_t). Use of a packed structure on the MSP430, even if it happens to be aligned for some particular instance, has a huge impact on code size as the compiler has to build the multi-byte values up by independent byte read and swap operations.
     
    So only used the packed annotation on structure declarations when you absolutely have to; and, where possible, lay out your structures so they're naturally 16-bit (or, better, 32-bit) aligned.
  20. Like
    jpnorair reacted to greeeg in Why is MSP430's Stack Poniter(SP) always alligned to even address?   
    Just to add. Robomon, you sound like your mistaking the stack Pointer, SP, for indirect addressing. The SP is a special register. It is linked to special function when push/pop/call/ret/reti instructions are executed.
     
    Your byte array would be compiled down to an indirect access, using a register like so:
     
    mov.b @r10,r11 or equiv. mov.b 0(r10),r11
     
    Where r10 specifies an address (doesn't have to be word aligned), and after executed r11 would be equal to the data contained at that address.
  21. Like
    jpnorair reacted to enl in Why is MSP430's Stack Poniter(SP) always alligned to even address?   
    As @@spirilis said, a quirk of the architecture. It is actually a good feature, as it greatly simplifies the memory hardware. If it were not for this, then either two memory accesses would be needed to access a 16bit word (like in the8085, Z80, etc) with a bit more logic to handle it, or a LOT more real estate would be needed for memory access logic, taking away space for other options and reducing the manufacturing yield, raising cost for the device.
  22. Like
    jpnorair reacted to spirilis in Why is MSP430's Stack Poniter(SP) always alligned to even address?   
    To answer the last question, addresses only store 8 bits, it's just that the MSP430 only performs 16 bit operations on even addresses (assuming the stated address contains the least-significant byte, and the odd address 1 higher contains the most significant byte; i.e. Little-Endian). FYI if you want to see an architecture that has truly 16-bit "bytes", take a look at the TI C2000 series (there is a LaunchPad for the Piccolo F28027 series chip for $17). That's a TI proprietary DSP/MCU 32-bit arch with 16 bit "bytes" and 32-bit words.
     
    Sent from my Galaxy Note II with Tapatalk 4
     
     
  23. Like
    jpnorair reacted to spirilis in Why is MSP430's Stack Poniter(SP) always alligned to even address?   
    Likewise though 8 bit instructions exist, i.e. the ASM instruction has a ".B" at the end to designate Byte. These can perform on arbitrary odd or even addresses, but any that copy byte data to a local register must acknowledge the fact that registers are 16-bit. For the most part this isn't an issue except with Signed data, where a signed 8-bit integer must have the SXT instruction applied to its data in register to make it work correctly as a signed 16-bit integer. This should be transparent to your C program though since the compiler takes care of it.
     
    Sent from my Galaxy Note II with Tapatalk 4
     
     
  24. Like
    jpnorair reacted to spirilis in Why is MSP430's Stack Poniter(SP) always alligned to even address?   
    16 bit operations can only occur on even addresses, just FYI. When 16bit operations occur the least significant bit of the address is ignored and assumed to be 0. Just a stated quirk of the architecture. This has bit me in the ass before when casting an arbitrary pair of bytes inside a uint8_t array to type "int"... weird results occurred.
     
    Sent from my Galaxy Note II with Tapatalk 4
     
     
  25. Like
    jpnorair got a reaction from bluehash in IP based IoT protocols   
    The question you really need to ask yourself is UDP, TCP, or if you are adventurous, SCTP.  At the application layer, the discussion is more about what kind of API you want moreso than what kind of networking features you want.
     
    In any case, MQTT is used for some things where REST is too much protocol overhead, especially push notifications, but generally both MQTT and HTTP are implemented above TCP, so the limitations are the same.  That is, with TCP you get generally get stuck needing a centralized hub, and there's no way to broadcast.  If you need to broadcast, you need to use a UDP or SCTP based application protocol.
×
×
  • Create New...