Jump to content
43oh

jpnorair

Members
  • Content Count

    718
  • Joined

  • Last visited

  • Days Won

    18

Reputation Activity

  1. Like
    jpnorair got a reaction from spirilis in Downsizing. Lots of stuff inside. BoosterPacks+Misc   
    I'm replying here simply to get "I'm looking for an Anal..." off the homepage.
     
    It was funny for a while, now just depressing.
     

  2. Like
    jpnorair got a reaction from bluehash in Downsizing. Lots of stuff inside. BoosterPacks+Misc   
    I'm replying here simply to get "I'm looking for an Anal..." off the homepage.
     
    It was funny for a while, now just depressing.
     

  3. Like
    jpnorair got a reaction from Adnan in Implementing WSN   
    I would use the MSP432 launchpad, because it has the best performance, the best low-power, and I am very familiar with ARM.
     
    If you do not have experience with ARM, the 5529 launchpad will be the best choice.  This chip has much better support than the FRAM ones have, and it can run basically twice as fast.  Since you're building only a pilot project (you're buying launchpads), quibbling over 1.5uA is just plain dumb.  Increase the size of the battery a tiny bit, instead.
  4. Like
    jpnorair got a reaction from Adnan in Implementing WSN   
    A typical duty cycle for a WSN endpoint is between 0.1% and 1%.  Yes, it can be lower if you are doing only transmissions at scheduled intervals, but this is not very functional.  I don't know if you are using someone else's protocol stack or if you are building your own, but I know all the major stacks, and all are at least 0.1% duty cycle.
     
    Even in the 10 minute beacon case, if you are using low data rate to get long range, you will use more power in TX than sleep.  "Back of the envelope" I calculated 4uA average current, which is more than the sleep current.  The MSP432 can sleep at 1uA, the 5529 at 2uA, and the 5969 at something like 0.5uA.  Really, this is a "drop in the bucket."  I've been designing WSN for almost 10 years now.
  5. Like
    jpnorair got a reaction from spirilis in Implementing WSN   
    A typical duty cycle for a WSN endpoint is between 0.1% and 1%.  Yes, it can be lower if you are doing only transmissions at scheduled intervals, but this is not very functional.  I don't know if you are using someone else's protocol stack or if you are building your own, but I know all the major stacks, and all are at least 0.1% duty cycle.
     
    Even in the 10 minute beacon case, if you are using low data rate to get long range, you will use more power in TX than sleep.  "Back of the envelope" I calculated 4uA average current, which is more than the sleep current.  The MSP432 can sleep at 1uA, the 5529 at 2uA, and the 5969 at something like 0.5uA.  Really, this is a "drop in the bucket."  I've been designing WSN for almost 10 years now.
  6. Like
    jpnorair got a reaction from un3x in Enough pins?   
    Just a note: It is probably best to log samples to RAM, and then batch write them to the SD card.  The 5-series parts have more RAM, and they also have DMA, so they would be better if you are really trying to blast ADC readings into the SD card.  A good CM0/CM3 with DMA-backed ADC and SPI will be able to run much harder still, maybe even 1MSps, but for 20kSps you can *definitely* achieve this with a 5-series, and even have plenty of CPU time available for other things should you need them.  
     
    43Oh used to have a USB MSP430F5510 board that mated with booster-pack pinouts.  I would check if this is still available.  That would be my best bet.
  7. Like
    jpnorair got a reaction from Adnan in Implementing WSN   
    There is a pretty big difference.  Read the datasheets more thoroughly.
     
    The biggest areas of importance:
    - CC1200 is good for narrowband, wideband, and spread spectrum.  CC1120 only narrowband.
    - CC1200 has FEC features.
    - CC1200 has lower power "sniff" feature.
    - CC1310 is designed to be easy to migrate-to from CC1200.
  8. Like
    jpnorair got a reaction from Adnan in Implementing WSN   
    Go with the CC1200.  It is PHY compatible with CC13xx, which is TI's next 5 year roadmap for sub 1GHz RF SoC.  Or just go with CC1310.
     
    CC430 is a dead end.  I spent years of my life working on it, so I'm not just saying this.
  9. Like
    jpnorair got a reaction from vinicius.jlantunes in Mailbag   
    Yeah, I don't guess solar is the most cost effective power generation technology in the UK.  
     
    Maybe you can collect rain and run it through hydro.  
  10. Like
    jpnorair reacted to Fred in Mailbag   
    I'm not sure if this quite counts as "mailbag" as it's a bit big, but this was delivered recently. A nice new workshop for the end of the garden that I'm currently busy kitting out with workbenches, power, ethernet, etc. It obviously also required the purchase of some more power tools to do the job.
     

  11. Like
    jpnorair got a reaction from JasonP in Using RTC as an ultra-low-power timer for the likes of MSP432   
    I posted a blog entry about how I used the STM32L1 RTC (a few years ago) as a tickless, ultra-low-power timer for my RTOS.  http://www.indigresso.com/_blog/?p=181
     
    The MSP432 has a similar problem.  Only the RTC and Watchdogs run in LPM3 and 3.5, no other timers do, but you want to use those LPMs for timed sleep!  There is a workaround, and it is actually very fast thanks to the really great ALU in the CM3 and CM4 devices.  My code is also implemented in bulletproof production firmware that I've shipped to various industries .
     
    Yes, the code is for STM32L1, but I think you should be able to very easily port it to MSP432.  If you wait long enough, I already will have ported it, but I noticed some forum activity on this very topic last week and I had to step in.
     
    Happy Coding.
  12. Like
    jpnorair reacted to tingo in I want to buy an awesome 3D Printer   
    I don't define a consumer price range because it is difficult. It depends on too many factors. But see my next point, maybe that will help.
    I don't give an example of an awesome printer simply because I have not seen one yet.
    I have seen videos of professional 3D printers, some of them might be awesome, but they cost a lot (typically USD 15000.- and up), and it is hard to judge the awesomeness of a 3D printer from a few minutes of demo video.
  13. Like
    jpnorair reacted to greeeg in I want to buy an awesome 3D Printer   
    I'd like to chime in. First some background. I am a student, I do not have much money, I will pick a cheaper option that require significant setup over something that works out of the box.
     
    I own both a "cheap" (<$1000) CNC and 3d printer.
    Specifically a flashforge creator (based on the makerbot replicator 2), and a "3020" CNC from china. (30 x 20cm work space)
     
    I have owned my 3d printer for over a year sometimes it delievers great prints, sometimes they're quite frankly terrible. There are alot of various setting and adjustments, being a cheap printer it didn't come with comprehensive instructions. Another note is that prints take A LONG TIME. So if you want to see the result from adjusting a small setting it can be very time consuming. However complex geometries are quite easy to produce on a well tuned printer.
     
     
    I bought the CNC after reading through this guide. http://lcamtuf.coredump.cx/gcnc/ I reccommend if you have the time to do the same. I knew nothing about CNC machining before buying my CNC. I found a local supplier of silicone and polyurethane resins. They are more expensive per kg than ABS/PLA filiments, but likely similar cost to UV resins. I also invested in a huge slab of tooling board. 1500 x 500 x 50mm, which is very quick to machine, and has created perfect molds, with almost no wear on my tools.
    The downside to the CNC is that a complex shape, i.e a simple poject box with a hole on each side requires a fair amount of 3d visulisation to seperate into parts that can be machined on a 3 axis machine. You could end up with a 4 or 5 part mold, whereas the 3d printer would just do it straight from your 3d CAD files.
     
    An advantage of the cnc + molds is that polyurethanes come with a huge assortment of diffrent properties. I have cast flexible and rigid objects, even from the same mold sometimes. The ability to pigment each cast individually is a blessing and a curse, on one hand it enables colour changes by simply adding a few cents woth of pigment or dye. On the other hand getting the same shade of colour for concecutive casts can be difficult.
     
    Ultimately, if this is for buisness purposes, the CNC road will create nicer looking parts. However a 3d printer esspecially something like the form 1+ might be easier for you to get started with.
  14. Like
    jpnorair reacted to greeeg in I want to buy an awesome 3D Printer   
  15. Like
    jpnorair got a reaction from StefanoDS in Strategic advice for MSP presentation   
    The normal Arduino and Energia libraries do nothing for low power modes, but this is changing fast with Energia-MT.  It is not complete yet, really, but it is the shape of things to come as far as Wiring is concerned.  With multi-threading, the RTOS can manage the low power mode of the MCU.
  16. Like
    jpnorair got a reaction from spirilis in Strategic advice for MSP presentation   
    I would focus mainly on the Launchpad devices and the good integration Launchpad has with CCS.  IMO Launchpad is a much better tool for going from novice to professional than Arduino is.  That is something you can discuss.
     
    You can also mention than MSP432 has familiar peripherals to MSP430, so going to ARM CM3/4 in the future is something the Launchpad/Energia community can do easily (and already has), whereas in Arduino-Land the transition to ARM never really happened.  It seems like Arduino-Land is stuck in 8 bit AVR forever.
     
    Lastly, I have made many presentations to engineers.  I would say, over a hundred.  Be nice.  Nobody wants to hear that their chosen platform is dead and is a piece of junk, even if it is.  So you should acknowledge the strengths of Arduino, but then try to pick a few areas where Launchpad/Energia is just must better, and talk about them.
  17. Like
    jpnorair got a reaction from StefanoDS in Strategic advice for MSP presentation   
    I would focus mainly on the Launchpad devices and the good integration Launchpad has with CCS.  IMO Launchpad is a much better tool for going from novice to professional than Arduino is.  That is something you can discuss.
     
    You can also mention than MSP432 has familiar peripherals to MSP430, so going to ARM CM3/4 in the future is something the Launchpad/Energia community can do easily (and already has), whereas in Arduino-Land the transition to ARM never really happened.  It seems like Arduino-Land is stuck in 8 bit AVR forever.
     
    Lastly, I have made many presentations to engineers.  I would say, over a hundred.  Be nice.  Nobody wants to hear that their chosen platform is dead and is a piece of junk, even if it is.  So you should acknowledge the strengths of Arduino, but then try to pick a few areas where Launchpad/Energia is just must better, and talk about them.
  18. Like
    jpnorair got a reaction from congia in Using RTC as an ultra-low-power timer for the likes of MSP432   
    I posted a blog entry about how I used the STM32L1 RTC (a few years ago) as a tickless, ultra-low-power timer for my RTOS.  http://www.indigresso.com/_blog/?p=181
     
    The MSP432 has a similar problem.  Only the RTC and Watchdogs run in LPM3 and 3.5, no other timers do, but you want to use those LPMs for timed sleep!  There is a workaround, and it is actually very fast thanks to the really great ALU in the CM3 and CM4 devices.  My code is also implemented in bulletproof production firmware that I've shipped to various industries .
     
    Yes, the code is for STM32L1, but I think you should be able to very easily port it to MSP432.  If you wait long enough, I already will have ported it, but I noticed some forum activity on this very topic last week and I had to step in.
     
    Happy Coding.
  19. Like
    jpnorair got a reaction from tripwire in Using RTC as an ultra-low-power timer for the likes of MSP432   
    I posted a blog entry about how I used the STM32L1 RTC (a few years ago) as a tickless, ultra-low-power timer for my RTOS.  http://www.indigresso.com/_blog/?p=181
     
    The MSP432 has a similar problem.  Only the RTC and Watchdogs run in LPM3 and 3.5, no other timers do, but you want to use those LPMs for timed sleep!  There is a workaround, and it is actually very fast thanks to the really great ALU in the CM3 and CM4 devices.  My code is also implemented in bulletproof production firmware that I've shipped to various industries .
     
    Yes, the code is for STM32L1, but I think you should be able to very easily port it to MSP432.  If you wait long enough, I already will have ported it, but I noticed some forum activity on this very topic last week and I had to step in.
     
    Happy Coding.
  20. Like
    jpnorair got a reaction from estratos in Introducing CC1310, and discussing Energia support   
    That is OK.  I am happy to collaborate in any way that makes sense.  It sounds like there is still plenty of overlap.  So, PanStamp is now added to my mailing list on this topic.  
  21. Like
    jpnorair got a reaction from estratos in Introducing CC1310, and discussing Energia support   
    Some information about TI's new IoT radio SoC product line is now trickling-out.  CC1310 is a sub-1GHz wireless SoC, and CC26xx units are for 2.4GHz PHYs.  Otherwise, these SoCs are basically identical.
     
    CC1310 | Sub-1 GHz | Wireless Connectivity | Description & parametrics
    CC2620 | RF4CE | Wireless Connectivity | Description & parametrics
     
    The specs of the CC1310 are absolutely insane.  There's no question it is built on a 90nm fab, or maybe even 65nm.  It contains 3 MCUs: the main unit (Cortex M3) the radio controller (Cortex M0) and a sensor controller that is some sort of proprietary 16 bit.
     
    I am interested in working on this platform, and I'm also interested in helping to port Energia to it.  What I can do is the firmware side of things.  I am not a Java programmer, nor do I want to be one.  So I'm putting-out this thread as a "call to arms" for anyone interested in a community-led effort to support the CC1310 with Energia.  
  22. Like
    jpnorair reacted to M-atthias in Forth for fresh MSP chips   
    I wish you happy Easter, of course with a small surprise: I just conquered the MSP432P401R with Mecrisp-Stellaris and I wish to announce quite fresh ports of Mecrisp for MSP430FR4133, MSP430FR5969 and MSP430F5529. Enjoy :-)

    Matthias
     
  23. Like
    jpnorair got a reaction from roadrunner84 in A new MSP430 coming [MSP432 ARM]   
    The [extremely sophisticated] benchmarks I have will port easily to MSP432 and STM32L4.  Atmel will be later in the year, but I have low hopes for Atmel, and I might not bother.
     
    Warning: Rant ahead.
     
    Anyway, Atmel uses more BS in their datasheet and marketing than TI does, and TI uses *slightly* more than ST.  
    Atmel's marketing numbers are unrealistic, best case figures where all the peripherals are off, the integral DC-DC is running, the chip is running at 12 MHz only, and it is running specially crafted code from a small region of SRAM.  Practically, it does 100uA/MHz.  Look at the datasheet, it's all there, albeit somewhat hidden.  Moreover, it's CM0+, so you really should multiply all figures by 66% to compare to CM4: 100 --> 166. TI's numbers are more honest.  A benchmark library is running from FLASH, the clock is 48 MHz, peripherals are mostly on, but the DC-DC is running with input 3.0V.  TI provides a great amount of information about what the power figures are when running with LDO, and they are still quite good (~160uA/MHz). ST is running Dhrystone benchmarks with all the peripherals going, clock at 80 MHz, code from flash, 128 KB of SRAM active, and there is no DC-DC on the device, so it's just LDO.  112 uA/MHz.  I have to guess they have implemented a mixed-size process with the core at 65nm, because they are a "quantum" ahead of the TI and Atmel offerings. I do wireless IoT, at "low" frequencies (sub 1-GHz), and with low power.  I tend to shun DC-DC converters because they kick up a lot of noise that does affect my radios (I've measured, it can be seriously bad).  It takes a lot of design time to cut-down the noise of DC-DC converters, and it's not always possible (if you can control the switching frequency in software, it's a whole lot better though).  Moreover, the input voltage limit of MSP432 and SAML21 is 3.7 and 3.6V respectively, so IT'S USELESS. It needs to be 4.3V at least, so we can use Li-Ion.  Otherwise, I need to make my own step-down from the Li-Ion, and I'm inclined to use my own DC-DC, with a totally vetted analog design and low EMI, that feeds 1.8V to my system.
     
    I really don't need the M4F, but the truth is that I really do prefer the M3/M4 to the M0+.  M0 is a "red-haired step child."  It doesn't fit into a good standard (it's ARMv6+ vs the gold-standard ARMv7).  Compilers are worse.  It only has 8 registers that can be batched to the stack, whereas all the regs in M3/M4 can be (so threading sucks on M0).  It has a crippled NVIC, and on and on.  Basically, it's a low cost hack.  For low power, you actually do better with M3/M4.  For performance, M3/M4 also.
     
    M4F gives the MSP432 (and STM32L4) a really good entry point into sophisticated signal processing apps.  Hell yeah, we're going to do FFT on these things.  I think it is ridiculously cool to do FFT -- fast -- with 4-8 mA.  Not everyone here realizes the kinds of possibilities this opens-up.  You might not think you need FFT, but the best Reed-Solomon algorithm uses FFT, and RS is awesome for error correction and data integrity in lossy IoT networks.  So it's a completely legit thing to talk about.
     
    I want to reiterate that I only hate Atmel because they make me hate them by being disingenuous.  If they changed their ways, I would have no issue.  I have "no dog in this fight."
     
    Anyway, I can tell you now that any performance difference between MSP432P4 and STM32L4 will almost certainly be outweighed by the difference in the development packages, features, and peripherals.  But I still think it is worth the time to explore all the little things that don't get marketed, which actually do have a huge impact on low-power RTOS functionality.  These will be in the official review, coming sometime in May or June I would guess.
  24. Like
    jpnorair got a reaction from tripwire in A new MSP430 coming [MSP432 ARM]   
    The [extremely sophisticated] benchmarks I have will port easily to MSP432 and STM32L4.  Atmel will be later in the year, but I have low hopes for Atmel, and I might not bother.
     
    Warning: Rant ahead.
     
    Anyway, Atmel uses more BS in their datasheet and marketing than TI does, and TI uses *slightly* more than ST.  
    Atmel's marketing numbers are unrealistic, best case figures where all the peripherals are off, the integral DC-DC is running, the chip is running at 12 MHz only, and it is running specially crafted code from a small region of SRAM.  Practically, it does 100uA/MHz.  Look at the datasheet, it's all there, albeit somewhat hidden.  Moreover, it's CM0+, so you really should multiply all figures by 66% to compare to CM4: 100 --> 166. TI's numbers are more honest.  A benchmark library is running from FLASH, the clock is 48 MHz, peripherals are mostly on, but the DC-DC is running with input 3.0V.  TI provides a great amount of information about what the power figures are when running with LDO, and they are still quite good (~160uA/MHz). ST is running Dhrystone benchmarks with all the peripherals going, clock at 80 MHz, code from flash, 128 KB of SRAM active, and there is no DC-DC on the device, so it's just LDO.  112 uA/MHz.  I have to guess they have implemented a mixed-size process with the core at 65nm, because they are a "quantum" ahead of the TI and Atmel offerings. I do wireless IoT, at "low" frequencies (sub 1-GHz), and with low power.  I tend to shun DC-DC converters because they kick up a lot of noise that does affect my radios (I've measured, it can be seriously bad).  It takes a lot of design time to cut-down the noise of DC-DC converters, and it's not always possible (if you can control the switching frequency in software, it's a whole lot better though).  Moreover, the input voltage limit of MSP432 and SAML21 is 3.7 and 3.6V respectively, so IT'S USELESS. It needs to be 4.3V at least, so we can use Li-Ion.  Otherwise, I need to make my own step-down from the Li-Ion, and I'm inclined to use my own DC-DC, with a totally vetted analog design and low EMI, that feeds 1.8V to my system.
     
    I really don't need the M4F, but the truth is that I really do prefer the M3/M4 to the M0+.  M0 is a "red-haired step child."  It doesn't fit into a good standard (it's ARMv6+ vs the gold-standard ARMv7).  Compilers are worse.  It only has 8 registers that can be batched to the stack, whereas all the regs in M3/M4 can be (so threading sucks on M0).  It has a crippled NVIC, and on and on.  Basically, it's a low cost hack.  For low power, you actually do better with M3/M4.  For performance, M3/M4 also.
     
    M4F gives the MSP432 (and STM32L4) a really good entry point into sophisticated signal processing apps.  Hell yeah, we're going to do FFT on these things.  I think it is ridiculously cool to do FFT -- fast -- with 4-8 mA.  Not everyone here realizes the kinds of possibilities this opens-up.  You might not think you need FFT, but the best Reed-Solomon algorithm uses FFT, and RS is awesome for error correction and data integrity in lossy IoT networks.  So it's a completely legit thing to talk about.
     
    I want to reiterate that I only hate Atmel because they make me hate them by being disingenuous.  If they changed their ways, I would have no issue.  I have "no dog in this fight."
     
    Anyway, I can tell you now that any performance difference between MSP432P4 and STM32L4 will almost certainly be outweighed by the difference in the development packages, features, and peripherals.  But I still think it is worth the time to explore all the little things that don't get marketed, which actually do have a huge impact on low-power RTOS functionality.  These will be in the official review, coming sometime in May or June I would guess.
  25. Like
    jpnorair got a reaction from zlalanne in A new MSP430 coming [MSP432 ARM]   
    The [extremely sophisticated] benchmarks I have will port easily to MSP432 and STM32L4.  Atmel will be later in the year, but I have low hopes for Atmel, and I might not bother.
     
    Warning: Rant ahead.
     
    Anyway, Atmel uses more BS in their datasheet and marketing than TI does, and TI uses *slightly* more than ST.  
    Atmel's marketing numbers are unrealistic, best case figures where all the peripherals are off, the integral DC-DC is running, the chip is running at 12 MHz only, and it is running specially crafted code from a small region of SRAM.  Practically, it does 100uA/MHz.  Look at the datasheet, it's all there, albeit somewhat hidden.  Moreover, it's CM0+, so you really should multiply all figures by 66% to compare to CM4: 100 --> 166. TI's numbers are more honest.  A benchmark library is running from FLASH, the clock is 48 MHz, peripherals are mostly on, but the DC-DC is running with input 3.0V.  TI provides a great amount of information about what the power figures are when running with LDO, and they are still quite good (~160uA/MHz). ST is running Dhrystone benchmarks with all the peripherals going, clock at 80 MHz, code from flash, 128 KB of SRAM active, and there is no DC-DC on the device, so it's just LDO.  112 uA/MHz.  I have to guess they have implemented a mixed-size process with the core at 65nm, because they are a "quantum" ahead of the TI and Atmel offerings. I do wireless IoT, at "low" frequencies (sub 1-GHz), and with low power.  I tend to shun DC-DC converters because they kick up a lot of noise that does affect my radios (I've measured, it can be seriously bad).  It takes a lot of design time to cut-down the noise of DC-DC converters, and it's not always possible (if you can control the switching frequency in software, it's a whole lot better though).  Moreover, the input voltage limit of MSP432 and SAML21 is 3.7 and 3.6V respectively, so IT'S USELESS. It needs to be 4.3V at least, so we can use Li-Ion.  Otherwise, I need to make my own step-down from the Li-Ion, and I'm inclined to use my own DC-DC, with a totally vetted analog design and low EMI, that feeds 1.8V to my system.
     
    I really don't need the M4F, but the truth is that I really do prefer the M3/M4 to the M0+.  M0 is a "red-haired step child."  It doesn't fit into a good standard (it's ARMv6+ vs the gold-standard ARMv7).  Compilers are worse.  It only has 8 registers that can be batched to the stack, whereas all the regs in M3/M4 can be (so threading sucks on M0).  It has a crippled NVIC, and on and on.  Basically, it's a low cost hack.  For low power, you actually do better with M3/M4.  For performance, M3/M4 also.
     
    M4F gives the MSP432 (and STM32L4) a really good entry point into sophisticated signal processing apps.  Hell yeah, we're going to do FFT on these things.  I think it is ridiculously cool to do FFT -- fast -- with 4-8 mA.  Not everyone here realizes the kinds of possibilities this opens-up.  You might not think you need FFT, but the best Reed-Solomon algorithm uses FFT, and RS is awesome for error correction and data integrity in lossy IoT networks.  So it's a completely legit thing to talk about.
     
    I want to reiterate that I only hate Atmel because they make me hate them by being disingenuous.  If they changed their ways, I would have no issue.  I have "no dog in this fight."
     
    Anyway, I can tell you now that any performance difference between MSP432P4 and STM32L4 will almost certainly be outweighed by the difference in the development packages, features, and peripherals.  But I still think it is worth the time to explore all the little things that don't get marketed, which actually do have a huge impact on low-power RTOS functionality.  These will be in the official review, coming sometime in May or June I would guess.
×
×
  • Create New...