Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by chicken

  1. The issue is the relatively high internal resistance of the CR2032. The green line in the graph shows 20 Ohms for a fresh battery. At 20mA that's a voltage drop of 0.4V, which is manageable until resistance starts increasing towards the end. At 100mA that's a 2V drop, i.e. you won't go anywhere even with a full battery.
  2. Grounds are often connected accidentally, e.g. when both devices are powered from the same USB hub. But to avoid any problems, it's better to explicitly make the connection. Looking at your picture, I wonder if there's another MCU in that device that is connected to the MCP3911. If so, it will fight the MSP430 for control over SPI and lead to unexpected results.
  3. PS: You may want to start with a basic tutorial on timer interrupts. E.g. https://www.embeddedrelated.com/showarticle/182.php
  4. Welcome to the forum. RST and TEST are the connections to program and debug your MCU. If you haven't already, get a MSP430FET or a newer MSP430 LaunchPad (e.g. MSP430F5529LP). This is required to load your application into the MCU. Also see http://43oh.com/2011/11/tutorial-to-use-your-launchpad-as-a-programmer/ There can only be one interrupt service routine (ISR) for a given interrupt vector (e.g. TIMER0_D0_VECTOR in your code). And I don't think you can declare an ISR within another function. Move the ISR to the end of your code, outside of main. If the ISR needs to do different thin
  5. You will need to connect with DGND / GNDB. GND is the reference point to decide whether a signal is high or low. In electronics, connected GND is almost always required/assumed with only a few exceptions. Did you also check SS with the oscilloscope? Typically, SPI does not require pull-ups/downs. Unless explicitly mentioned in the datasheet of the MCP3911 or related evaluation boards, you probably don't need them.
  6. You may want to research and/or test if a CR2032 actually can deliver that current and theoretical capacity at that load. The datasheets don't specify a max current, but the capacity is specified at sub mA constant draw, and the graphs usually only go up to 1 or 2mA.
  7. What LaunchPad and what version of Energia are you using? Looking at MSP430F5529 as an example, SS/SCK/MISO/MOSI are on pins 33/34/14/15 for SPI(0) and 8/7/9/10 for SPI(1).
  8. Kate Gregory's point wasn't that you should stop using C. The talk was about better approaches to teach people C++ that don't know C and may even be new to programming. For that audience, starting with higher level concepts rather than pointers and char arrays makes a lot of sense. Getting a const char* out of a string should be straight forward. In the days of classes (when I was doing large scale C++ projects), the string class usually had an operator that transparently took care of the conversion. Not sure if STL has the same (I think so) or whether you explicitly have to use c_str() me
  9. @@StrangerM just tried with a MSP430F5529 LaunchPad and it works for me. I tried both ways entering the bootloader, either pressing the BSL button when plugging in or the B command in the debug menu. I can see two potential issues: 1) Make sure your firmware file is not corrupted. Some browsers seem to save HTML code instead of plain text when downloading a .txt from Github. I just uploaded them to Github as ZIP file to avoid that issue. 2) On my LaunchPad, only the GND, 5V and 3.3V jumpers are in. The other jumpers on the debug connection are empty. Regards, Adrian
  10. @@StrangerM I will have to check that tonight. I will keep you posted.
  11. Re BSL: I plan to use the Python libraries myself to let users upgrade the firmware on my AIS Receiver HAT for the Raspberry Pi. At least when trying to combine it with UART BSL compiled from source code (I can't use the built in BSL due to retarded pin assignment) the Python library turned out to be very buggy, to a level where I wonder if it was ever working for UART. If I remember correctly, the bug with the CRC calculation was that it included the BSL header instead of just the payload. Attached the fixed libraries that work for me. My code does not cover getting the device int
  12. Here's a great webinar on the topic of stack overflow from basics like stack sizing all the way to stack usage estimation and analysis, stack monitoring and stack overflow handling. Recording: Transcript: http://barrgroup.com/Embedded-Systems/How-To/Prevent-Detect-Stack-Overflow Found via the Embedded Muse newsletter.
  13. Are you sure your sensor works with 3.3V power and logic? Looking at the product page for the MLX90614, there seem to be separate versions for 3 and 5V supply voltage. https://www.melexis.com/en/product/MLX90614/Digital-Plug-Play-Infrared-Thermometer-TO-Can
  14. @@yyrkoon I'd argue that GPIO_IS_OUTPUT(1,4); GPIO_IS_OUTPUT(1,6); GPIO_IS_OUTPUT(1,0); or gpio_is_output(1,4); gpio_is_output(1,6); gpio_is_output(1,0); are easier to read and maintain than P1SEL &= ~(BIT4); P1DIR |= BIT4; P1SEL &= ~(BIT6); P1DIR |= BIT6; P1SEL &= ~(BIT0); P1DIR |= BIT0; And to the be a total nit picker, the last piece of code actually still relies on macros defined in the MCU specific msp430xxxx.h file. Like with turtles, the embedded C world is macros all the way down
  15. @@Rickta59 Sweet! Thanks for running the comparison. I will have to check with the TI compiler, but I'm hopeful the results are the same. If so, inline is definitely the way to go.
  16. Thank you all for your thoughtful comments. @@yyrkoon I think being able to change pin assignments in once place reduces the likelihood of mistakes. Also reusing the same code or macro instead of repeating code in multiple places should reduce errors. But I agree that complex macros can be a pain to debug if there are issues. @@roadrunner84 Yes, templates would probably the way to go if this were a C++ project. @@enl Do you know, whether the compiler will optimize inline code when using constants as parameters in the function call? E.g. would if(port=='x') or switch(port) statement
  17. PS: One option would be to assume the defaults (pins are configured for GPIO) are in place and do not clear SEL during initialization.
  18. In my project, I use a few basic macros for GPIO. The goal is, that I can easily redefine pin assignment in a central location without compromising performance or code size. The macros (gpiomacros.h): // MSP430 gpio macros #define GPIO_SEL(port) P ## port ## SEL #define GPIO_DIR(port) P ## port ## DIR #define GPIO_OUT(port) P ## port ## OUT #define GPIO_IN(port) P ## port ## IN #define GPIO_IS_INPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) &= ~(pin); } #define GPIO_IS_OUTPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) |= (pin); } #define GPIO_IS_PERIPHER
  19. Hi Polyphemus, Yes, dAISy includes a bandpass filter. I experimented with external LNAs a few times, but didn't see any benefit. Though I never was very systematic about my experiments. The max input must not exceed 10 dBm. Even -50 dBm is more than enough to reliably decode a signal. A LNA would only be useful if it pulls very weak signals (say below -100 dBm) out of the noise.
  20. The f_cpu variable in boards.txt file defines the clock speed of each board. F_CPU is passed into the startup code in wiring.c to configure the clocks. If you're lucky, changing boards.txt is all that's needed. If not, you will have to dig into Energia source code. wiring.c can be found it in the hardware / cores / msp430 folders. According to the G2553 datasheet page 21, 1.8V is the lowest supply voltage supported at up to 6 MHz. Even if your MCU runs down to 1.6V, I would not rely on it. http://www.ti.com/lit/ds/symlink/msp430g2553.pdf
  21. You have to be more specific about what you already tried and what problems you encountered. The Github repository linked in this thread includes examples. If you don't use the Anaren modules, you will have to look at the schematics and adjust wiring or source code. PS: Posting a question once is sufficient. No need to revive multiple marginally related threads.
  22. Hi @@matkar Very good analysis of the PCB. The components in the blue box form a Wilkinson divider tuned to 162 MHz. It has an insertion loss of about 3 dBm. Surprisingly I didn't notice any impact in real-world performance compared to the single-channel dAISy. Not sure why, but I suspect a combination of better noise management (e.g. noise filtering on power rail, radios further away from MCU) and the signal being limited by environmental noise. D41 is for diodes to protect the radios from RF overload. But I struggle to find the right part and am unsure how much it really helps. E
  23. Progress is slow in dAISy land, mostly due to lack of time. But I finally got time to unpack and test the first production batch of the 2-channel dAISy HAT for Raspberry Pi. I've used MacroFab for the first time, which worked out great. Because they don't have NRE, it's the perfect solution for slowly ramping up volumes while still tweaking the design. I even built a little jig for programming and testing. Even though I included a Tag-connect footprint, I decided to use pogo pins and a F5529 LaunchPad for programming. As communication with the Raspberry Pi is only via UART, I c
  24. Which reminds me of http://imgur.com/r/woahdude/y2wd9rK - almost bringing us back on topic re electronic Halloween costumes :-)
  25. Tag connect is nice for programming multiple boards. IMO it's rather impractical when you're still in the developping / debugging phase.
  • Create New...