Jump to content
43oh

StefanSch

Members
  • Content Count

    61
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by StefanSch

  1. As far as I can remember, the G2553 has a very small serial buffer. Just try to reduce the number of byte to send, e.g. AT: Instead of Enter AT commands:
  2. G2553 has a Hardware Serial Interface, so do not use the Software implementation. Serial BTSerial..... Should work
  3. Have you removed the jumper for the Red LED, they share the some port from the MSP430 and the load of the LED is to high for I2C. Also ensure your sensor board has the pull up resistors on the I2C data lines.
  4. So it gets stuck in the function for the bioHub. How have you connected the bio sensor?
  5. do a print before this line: Wire.begin(); To ensure the code does not get stuck in this function: int result = bioHub.begin();
  6. Have you tried a simple example for the UART already? So without the Bio sensor code How have you attached the sensor? Try to dump something on the UART before accessing the bio sensor - to ensure / check that this one is not blocking the UART.
  7. Which I2C port do you use - at which pins have you attached your Gyro? Which pin do you use for the servo?
  8. If you need help you should provide some more details: Which launchpad are you using? Which components are you using and how have you connected them? Is gyro running on its own? Is servo running on its own? What step to debug the issue have you already done?
  9. A look into the Schematic resolves the mystic: The signal is not connected as R63 is marked as DNP (Do not populate)
  10. Yes, of course you can do that. Just for the Launchpad the numbering is always done on the boarder of the PCB = Pin Headers of the board, as this is the point where a typical user would connect something. If you prefer for your own board to have the device pin numbers used - you can do that. Doing the updates as you mentioned above should do that 🙂 To get the board in the GUI you need to - add a device in the variants folder - as just discussed with the update of the pins_energia.h file - add a section into the boards.txt file (located in the folder above) in a s
  11. Hi, you are right the pins_energia.h file is the correct location for that. Just let me give you one example of how the mapping works. (line numbers are based on latest released version (1.0.7) line 45 : = pin header static const uint8_t SS0 = 47; /* P4.0 */ line 216: = pin header static const uint8_t P4_0 = 47; Beginning with line 457 the mapping from the pin header to the device function is done With the function above line 505 - tells it has not Timer line 560 - tell it is on Port 4 line 615 - tell it is on Port4 but now mo
  12. Hi Berry, i am not the expert on the cc3220 as this uses RTOS functions to implement the multi threading features. In this implementation a lot of the functions are inside the RTOS library. So check following files: Board_init.c - to adopt pins for SPI, ADC, UART Board.h - to adopt pins for I2C, LEDs, SPI pins.c - maps function to board pin (not CC3220 pin) pins_energia.h - maps function to board pin (not CC3220 pin) Note: DIOxx is pin xx on CC3220 - sometimes the use of board pins and CC3220 can be confusing but needs to be handled carefully.
  13. in the board.txt file you also need to change the prefix CC3220SF-LAUNCHXL.xxxxx
  14. Hi Josef, thanks for highlighting the availability of the newer GCC version. Unfortunately i made a link to the GCC page at TI but this page did not point to the latest compiler (9.x.x) anymore but still to the 8.x.x version. I have just uploaded a new Energia elf GCC compiler version with the 9.2.0.50 compiler (Energia package 2.0.9). Stefan
  15. Thanks, for the feedback. I have already implemented the fixes based on your findings and planning for an update release of this package.
  16. The attribute you have used does work, you just do not see this in the memory report as the report summary did not contain section of upper and lower data memory. When checking the map file (see above) you should see the right placement.
  17. It looks like that the compiler setting for the large memory model is not set correct. can you open the platform.txt file in c:/users/johnw/appdata/local/energia15/packages/energia/hardware/msp430elf/2.0.7/platform.txt and change line 21 from compiler.mlarge_flag=-mlarge -mcode-region=upper to compiler.mlarge_flag=-mlarge -mcode-region=either
  18. The elf gcc compiler automatically uses the full memory space (upper and lower). If you need to place certain functions into upper or lower memory you should use __attribute__((section(".lower.text"))) __attribute__((section(".upper.text"))) The calculation of the used memory needs some update, esp. the available memory is not showing the full (upper and lower memory) What happened at your side: not sure but i assume with the __attribute__ you have used the code did went into the RAM
  19. The golden rule is that an Interrupt Service Routine (ISR) should be as short as possible. Therefore the received data is just stored and then evaluated outside of the ISR. This examples is really very minimalistic - is should better store the data in a buffer instead of a single bit and trigger the evaluation once a full frame has been received. This evaluation than should of course being outside of an ISR. Having this task outside of the ISR ensures proper execution of the code and esp. handling interrupts right in time. Note: during interrupt execution other interrupts are blocked. So
  20. Sorry, do see this problem the first time. Can this be access rights problem? How have you have you waited to complete? Which OS you are using? ~ Stefan
  21. The two proposals are basically the same, where mine is just the already compiled and packed solution of the repository mentioned in the other post. The elf compiler tool chain has been tested for quite a while but it is still beta phase. There are plans to officially release the elf compiler as well but not a fixed time schedule. The good thing: - both tool chains are compatible where the elf compiler does support newer C standard and also the upper memory regions. - you can use both in parallel you just need to select in the board manager the board and the compiler tool chain.
  22. The current compiler in Energia does not support instructions addressing the upper memory space - so it will not work. If you like, you can use a beta implementation using the latest released GCC compiler for the MSP430 and test it on this project. Just add this path in the file | Preferences | Additional Board manager section: http://s3.amazonaws.com/energiaUS/packages/package_msp430_elf_GCC_index.json open the board manager and install the latest version of the Energia MSP430 boards (elf-GCC) Any feedback on this is welcome!
  23. The main issue when compiling this libraries is that it uses C99 standard where as the used compiler for the MSP430 Energia support is quite old not supporting this language version. If you like, you can use a beta implementation using the latest released GCC compiler for the MSP430 and test it on this project. Testing one of the demos did compile without issues Just add this path in the file | Preferences | Additional Board manager section: http://s3.amazonaws.com/energiaUS/packages/package_msp430_elf_GCC_index.json open the board manager and install the latest versio
  24. If you prefer the GCC compiler just open the project properties (ALT + Enter) and select under CCS General | Compiler Version the GNU Compiler
  25. This line in your code for sure gives an issue. If this already solve the problem - i have not tested // Initialize UART and set RX interrupt enable UCA1CTLW0 &= UCSWRST; This will clear all bits except UCSWRST. You would like to clear the UCSWRST bit but then you need to write UCA1CTLW0 &= ~UCSWRST;
×
×
  • Create New...