Jump to content
43oh

jpnorair

Members
  • Content Count

    718
  • Joined

  • Last visited

  • Days Won

    18

Reputation Activity

  1. Like
    jpnorair reacted to timotet in I want to buy an awesome 3D Printer   
    This looks pretty neat too. Not much Z travel though.
     
    https://www.inventables.com/technologies/carvey
  2. Like
    jpnorair reacted to Jake in I want to buy an awesome 3D Printer   
    I had almost bought that Emco that was on Craig's list and do I Linux CNC retrofit on it. But I decided I would hold onto the money and get my VMC in one piece and running. It was like $1800 and I figured I could do the Linux CNC retrofit for about a grand using servo motors on three axis.
     
     
    http://www.okuma.com/genos-m560-v
     
    This is what I really want! Just gotta come up with $160k for it!
  3. Like
    jpnorair reacted to Jake in I want to buy an awesome 3D Printer   
    I have a friend with an Emco concept 55, it's pretty slick for a little machine. On the desktop machines other than that. I don't know....You may be able to find some of those emco (not enco) used, there was one of the manual models on craigslist here that can be easily converted to CNC as they are the same machine as the CNC less the servos and controls. my Bridgeport is the smallest in the shop. My VMC has a 15hp spindle on it.
  4. Like
    jpnorair reacted to Fred in I want to buy an awesome 3D Printer   
    SLA printers definitely have the edge on quality, but you're obviously restricted by the curable resins (which are expensive). I didn't know they did a flexible resin but it seems they do. I've got a standard FDM printer and whilst it's useful to some degree, I definitely use my CNC mill more. A mill gives you a much wider range of materials. Would one suit what you need to do better than a printer?
  5. Like
    jpnorair reacted to Jake in I want to buy an awesome 3D Printer   
    Depends on the elastomers. Some machine nicely, some will make you throw them across the shop. You have to learn the material and the tooling to cut that material. A few of the elastomers I have cut razor sharp polished HHS tooling had worked well, minimizing dwell time and making sure travel speeds are high enough that material is removed and heating minimized. I have done more on a manual mill than a CNC, with elastomers my Bridgeport only goes 2700 rpm and I wanted faster still. I need to get my VMC in one piece and going.
  6. 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.
  7. Like
    jpnorair reacted to timb in Pin Mux Utility v3 for OS X Now Available!   
    Hey everyone, I
  8. 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.
  9. Like
    jpnorair reacted to spirilis in Introducing CC1310, and discussing Energia support   
    @@jpnorair - FYI, I have been thinking about this a bit the past few days, and I think a good approach would be to try and implement the Wiring core using Arduino 1.6+ with their 3rd party hardware support infrastructure.  No Java coding required.
     
    As a side note, I have embarked this week on an unofficial port of the MSP430 to Arduino 1.6.1 using the new RedHat GCC (msp430-elf-gcc) compiler; this port is targeting the larger F5xxx/6xxx and FRxxxx series chips along with the larger of the G2xxx.  So this week I've got pretty cozy with creating and modifying the "platform.txt" and "boards.txt" files for 3rd party hardware support.
     
    This is the guide I've been following - https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification
     
    My current "platform.txt" looks like this at the moment:
    ~/Documents/Arduino/hardware/spirilis/msp430/platform.txt
    name=TI MSP430 Energia-Arduino msp430-elf port version=1.0.0 compiler.path=/opt/local/msp430-elf-gcc/bin/ compiler.c.cmd=msp430-elf-gcc compiler.c.flags=-c -g -Os -ffunction-sections -fdata-sections -Wall -fno-exceptions compiler.cpp.cmd=msp430-elf-g++ compiler.cpp.flags=-c -g -Os -ffunction-sections -fdata-sections -Wall -fno-exceptions -fno-rtti -fpermissive compiler.c.elf.cmd=msp430-elf-g++ compiler.c.elf.flags=-Os -Wl,--gc-sections -minrt compiler.ar.cmd=msp430-elf-ar compiler.ar.flags=rcs compiler.objcopy.cmd=msp430-elf-objcopy compiler.size.cmd=msp430-elf-size # Compile C files recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.c.flags} -mmcu={build.mcu} -DF_CPU_DEFAULT={build.f_cpu} -m{build.optlarge} {build.extra_flags} -DARDUINO={runtime.ide.version} -DENERGIA={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DMSP430_MEMORY_{build.optlarge} {includes} "{source_file}" -o "{object_file}" recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} -o "{build.path}/{build.project_name}.elf" -u main {object_files} "{build.path}/{archive_file}" "-L{build.path}" -T "{build.ldscript}" -lm {build.optlibs} # Compile C++ files recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} -mmcu={build.mcu} -DF_CPU_DEFAULT={build.f_cpu} -m{build.optlarge} {build.extra_flags} -DARDUINO={runtime.ide.version} -DENERGIA={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DMSP430_MEMORY_{build.optlarge} {includes} "{source_file}" -o "{object_file}" # Compile ASM files recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.c.flags} -mmcu={build.mcu} -DF_CPU_DEFAULT={build.f_cpu} -m{build.optlarge} {build.extra_flags} -DARDUINO={runtime.ide.version} -DENERGIA={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DMSP430_MEMORY_{build.optlarge} {includes} "{source_file}" -o "{object_file}" # Create AR archive recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} "{build.path}/{archive_file}" "{object_file}" # Find ELF code size recipe.objcopy.nodebug.pattern="{compiler.path}{compiler.objcopy.cmd}" -g "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.nodebug.elf" recipe.size.pattern="{compiler.path}{compiler.size.cmd}" -A "{build.path}/{build.project_name}.nodebug.elf" recipe.size.regex=Total\s+([0-9]+).* # Tools definition tools.mspdebug.cmd.path=/usr/local/bin/mspdebug tools.mspdebug.upload.params.verbose=-v tools.mspdebug.upload.params.quiet= tools.mspdebug.upload.pattern="{cmd.path}" {upload.verbose} {upload.protocol} "prog {build.path}/{build.project_name}.elf" tools.mspdebug.bootloader.pattern="{cmd.path}" --allow-fw-update tilib "md 0x1000" (I don't have a good name for my port so I'm calling it Energia-on-Arduino for now.)
     
    Boards.txt:
    # TI MSP430 - Energia-to-Arduino 1.6 port ############################################################## lpmsp430f5529.name=LaunchPad w/ msp430f5529 (16MHz / 16-bit ptr) lpmsp430f5529.upload.tool=mspdebug lpmsp430f5529.upload.protocol=tilib lpmsp430f5529.upload.maximum_size=48128 lpmsp430f5529.build.mcu=msp430f5529 lpmsp430f5529.build.f_cpu=16000000L lpmsp430f5529.build.core=msp430 lpmsp430f5529.build.variant=launchpad_f5529 lpmsp430f5529.build.ldscript=msp430f5529.ld lpmsp430f5529.build.extra_flags= lpmsp430f5529.build.optlarge=small lpmsp430f5529.build.optlibs= ############################################################## lpmsp430f5529_25.name=LaunchPad w/ msp430f5529 (25MHz / 16-bit ptr) lpmsp430f5529_25.upload.tool=mspdebug lpmsp430f5529_25.upload.protocol=tilib lpmsp430f5529_25.upload.maximum_size=48128 lpmsp430f5529_25.build.mcu=msp430f5529 lpmsp430f5529_25.build.f_cpu=25000000L lpmsp430f5529_25.build.core=msp430 lpmsp430f5529_25.build.variant=launchpad_f5529 lpmsp430f5529_25.build.ldscript=msp430f5529.ld lpmsp430f5529_25.build.extra_flags= lpmsp430f5529_25.build.optlarge=small lpmsp430f5529_25.build.optlibs= So with whatever tools TI provides, assuming they can be fully run from the CLI, this "platform.txt" layout should give you a place to start.  What dev boards/tools do you have in mind (and/or have already purchased)?  Curious what your plans are
  10. Like
    jpnorair reacted to spirilis in Introducing CC1310, and discussing Energia support   
    As a side note, I believe going this route (Arduino 3rd party HW support) is what the panStamp guys ended up doing.
  11. 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.  
  12. Like
    jpnorair got a reaction from bluehash 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.  
  13. Like
    jpnorair got a reaction from jazz 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.  
  14. Like
    jpnorair reacted to cubeberg in Updates and going forward   
    I've kind of felt that spreading the communities across multiple domains kind of dilutes the discussion I'd almost love to see a TIMicros.com or something to bring it all together.  
     
    The community has been pretty quiet lately - especially in comparison to when I started on the site a few years ago.  I'd love to see what we can do to make it as active again.  The POTMs were great - but the last few didn't get much participation.  Maybe we should start a thread on what we can do as a community (not just @bluehash) to keep things going?
  15. Like
    jpnorair got a reaction from zeke in A new MSP430 coming [MSP432 ARM]   
    People in the industry have been dropping me hints for a while that an ARM M0+ with MSP peripherals and clock system is on the way.  A few years ago, I lobbied pretty hard for this, so I guess it's nice that things are coming around.  
     
    Assuming that the resulting device gets Energia support, that would be great.  The Atmel ARM CM parts aren't worth using in low power designs (frankly I think they are weak in most respects).  The STM32L parts are great, but I would need to port Arduino to them and do all the requisite community marketing: no thanks.  I have a pretty nice firmware and IoT platform waiting in the wings that does all the low-power optimizations for you transparently (as long as you're running sketches).  So I have my fingers crossed.
  16. Like
    jpnorair got a reaction from spirilis in A new MSP430 coming [MSP432 ARM]   
    People in the industry have been dropping me hints for a while that an ARM M0+ with MSP peripherals and clock system is on the way.  A few years ago, I lobbied pretty hard for this, so I guess it's nice that things are coming around.  
     
    Assuming that the resulting device gets Energia support, that would be great.  The Atmel ARM CM parts aren't worth using in low power designs (frankly I think they are weak in most respects).  The STM32L parts are great, but I would need to port Arduino to them and do all the requisite community marketing: no thanks.  I have a pretty nice firmware and IoT platform waiting in the wings that does all the low-power optimizations for you transparently (as long as you're running sketches).  So I have my fingers crossed.
  17. Like
    jpnorair got a reaction from tripwire in A new MSP430 coming [MSP432 ARM]   
    People in the industry have been dropping me hints for a while that an ARM M0+ with MSP peripherals and clock system is on the way.  A few years ago, I lobbied pretty hard for this, so I guess it's nice that things are coming around.  
     
    Assuming that the resulting device gets Energia support, that would be great.  The Atmel ARM CM parts aren't worth using in low power designs (frankly I think they are weak in most respects).  The STM32L parts are great, but I would need to port Arduino to them and do all the requisite community marketing: no thanks.  I have a pretty nice firmware and IoT platform waiting in the wings that does all the low-power optimizations for you transparently (as long as you're running sketches).  So I have my fingers crossed.
  18. Like
    jpnorair got a reaction from cubeberg in A new MSP430 coming [MSP432 ARM]   
    People in the industry have been dropping me hints for a while that an ARM M0+ with MSP peripherals and clock system is on the way.  A few years ago, I lobbied pretty hard for this, so I guess it's nice that things are coming around.  
     
    Assuming that the resulting device gets Energia support, that would be great.  The Atmel ARM CM parts aren't worth using in low power designs (frankly I think they are weak in most respects).  The STM32L parts are great, but I would need to port Arduino to them and do all the requisite community marketing: no thanks.  I have a pretty nice firmware and IoT platform waiting in the wings that does all the low-power optimizations for you transparently (as long as you're running sketches).  So I have my fingers crossed.
  19. Like
    jpnorair got a reaction from LariSan in Analog Discovery   
    Several years ago I bought a PC logic analyzer from Intronix (http://www.pctestinstruments.com).  It is really quite good, but this Analog Discovery product looks much, much better.  Seems like a must-buy.
  20. Like
    jpnorair reacted to RobG in Analog Discovery   
    If you ever wanted to get logic analyzer, you should take a look at Digilent's Analog Discovery.
     
    Analog Discovery is a multifunction device developed by Digilent in cooperation with Analog Devices (AD is filled with chips from AD.)
    AD features analog and digital inputs and outputs, and can be used as an oscilloscope, function generator, logic analyzer, pattern generator, virtual I/O, voltmeter, spectrum analyzer, network analyzer, and even power supply. And the best part, it's affordable, especially for US students.
     
    I got my AD several days ago and let me tell you, AD is a true Swiss Army knife for geeks.
    To show you how useful AD can be, I used it to test new version of my audio analyzer BoosterPack.
    For my tests, I am using oscilloscope, logic analyzer, and waveform generator instruments (AD comes with software called WaveForms, which is a suite of virtual instruments.)
    Waveform generator provides 2 audio signals (via 3.5mm stereo jack) to BP's audio input. A simple tone or a sweep can be generated, so many options.
    Oscilloscope is connected via (optional) BNC Adapter Board and a probe to audio switch's output, so I can see which signal is fed to the EQ chip.
    Finally, logic analyzer is connected to LP's SPI output and displays sampled data.
     


     
    Analog Discovery's pinout

  21. Like
    jpnorair reacted to smarpl in Bitlash   
    I succeed porting Bitlash to MSP430 microcontrollers. See my blog post Bitlash for MSP430
  22. Like
    jpnorair got a reaction from RFEE in MSP430FR vs M0+ which is better for battery-less operation   
    I feel bad about saying this on an MSP430 site, but really, really, really... the MSP430 is not getting chosen for new designs in IoT stuff.  If you are a TI dedicate, this might be OK, since there is a little bit of leaked information about CC13xx on the internet... you can probably guess what it is (good night CC430).  And no, I do not have an active NDA with TI.  I've said for a long time that TI should upgrade MSP to CM0+ and just keep the same clocking and peripherals.
     
    A good Cortex M0+ like the STM32L0, EFM32-Zero, or the equivalent Freescale part (I am not familiar with their naming, but I know they are doing a lot of ARM CM devices) will be able to run the same code (let's say, C) a lot faster than MSP430 will.  For the most part, the CM0+ devices have roughly similar figures for current usage at 16 MHz, and this figure is about the same as the MSP430F5/CC430 at 20 MHz.  It's somewhere in the area of 3.5mA.  However, the CM0+ at 16 MHz is still more than twice as fast as the MSP430F5 at 20 MHz.  CM3 is almost exactly three times as fast, in my personal measurements with OpenTag.
     
    In terms of sleep current, this is important too.  In ARM language, your main sleep mode will be DEEPSLEEP with all buses powered-down.  STM32 calls this "STOP."  EFM32 has some LPx nomenclature.  In any case, on these devices, STOP current (or equivalent LPx) is in the 0.4-0.7 uA range, and you can go from STOP to full speed run in about 4us.  That's pretty damn impressive.  The light-sleep that you can use during certain, blocking operations is in the 600 - 800 uA range.  That is still impressive.  Additionally, one of the things I do with STM32 is have OpenTag (an RTOS) automatically determine the optimal run speed.  Tasks can also request a speed.  The most efficient run speed of the STM32 is 4.2 MHz, but for doing protocol processing you definitely want to jump to 16 MHz in order to turn-around the packet faster.
     
    Other benefits:
    - ARM CM DMA is a lot better than the MSP430 DMA.  If you are smart, you can write fast memcpy and SPI routines that also go into light sleep.  This adds up.
    - ARM CM has a nested-vector interrupt controller, which can be nice for working with multiple I/O.  This is most prevalent on CM3, 4, 7.
    - ARM CM has a hardware-based dual stack configuration, which makes running a lightweight RTOS much more efficient and reliable than with MSP430.
     
    IMO, the best CM3 device is the EFM32 Gecko, but the best CM0+ device is the STM32L0.  It beats or matches the zero gecko in most respects, it has HW CRC, HW AES, and also a bunch of special low-power features.  It also has onchip EEPROM, which is really important if you want to store non-volatile data, even if it is just a mapping table to a flash wear leveling system.  It is also priced much better than EFM32.  Nonetheless, it might be worth it to wait for more info on CC13xx.
     
    RF Element:
    The biggest power user is going to be the RF transmitter.  In addition, you need to worry about the RF startup time.  The SPIRIT1 from ST has an onchip SMPS, so it has the lowest TX current by far.  It also has a very fast fractional-N PLL and crystal driver.  However, I think it is not so fast from a truly cold start.  You will need to seriously inspect the startup-time for all the transmitters you are considering, in addition to the transmission current.  I still bet SPIRIT1 is the best choice.
  23. Like
    jpnorair reacted to eck in MSP430FR vs M0+ which is better for battery-less operation   
    @@jpnorair, I see the Zero Gecko parts at Mouser even in single quantities for just about a dollar upwards. I haven't seen the STM32L0 anywhere that cheap yet.
  24. Like
    jpnorair got a reaction from igor in STM32L0 USB Interface   
    Proto PCBs are sent to OSHpark.
     
    Pluto is basically a Teensy 2.0 with Cortex M0+.  I tried to keep the I/O as similar to the Teensy as possible, although it is not quite identical.  I also added some new things:
    A load-switch that allows a coin cell (or whatever) to operate as the power source, automatically, when it is not plugged-in. A raw Vdd port for attaching a super cap.   Pink LED.  Go pink.  
    Charon is a tiny USB-dongle type thing.  It is extremely small, the USB plug is the biggest part of the assembly.  There is a 10 x 12.7mm header on one end that exposes SWD and a com-bus.  SPI, UART, or I2C can be used (but only one I/F at any one time).  The firmware will do autodetection, and there's an extra pin for forcing the bus to reset.
     
    Both will use virtually identical firmware, which is what will provide the ultra-low-power features in addition to the multi-sketch (multi-thread) features.  When sketches call delay() or any other sort of blocking call, the underlying kernel will transparently do the multitasking and most opportunistic low power sleeping (This stuff I already have done).
     
    The default firmware also can do autodetection of control data (binary, packetized) vs. TTY data.  Control data can be sent according to a spec, but the client software "otter" is the best tool for working with it.  The "otter" interface is a bit like the Bus Pirate interface.  All firmware and software is and will be open source.
  25. Like
    jpnorair got a reaction from abecedarian in imp.guru Droplet and 915MHz Long Range Radio to WiFi   
    This is wrong.  I won't get started about HAM and ARRL, and how they destroy innovation in the modern era.  But at least you can figure out my opinion.
     
    Lower wavelengths represent smaller particles via the wave-particle duality, more smaller particles can be produced with a given energy level, and therefore lower wavelengths propagate better through any medium.
     
    What I assume this question and answer refer-to is practice rather than theory.  In a concrete bunker, VHF will propagate through the bunker much better than UHF.  In a building with windows and doorways, there are situations where the diffractive losses of a longer wave signal will result in greater attenuation than the bouncing of shorter wave signals.  This can be very experimental and it depends a lot on physical geometry, construction materials, etc.
     
    UHF is basically 300-1000 MHz.  Planet Earth and humans are scaled geometrically such than UHF often propagates well in "real-world" environments.  But does it really propagate better than a 30 MHz signal?  That's a stretch.
×
×
  • Create New...