spirilis

Members
  • Content count

    3,383
  • Joined

  • Last visited

  • Days Won

    144

Everything posted by spirilis

  1. Here's a boosterpack breaking out the FTDI FT230X, a simple USB-UART adapter chip (similar to the FT232RL but with less crap, also less cost). Should allow custom UART speeds and good driver support to have your MSP430 talk to any computer. Compatible with 20-pin or 40-pin XL LaunchPads, for 20-pin LP's just ignore the 21-30/31-40 headers. Uses a Mini-B USB port. Includes 250mA Voltage Regulator for powering the project completely off this board's USB connection. The RTS, CTS, CBUS0-3 lines are all broken out to a header and breakout pads are there for all 40 pins of an XL-size LaunchPad. Breakout pads for RX, TX are there plus jumpers to connect/disconnect the UART lines--plus these can be installed transverse like the v1.5 launchpad, enabling Software UART pinout like the pre-1.5 launchpad chips instead. TX, RX LEDs attached to CBUS1 & 2 by default. All references to "TX" and "RX" are from the standpoint of the MCU, not the FTDI chip FYI. So the "TX" pad goes to the RXD pin on the FT230X, the "RX" pad goes to the TXD pin. Likewise CBUS2 defaults to TXLED# but it routes to the "RX" LED, vice versa for TX. Datasheet for the FT230X: http://www.ftdichip....s/DS_FT230X.pdf Bill of Materials: USB port - Wurth 651005136521 Mouser link R1, R2 - 1K 0603 SMD resistors R3, R4 - 22R 0603 SMD resistors TX, RX LED - 0603 SMD LEDs C3, C4, C5, C6 - 0603 0.1uF SMD ceramic capacitors C1 - 1206 4.7uF SMD ceramic capacitor C2 - 1206 10uF SMD ceramic capacitor C7, C8 - 47pF 0603 SMD ceramic capacitors RG1 - TI LDO voltage regulator, TPS77301 U3 - FTDI FT230XS (SSOP-16) F1 - nanoSMD fuse, PTC resettable 0.5A 13.2V - Mouser link First, pics (OSHpark mockup): Top- Bottom- Second, schematic: DipTrace Schematic - FTDI_FT230X_BoosterPak_draft2.pdf And last but not least, gerbers: OSHpark gerbers: OSH_FT230X_BPak.zip Seeed/ITeadStudio gerbers: Seeed_FT230X_BPak_5x5.zip This is a 5cmx5cm board (49x49mm) FYI. I am going to have a short run of these made, probably as an order-stuffer with my next Seeed order, then assemble them for the 43oh store.
  2. Hi- quick question, do you have any software you like for designing filters? (e.g. FIR or IIR coefficients) I may be dabbling into MSP432 DSP work soon...
  3. Mind you the 20km (actually 30km now?) was tested at the top of two buildings in Norway with clear line-of-sight between them.... but 0.3km still sounds bad to me. Wish I had some time to keep playing with these, as I want to follow up on a lot of this stuff.
  4. I haven't messed with energia in a while but I am pretty sure SoftwareSerial doesn't work on that chip... it was meant for the really small MSP430G2452 and similar which didn't have a hardware UART. Arduino handles softwareserial better. Maybe someone else has a better softwareserial implementation around here, I don't know though.
  5. Bringing back threads from the dead! Can you provide more context here? The GPS shouldn't use the same UART as another device (camera? what kind?) but otherwise yeah, Serial1 should work...
  6. I see you posted an E2E thread for this, that was my only suggestion (interesting to see what TI says about this) https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/601521
  7. I have a library I've been working on for the past month or so to give Energia and Arduino users intuitive access to the TI RF430CL330H series of NFC transponders. https://github.com/spirilis/RF430CL This library is composed of two logical sections: 1. The RF430 class which defines and manages a physical RF430CL330H NFC transponder over I2C using the "Wire" library 2. The NDEF class system which allows users to conceptually define and manage NFC NDEF data records, importing & exporting them The NDEF class and subclasses (so far NDEF_URI, NDEF_TXT being the only RTD-specific subclasses implemented) maintain buffers for storing the NDEF "Type" field (a character string), "ID" field (optional, character string) and the actual payload. The class is designed to be flexible so the user has to provide the buffer space (and maximum buffer size) for storing the Type, ID and Payload information, but some of the subclasses (and soon the base class) support defining those buffers as immutable data types (e.g. const uint8_t [] or const char [] arrays) for export usage only. For importing & exporting, the NDEF class and all subclasses have two methods: .sendTo(Stream &, boolean Message_Begin=true, boolean Message_End=true) .import(Stream &) sendTo writes byte-for-byte the physical NDEF record associated with that object's current state, returning an integer equal to the exact length (in bytes) of the NDEF binary record. The two boolean arguments allow the user to customize the setting of the MB and ME bits in the NDEF header byte to support having multiple NDEF records in a single NFC memory segment. If those boolean arguments are omitted, they default to "true" so the NDEF record will be written with both MB and ME bits set (typical usage for an NFC transponder housing only a single NDEF record). import uses the read() and readBytes() feature of the Stream object supplied to read, byte for byte, and analyze (rejecting by returning -1 if read errors or for RTD-specific sub-classes, if the header or structure of the record does not match the appropriate NDEF RTD type) and import the data. Buffers must be defined for the NDEF object using .setPayloadBuffer(<buf>, <maxlen>) and for the base (generic) NDEF class, .setTypeBuffer() and optionally .setIDBuffer() so the import function has a place to store the TYPE and (optionally, if present, i.e. the "ID" bit is set in the NDEF header byte) ID strings. The RF430 class (which references the hardware) has an internal counter and I/O system which implements Arduino's "Stream" interface, so it's a valid target for the NDEF sendTo & import functions. There are functions for changing/resetting the internal "pointer" as well as informing the RF430 library how much NDEF data is there (this must be set, or else any NFC master going to read or write to the transponder will error). Several examples are provided illustrating the use of the RF430 and NDEF classes and typical application program flow. IRQ support is there, with the ability to detect whether an NFC master (e.g. cellphone) has read from the RF430CL330H recently, or has written a new record or series of records to the RF430CL330H's SRAM. There is still more work to be done to enable simpler and better-managed generic NFC importers, and I would like to make an NDEF subclass that eases the use of custom/externally-defined RTD types. As of now, this does not support the TRF7970A in any way. In theory, I could support it in the future with the NDEF class infrastructure provided here. The RF430CL330H is a whole lot simpler/easier to understand IMO. I have been testing this with the F5529LP and DLP-RF430BP boosterpack. Here's a zip of the current codebase (from git as of 2/26/2015) - RF430CL_02262015.zip And here's one of the examples, illustrating how to write "Hello World" to the RF430CL330H and use Energia's Low-Power-Mode support (suspend() aka LPM4) to put the host MCU in deep sleep, waking up only when the RF430 sees an NFC master read or write to it: /* HelloWorld - NFC edition * Written for the TI RF430CL330H with Energia * * Showcases Low-Power Sleep modes in Energia and IRQ-driven wakeup of * the MCU based on RF430CL330H IRQs. * * 2/25/2015 Eric Brundick */ #include <Wire.h> #include <RF430CL.h> #include <NDEF.h> #include <NDEF_TXT.h> #define RF430CL330H_BOOSTERPACK_RESET_PIN 8 #define RF430CL330H_BOOSTERPACK_IRQ_PIN 12 RF430 nfc(RF430CL330H_BOOSTERPACK_RESET_PIN, RF430CL330H_BOOSTERPACK_IRQ_PIN); void setup() { Serial.begin(115200); delay(1000); Serial.println("Hello World - NFC edition!"); Serial.println("Here we will post the text \"Hello World\" to the RF430CL330H."); Serial.println("Initializing I2C and RF430CL330H-"); Wire.begin(); // Initialize I2C subsystem nfc.begin(); // Format RF430CL330H, prepare for data // Register interrupt to wake MCU when RF430CL330H INTO (IRQ) line triggers attachInterrupt(RF430CL330H_BOOSTERPACK_IRQ_PIN, wake_up, FALLING); Serial.println("Creating NFC NDEF_TXT object-"); NDEF_TXT helloWorld("en", "Hello World"); // English Serial.println("Posting to RF430CL330H-"); size_t ndef_size; ndef_size = helloWorld.sendTo(nfc); // Write NDEF data to NFC device memory nfc.setDataLength(ndef_size); // Inform NFC device memory how much data is there Serial.println("Activating RF430CL330H RF link-"); nfc.enable(); // Now we're live! } void loop() { if (nfc.loop()) { if (nfc.wasRead()) { Serial.println("Something has read the NFC device!"); } if (nfc.available()) { Serial.println("Something has re-written the NFC device!"); nfc.flush(); } nfc.enable(); // If nfc.loop() returns true, it will have disabled the RF link as a side-effect. } Serial.println("<low power sleep>"); Serial.flush(); // wait for unsent UART data to flush out before going into low-power sleep suspend(); // Enter indefinite sleep (LPM4 on MSP430, DEEPSLEEP on ARM) Serial.println("<wake up>"); } void wake_up() { wakeup(); // Signal Energia to wake the MCU upon IRQ exit }
  8. I gotcha... I haven't personally used Energia with this chip. I do know that in CCS, it's not good enough to set a #define somewhere for that, I have to make it a compiler directive using the project properties compiler predefine option. So it's highly probable that Energia's not building it with CCFG_FORCE_VDDR_HH=1 correctly.
  9. For 14dBm, EasyLink might tell you 12dBm but only because the RF register setting for 12dBm is identical to the setting for 14dBm, the only difference is the CCFG_FORCE_VDDR_HH=1 which boosts the power to the RF stage internally a bit. Likewise, if you set it to 0dBm with CCFG_FORCE_VDDR_HH=1, your actual transmit power should (theoretically) be a little higher. EasyLink's way of determining this won't tell you though.
  10. The typical use-case for the CC1350 (as opposed to the CC1310, or CC2640/2650) is as a local Sub-GHz to BLE gateway (helping to get sub-GHz information to a nearby cellphone). So the idea here would be to have a CC1350 radio gateway in the vicinity of your cellphone, and a CC1310 (or 1350, but the 2.4GHz path wouldn't be used) inside the greenhouse transmitting the information long-haul over sub-GHz. Alternately, if antennas permit, you could scrap the whole thing and use the CC2650STK with an external antenna or something and hope your cellphone can receive BLE at that distance. The one thing I'm leery of is the CC1350's support for two frequency bands, because they appear to share the same radio pins and so the radio hardware inside the chip is probably optimized for one frequency band but not the other (or it's a compromise for both).
  11. Allocate an NDEF_TXT object first instead of just composing your "Value" variable and trying to send it directly over the NFC: NDEF_TXT t("es", Value.c_str()); int ndef_size = t.sendTo(nfc); nfc.setDataLength(ndef_size) Note the first string in the NDEF_TXT constructor is the language code describing the language used for the text.
  12. Hi folks... So I'm a little new to Energia, but since I wrote a library for the nRF24L01+ digital transceivers for native C-based apps I figured it'd be a great idea to port this to Energia. I'm rewriting it from scratch, trying to make it simpler & feel more like a native C++ energia lib. edit: This has been written and the latest version is up on Github. Github project- https://github.com/spirilis/Enrf24 Latest version + comments- http://forum.43oh.com/topic/3237-energia-library-nordic-nrf24l01-library/?p=48805 To that end, I'd like some feedback on the API choices I've made. I want to know what some of you guys think should go in here. For now, here's an example of my "Nrf24.h" class definition (public's only, I haven't drafted the private's and probably won't until I really start writing the code): class Nrf24 { public: Nrf24(uint8_t cePin, uint8_t csnPin, uint8_t irqPin); void begin(); // Defaults used void begin(uint32_t datarate); // Specify bitrate void begin(uint32_t datarate, uint8_t channel); // Specify bitrate & channel void end(); // Shut it off, clear the library's state // I/O boolean available(); // Check if incoming data is ready to be read boolean write(void *buf, uint8_t len); /* Send packet, return true/false for autoACK * (true always if autoACK disabled or 250Kbps rate used) */ uint8_t read(void *inbuf); // Read contents of RX buffer, return length uint8_t read(void *inbuf, uint8_t maxlen); // Read contents of RX buffer up to 'maxlen' bytes, return final length. void autoAck(boolean onoff); // Enable/disable auto-acknowledgements (enabled by default) // Power-state related stuff- void deepsleep(); // Enter POWERDOWN mode, ~0.9uA power consumption void enableRX(); // Enter PRX mode (~14mA) void disableRX(); /* Disable PRX mode (PRIM_RX bit in CONFIG register) * Note this won't necessarily push the transceiver into deep sleep, but rather * an idle standby mode where its internal oscillators are ready & running but * the RF transceiver PLL is disabled. ~26uA power consumption. */ // Custom tweaks to RF parameters, packet parameters void setChannel(uint8_t channel); void setTXpower(int8_t dBm); // Only a few values supported by this (0, -6, -12, -18 dBm) void setSpeed(uint32_t rfspeed); void setCRC(boolean onoff, boolean crc16bit); /* Enable/disable CRC usage inside nRF24's hardware packet engine, * specify 8 or 16-bit CRC. */ // Protocol addressing -- receive, transmit addresses void setAddressLength(uint8_t len); // Valid parameters = 3, 4 or 5. Defaults to 5. void setRXaddress(uint8_t *rxaddr); // 3-5 byte RX address loaded into pipe#1 void setTXaddress(uint8_t *txaddr); // 3-5 byte TX address loaded into TXaddr register // Miscellaneous feature boolean rfSignalDetected(); /* Read RPD register to determine if transceiver has presently detected an RF signal * of -64dBm or greater. Only works in PRX (enableRX()) mode. */ } What do you think? General usage would be to instantiate an Nrf24 object in the global, use begin() to start it and specify some custom params (data rate, or data rate & channel), then the transceiver is just sitting there idle until you either transmit (with setTXaddress() + write()) or enable RX mode with setRXaddress() + enableRX() and poll the available() function periodically. One thing I haven't worked out yet is how to implement the IRQ feature with Energia. The nRF24 has an IRQ pin that is best hooked up for optimal function. Can the library just use attachInterrupt() on the irqPin value that the user passes up top?
  13. Aand. .. Arrow's still doing free shipping, no code needed. $50 minimum for international orders. I'm guessing they're pushing hard to gain a presence in the small-order online commerce arena, but that's good for us! (for now, while shipping is free ) For the most part their online ordering process has improved since last August when I found much to gripe about, and they gave me a contact who manages the web development and I've written him once or twice to report issues I've seen.
  14. Not sure what the JTAG tools run for those, although I think they have a serial bootloader of sorts (the big brother RX series do anyway), and the arch is a modern evolution of the Z80 (taken from NEC when NEC sold their semiconductor division to Renesas) from what I gather. Not important for a smaller chip but, for larger RL78/G14's and such with >64KB flash and/or SRAM, the architecture still uses a 16-bit address bus but with special paging that requires the compiler use "trampoline" code to switch pages as needed (should be transparent to the developer though but adds latency to function calls)..... but, for a super simple program on a small chip, you'll never encounter this. edit: For JTAG, the Renesas E1/E20/etc series of emulators are specified, the cheapest variety is the E2 emulator Lite which is ~$65ish.
  15. Well, I am not sure about the interrupt latency (not that familiar with the arch), and the price is more like $1.50ish... but Renesas RL78/G13 is close: https://www.renesas.com/en-us/products/microcontrollers-microprocessors/rl78/rl78g1x/rl78g13.html https://products.avnet.com/shop/en/ProductDisplay?storeId=715839035&catalogId=10001&langId=-1&productId=3074457345625366633 OK, going down a bit, RL78/G12 has a 24MHz part that's <$1: https://www.renesas.com/en-us/products/microcontrollers-microprocessors/rl78/rl78g1x/rl78g12.html?status=No%3B&pin_count=20%3A20%3B# https://products.avnet.com/shop/ProductDisplay?catalogId=10001&langId=-1&storeId=715839035&productId=3074457345625120989&categoryId=&fromPage=autoSuggest IIRC the compiler is free, or at least there is a GCC port, and Renesas e2studio is a free Eclipse-based IDE.
  16. Happy new year!
  17. Hasn't been tested to rigorous standards demanded by production use cases. Plus TI has to state that to avoid being sued if bad things happened that could be traced back to bugs in Energia. (Not an official explanation)
  18. I thought Energia MT implicitly supported creating multiple tasks by having additional source files with different variations of the setup() and loop() functions e.g. setupRadio() and loopRadio() or similar?
  19. I'm a little embarrassed to admit, but, I had no idea the Linux 'sleep' command could take a decimal point..... always thought it had to use integers. Turns out it takes suffixes for 's' (seconds, the default), 'm' (minutes), 'h' for hours and 'd' for days too! DESCRIPTION Pause for NUMBER seconds. SUFFIX may be 's' for seconds (the default), 'm' for minutes, 'h' for hours or 'd' for days. Unlike most implementa? tions that require NUMBER be an integer, here NUMBER may be an arbitrary floating point number. Given two or more arguments, pause for the amount of time specified by the sum of their values.
  20. Nope magnification visor w/ extra loupe I can swing down. I think viewing in stereo helps.
  21. Regarding making your own PCB with RF, one nice thing about the TI parts is the TI reference designs, I've used their 2-layer (0.8mm thick) ref design to build a few CC1310 boards of my own, and they work great but the RF passives are all 0402 and require a stencil for solder (OSHStencils stainless works great for this). 0402 is a bear and the absolute lower limit I will go. That said, one of TI's partners made a module for the CC2650 with LGA pads underneath IIRC. That makes the chip far more accessible. Trey German formerly from TI started a small company (Polymorphic Labs) building tiny gadgets based on that module. The CC2650 "BoosterPack" package includes a sample or 2 of that module. But of course all of that is probably over your budget
  22. Well whatever you use, 2.4GHz is best due to PCB antenna size. It is a shame the CC26xx series is too expensive since its high sensitivity would help make the distance even with sketchy small PCB antennas. Also for nRF stuff, I wouldn't bet on those actually making 10m at 2Mbps, but it should at 250Kbps. The issue is the human body and how it may reflect/refract RF as the wearer moves around.
  23. Arrow's still doing free shipping now, all orders USA and $50+ International. Bought a few more components (10x HDC1080, 10x TPS61221 for some CC1310 sensor nodes) to stock the bins.
  24. Without having any way of seeing your breadboard adapter socket soldering job and where the passives are, my first assumption is you probably did something wrong with the chip's layout; FYI this isn't a chip you can casually "solder to an adapter" and expect it to work. It has several passives including an inductor, multiple values of decoupling capacitors, a 24MHz XTAL without load caps (load caps are internal) along with a 32.768KHz XTAL with load caps that are expected (earlier revisions of the CC1310 chip couldn't run without the 32.768KHz XTAL). I've been successful in rolling my own boards by designing them from scratch but closely following the layout decisions demonstrated by TI's own reference designs.
  25. I personally won't touch anything other than the F128 model. I think it was a mistake for TI to produce them (especially the CC1310F32, like, wtf?)... with the RTOS being an integral part of the solution.