Jump to content

StefanSch

Members
  • Content Count

    52
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by StefanSch

  1. 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 section the name before the dot needs to be identical (all lines need to start with that) and this name needs to be unique So take the existing MSP430F5994 part, replace the name before the dot and the name = display name in the selection drop down menu
  2. 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 more explicit on Port 4.0 line 670 - tell is has Analog input 8 The final mapping can now be found in the datasheet. Check for mapping of Port 4.0 to the pin mapping of the device variant.
  3. 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.
  4. in the board.txt file you also need to change the prefix CC3220SF-LAUNCHXL.xxxxx
  5. 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
  6. Thanks, for the feedback. I have already implemented the fixes based on your findings and planning for an update release of this package.
  7. 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.
  8. 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
  9. 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
  10. 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 the LPM is cleared the enable execution in the main function again, otherwise the CPU would go into sleep mode again after the ISR. The __bic_SR_register_on_exit cannot clear any of the interrupt flags. The I2C interrupt flags are automatically cleared by switch(__even_in_range(UCB0IV, USCI_I2C_UCBIT9IFG)) - more details are in the Users Guide
  11. 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
  12. 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. But: - the elf compiler might generate some more code due to the support of the upper memory with the extended addressing required for that. And any feedback is welcome....
  13. 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!
  14. 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 version of the Energia MSP430 boards (elf-GCC) Any feedback on this is welcome!
  15. If you prefer the GCC compiler just open the project properties (ALT + Enter) and select under CCS General | Compiler Version the GNU Compiler
  16. 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;
  17. By providing that kind of information nobody will be able to help. So at least add: - type of SD card - connection of sd card - observed error - steps you have tried already - references to the libraries used
  18. see the same now - i do not know why the downgrade did not properly set the path for the downloader Just can suggest a direct hack now: Got to your Energia install folder and edit .... \hardware\energia\msp430\platform.txt replace: tools.dslite.path={runtime.tools.dslite-9.2.0.1793-e1.path} with: tools.dslite.path={runtime.tools.dslite-9.3.0.1863.path} If it can not find the dslilte again then also install the TIVAC package from the board manager - that is also using this dslite version
  19. Hi, it looks like that during the packaging of the last release a few files got missing. If you open the Board manager and switch the version for the MSP430 back to 1.0.6 it should work again.
  20. yes, void delayMicroseconds(unsigned int us) 🙂
  21. __even_in_range is an instrinsic function added for the MSP430 which allows the compiler to generate optimized code using the TAIV register. As it is just used to generate optimized code you can also just leave it away. So use that line: switch(TA0IV)
  22. To just get the latest version you can use the development approach. For this first https://github.com/energia/tivac-core and select Clone or Download and Download ZIP Then locate your local git folder where your projects are stored. In Windows this is in your My Document folder and generate a hardware and Energia folder and unzip the downloaded file into this. So you should get: My Domentents - Energia - hardware - Energia - tivac-core-master => content of downloaded zip file Now start Energia again. You should now have two TIVAC in your board selection / just need to find the correct one.
  23. thanks for reporting this issue. I could commit a fix for this - see here https://github.com/energia/msp430-lg-core/pull/126 This will go into the next release but feel free to grab it an fix it locally. There are just 3 line missing in energia-1.8.10E23 .... \hardware\energia\msp430\libraries\Wire\utility\twi.c
  24. It looks like that this library was written on Arduino only and with some special focus on features provided there. So to get it working in a first step you can: add this line into UserInterface.cpp: #include <atof.h> This will solve your initial error. The C-Compiler in Arduino does automatically include the atof which is nice for the user but makes issues when porting. Next you may run into an issue that the header file util/delay.h can not be found. Delay is part of Arduino and Energia so does not need to be included. To solve this just add an folder util and and empty file delay.h into the LTSketchbook\libraries\Linduino\ folder. Now it gets complicated: this library uses some hardware driver for I2C and SPI - note sure why (did not dig deeper into the lib and hardware) but maybe they want to use a second SPI and I2C. This are hardware specific driver and you need to port them or replace them. As template and examples you might use the existing SPI and I2C(Wire) drivers.
  25. try it with this line: TA0CTL=0b0000001011010000; If it works i will explain why 😊
×
×
  • Create New...