Jump to content
43oh

Lyon

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    7

Reputation Activity

  1. Like
    Lyon got a reaction from bluehash in error when build (CCS)   
    Hi,
    See this picture:
     
    Keep in mind the Problems window is with "problems" - sometimes it remains blocked, so it is wise to: i)clean up the project and ii)delete manually all info in Problems window and re-build the project.
    Not clear to me if you upgraded or not. 
    If you have still problems, read the Workshop Guide for launchpad - I presumed you use CCS.
    L
  2. Like
    Lyon got a reaction from tripwire in Execution time - the easy way   
    Hi,
    Found on web several postings related to some available, but unused hardware on Cortex-Mx processors (unused on some platforms, available on others.
    Adapted for TM4C as below:
    #include "inc/hw_nvic.h" /* for definition of NVIC_DBG_INT */ #include "inc/hw_memmap.h" /* for definition of DWT_BASE */ #include "inc/hw_types.h" /* for definition of HWREG */ #define DWT_O_CYCCNT 0x00000004 static  uint32_t     c_start, c_stop; // declaration of an initialization function void EnableTiming(void); // definition of that function /******************************************************************************/ void EnableTiming(void){    HWREG(NVIC_DBG_INT) |= 0x01000000;      /*enable TRCENA bit in NVIC_DBG_INT*/    HWREG(DWT_BASE + DWT_O_CYCCNT) = 0;   /* reset the counter */    HWREG(DWT_BASE) |= 0x01;                /* enable the counter */    enabled = 1; } /******************************************************************************/ // and then, in the code to be examined write these: EnableTiming();  c_start = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the beginning of the tested code  // your code follows here  c_stop = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the end of the tested code // then c_stop - c_start is the execution number of cycles for the code; // just multiply with clock period to find out the execution time of the code. // At 80MHz, the 32 bit counter gives you a total time 2^32 x 12.5ns = ~53 seconds! // Another interesting function is this one /**********************************************************/ void TimingDelay(unsigned int tick) { unsigned int start, current; start = HWREG(DWT_BASE + DWT_O_CYCCNT); do { current = HWREG(DWT_BASE + DWT_O_CYCCNT); } while((current-start)<tick); } /*********************************************************/ Enjoy!
    L
  3. Like
    Lyon reacted to pabigot in Execution time - the easy way   
    Excellent; thank you. For reference, here's a portable version using CMSIS, checked on Tiva and EFM32 processors. (You will need to include the CMSIS device header, e.g. TIVA.h for TM4C and em_device.h for EFM32. That's hidden in bspacm/core.h below.)
     
    For reference, the necessary information is in the ARMv7-M Architecture Reference Manual; you have to register with ARM to download the PDF. See sections C1.6.5 for DEMCR and C1.8 for DWT.
     

    /* BSPACM - demonstrate cycle counter interface * * Written in 2014 by Peter A. Bigot <http://pabigot.github.io/bspacm/> * * To the extent possible under law, the author(s) have dedicated all * copyright and related and neighboring rights to this software to * the public domain worldwide. This software is distributed without * any warranty. * * You should have received a copy of the CC0 Public Domain Dedication * along with this software. If not, see * <http://creativecommons.org/publicdomain/zero/1.0/>. */ #include <bspacm/core.h> #include <stdio.h> #define BSPACM_CORE_ENABLE_CYCCNT() do { \ if (! (DWT_CTRL_NOCYCCNT_Msk & DWT->CTRL)) { \ CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; \ DWT->CYCCNT = 0; \ DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; \ } \ } while (0) #define BSPACM_CORE_DISABLE_CYCCNT() do { \ if (! (DWT_CTRL_NOCYCCNT_Msk & DWT->CTRL)) { \ DWT->CTRL &= ~DWT_CTRL_CYCCNTENA_Msk; \ CoreDebug->DEMCR &= ~CoreDebug_DEMCR_TRCENA_Msk; \ } \ } while (0) #define BSPACM_CORE_CYCCNT() DWT->CYCCNT #define BSPACM_CORE_DELAY_CYCLES(cycles_) do { \ uint32_t const delta = (cycles_); \ uint32_t const cc0 = DWT->CYCCNT; \ while ((DWT->CYCCNT - cc0) < delta) { \ /* spin */ \ } \ } while (0) void main () { uint32_t cc0 = 0; BSPACM_CORE_ENABLE_INTERRUPT(); printf("\n" __DATE__ " " __TIME__ "\n"); printf("System clock %lu Hz\n", SystemCoreClock); if (DWT_CTRL_NOCYCCNT_Msk & DWT->CTRL) { printf("DWT does not support cycle counting\n"); return; } BSPACM_CORE_ENABLE_CYCCNT(); do { uint32_t cc1 = DWT->CYCCNT; uint32_t delta = cc1 - cc0; printf("Cycle counter %lu, delta %lu\n", cc1, delta); cc0 = cc1; BSPACM_CORE_DELAY_CYCLES(8000000U); } while (1); }
  4. Like
    Lyon got a reaction from bluehash in Execution time - the easy way   
    Hi,
    Found on web several postings related to some available, but unused hardware on Cortex-Mx processors (unused on some platforms, available on others.
    Adapted for TM4C as below:
    #include "inc/hw_nvic.h" /* for definition of NVIC_DBG_INT */ #include "inc/hw_memmap.h" /* for definition of DWT_BASE */ #include "inc/hw_types.h" /* for definition of HWREG */ #define DWT_O_CYCCNT 0x00000004 static  uint32_t     c_start, c_stop; // declaration of an initialization function void EnableTiming(void); // definition of that function /******************************************************************************/ void EnableTiming(void){    HWREG(NVIC_DBG_INT) |= 0x01000000;      /*enable TRCENA bit in NVIC_DBG_INT*/    HWREG(DWT_BASE + DWT_O_CYCCNT) = 0;   /* reset the counter */    HWREG(DWT_BASE) |= 0x01;                /* enable the counter */    enabled = 1; } /******************************************************************************/ // and then, in the code to be examined write these: EnableTiming();  c_start = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the beginning of the tested code  // your code follows here  c_stop = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the end of the tested code // then c_stop - c_start is the execution number of cycles for the code; // just multiply with clock period to find out the execution time of the code. // At 80MHz, the 32 bit counter gives you a total time 2^32 x 12.5ns = ~53 seconds! // Another interesting function is this one /**********************************************************/ void TimingDelay(unsigned int tick) { unsigned int start, current; start = HWREG(DWT_BASE + DWT_O_CYCCNT); do { current = HWREG(DWT_BASE + DWT_O_CYCCNT); } while((current-start)<tick); } /*********************************************************/ Enjoy!
    L
  5. Like
    Lyon got a reaction from bluehash in Assembly CCS Stellaris LaunchPad   
    Some references:
    1) DDI0403D_arm_architecture_v7m_reference_manual.pdf, ARM
    2) DAI0298A_cortex_m4f_lazy_stacking_and_context_switching.pdf, ARM
    3) Joseph Yiu - The definitive Guide to ARM Cortex-M3, Second Edition, Elsevier,  ISBN 978-1-85617-963-8
    4) Jonathan Valvano: http://users.ece.utexas.edu/~valvano/. Many examples, on-line courses, books. Best starting point for everything ARM
    5) TI: spmu159a - Cortex M3/M4F Instruction Set,: Technical User Manual
    6) TI: spnu118K - ARM-Assembly-Language-Tools-V5.0 User's Guide
    L
  6. Like
    Lyon got a reaction from igor in Execution time - the easy way   
    Hi,
    Found on web several postings related to some available, but unused hardware on Cortex-Mx processors (unused on some platforms, available on others.
    Adapted for TM4C as below:
    #include "inc/hw_nvic.h" /* for definition of NVIC_DBG_INT */ #include "inc/hw_memmap.h" /* for definition of DWT_BASE */ #include "inc/hw_types.h" /* for definition of HWREG */ #define DWT_O_CYCCNT 0x00000004 static  uint32_t     c_start, c_stop; // declaration of an initialization function void EnableTiming(void); // definition of that function /******************************************************************************/ void EnableTiming(void){    HWREG(NVIC_DBG_INT) |= 0x01000000;      /*enable TRCENA bit in NVIC_DBG_INT*/    HWREG(DWT_BASE + DWT_O_CYCCNT) = 0;   /* reset the counter */    HWREG(DWT_BASE) |= 0x01;                /* enable the counter */    enabled = 1; } /******************************************************************************/ // and then, in the code to be examined write these: EnableTiming();  c_start = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the beginning of the tested code  // your code follows here  c_stop = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the end of the tested code // then c_stop - c_start is the execution number of cycles for the code; // just multiply with clock period to find out the execution time of the code. // At 80MHz, the 32 bit counter gives you a total time 2^32 x 12.5ns = ~53 seconds! // Another interesting function is this one /**********************************************************/ void TimingDelay(unsigned int tick) { unsigned int start, current; start = HWREG(DWT_BASE + DWT_O_CYCCNT); do { current = HWREG(DWT_BASE + DWT_O_CYCCNT); } while((current-start)<tick); } /*********************************************************/ Enjoy!
    L
  7. Like
    Lyon got a reaction from igor in GDB with stellaris LP under windows?   
    Hi,
    You may start by downloading OpenOCD for Windows from here (use binary package since the compilation on Windows is difficult): http://www.freddiechopin.info/en/download/category/4-openocd   Note the last version, 0.7.0, is working for TM4C123x/LM4Fxxx micros - has all modifications needed.   The trick to make it working with Win systems is to instruct the device manager in Windows to ignore all USB connection of this board, since OpenOCD uses it own USB library.   How to install and use it from command line is best described in this page: http://processors.wiki.ti.com/index.php/Stellaris_Launchpad_with_OpenOCD_and_Linux - ignore the Linux stuff and use only the rest of the info, with one mention: still this page is largely outdated -  do not apply patches from Zylin since these are already included into the latest release.   If you like to set up your Eclipse toolchain, then this link is the best, although it may refer to other tools also (contains also a lot of tricks for Eclipse): http://mcuoneclipse.com/2014/02/16/diy-free-toolchain-for-kinetis-part-10-project-creation-with-gnu-arm-eclipse-2-1-2/#more-10788 This is the tenth episode from a series about installing and using Eclipse - and apply for all operating systems. I provided you the last episode since this contain links for other previous nine ones.   Last, one more plugin - needed to define the processor registers by name and to easily inspect them Embedded Registers View:
    - from here: http://sourceforge.net/projects/embsysregview/ to be downloaded as local package or 
    - from here: http://embsysregview.sourceforge.net/update    to be installed from Eclipse. 
    Also from embsysregview.sourceforge.net - go to Install menu and then click "Configuration" to find out how to configure this plug-in.
     
    If any problem - just ask.
    Good luck!
    L
  8. Like
    Lyon got a reaction from timotet in Execution time - the easy way   
    Hi,
    Found on web several postings related to some available, but unused hardware on Cortex-Mx processors (unused on some platforms, available on others.
    Adapted for TM4C as below:
    #include "inc/hw_nvic.h" /* for definition of NVIC_DBG_INT */ #include "inc/hw_memmap.h" /* for definition of DWT_BASE */ #include "inc/hw_types.h" /* for definition of HWREG */ #define DWT_O_CYCCNT 0x00000004 static  uint32_t     c_start, c_stop; // declaration of an initialization function void EnableTiming(void); // definition of that function /******************************************************************************/ void EnableTiming(void){    HWREG(NVIC_DBG_INT) |= 0x01000000;      /*enable TRCENA bit in NVIC_DBG_INT*/    HWREG(DWT_BASE + DWT_O_CYCCNT) = 0;   /* reset the counter */    HWREG(DWT_BASE) |= 0x01;                /* enable the counter */    enabled = 1; } /******************************************************************************/ // and then, in the code to be examined write these: EnableTiming();  c_start = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the beginning of the tested code  // your code follows here  c_stop = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the end of the tested code // then c_stop - c_start is the execution number of cycles for the code; // just multiply with clock period to find out the execution time of the code. // At 80MHz, the 32 bit counter gives you a total time 2^32 x 12.5ns = ~53 seconds! // Another interesting function is this one /**********************************************************/ void TimingDelay(unsigned int tick) { unsigned int start, current; start = HWREG(DWT_BASE + DWT_O_CYCCNT); do { current = HWREG(DWT_BASE + DWT_O_CYCCNT); } while((current-start)<tick); } /*********************************************************/ Enjoy!
    L
  9. Like
    Lyon got a reaction from pabigot in Execution time - the easy way   
    Hi,
    Found on web several postings related to some available, but unused hardware on Cortex-Mx processors (unused on some platforms, available on others.
    Adapted for TM4C as below:
    #include "inc/hw_nvic.h" /* for definition of NVIC_DBG_INT */ #include "inc/hw_memmap.h" /* for definition of DWT_BASE */ #include "inc/hw_types.h" /* for definition of HWREG */ #define DWT_O_CYCCNT 0x00000004 static  uint32_t     c_start, c_stop; // declaration of an initialization function void EnableTiming(void); // definition of that function /******************************************************************************/ void EnableTiming(void){    HWREG(NVIC_DBG_INT) |= 0x01000000;      /*enable TRCENA bit in NVIC_DBG_INT*/    HWREG(DWT_BASE + DWT_O_CYCCNT) = 0;   /* reset the counter */    HWREG(DWT_BASE) |= 0x01;                /* enable the counter */    enabled = 1; } /******************************************************************************/ // and then, in the code to be examined write these: EnableTiming();  c_start = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the beginning of the tested code  // your code follows here  c_stop = HWREG(DWT_BASE + DWT_O_CYCCNT); // at the end of the tested code // then c_stop - c_start is the execution number of cycles for the code; // just multiply with clock period to find out the execution time of the code. // At 80MHz, the 32 bit counter gives you a total time 2^32 x 12.5ns = ~53 seconds! // Another interesting function is this one /**********************************************************/ void TimingDelay(unsigned int tick) { unsigned int start, current; start = HWREG(DWT_BASE + DWT_O_CYCCNT); do { current = HWREG(DWT_BASE + DWT_O_CYCCNT); } while((current-start)<tick); } /*********************************************************/ Enjoy!
    L
  10. Like
    Lyon got a reaction from Vin255 in Understanding ARM based controller (stellaris) through driverlib or through registers   
    Hi,
    I am speaking for myself, not part with any brand - each approach has its own advantages and disadvantages. You may use whatever you need or think is more appropriate to your application.
    CMSIS is more permisive in terms of its licence - you may use it in both commercial and non-commercial applications. However, its price, as noted by @@pabigot, is the code size and of coarse the execution time. This expression:
    GPIOA->AFSEL |= GPIO_PIN_0 | GPIO_PIN_1;
    for instance is of the type read-modify-write sequence, so it induces some penalty in code size and of coarse execution time, since there are three operations to make, while the the HWREG used by TI is of type write-only, since uses bit-banding, which allows to change any bit, and this is done in a single write cycle. This may become obvious in time-constrained applications, where you need to optimize the execution time of interrupts, otherwise could be unimportant.
    As for portability of structures - yes, maybe, but this stop here, since there is not any true portability between different brands: for instance TI makes GPIO ports 8-bit wides, ST makes them 16-bits and NXP makes them 32-bits. Not the same also for other peripherals implemented. I checked the CAN module implementation on TI and compared to that of NXP, for Cortex-M4. While the general structure looks the same, NXP has an extra register more than TI, not speaking about the register names are different.
    And despite these, if there are some libraries ready-made why not to use them?
    L
  11. Like
    Lyon got a reaction from roadrunner84 in Extremely simple ARM assembly example with Tiva C?   
    HI,
     

    Well, while it is possible to do such small program as you do for MSP430, you must take into account the major differences between MSP430 and Cortex-M4: the latest imposes some discipline in program writing. This is due to hardware realization of the inside circuitry of Cortex.    First flash location is at address 0 and in this location must reside the address of stack pointer, even if it is not used. The second location is the address of startup routine; this must be also present; at startup the processor uses these two locations and then goes further, so you must provide them. This address and the rest of interrupt vectors must have the last bit set to 1, making it odd number, despite even alignment - this last bit is internal signal for thumb interrupt - as requested by ARM. Note this is compiler's job, but directed by you.   Next, after these two locations, there must be the rest of interrupt vectors locations, properly initialized. You need these also - otherwise you will be soon in trouble, at the first mistake. You must know also this processor is provided with a unusual big and complex debug and diagnostic machine - so fault interrupts must be really initialized and a code body provided for them. So this is why in general, you must use two files for every small program (and Valvano is best to follow and learn from):  - one is a startup.S, which is written only once; - the other one is main.S which is your program.   I understand your pain - this is not so simple - and using IAR is an add-on, since no example - of coarse you must read/learn IAR documentation - however an example written in IAR assembler can be found in TIVA/boot_loader/bl_startup_ewarm.S - you can copy/paste from that file a lot...   Hope this will help you,
  12. Like
    Lyon got a reaction from skugga87 in Interrupt routines   
    Hi,

    First, you cross-posted on e2e tiva-arm site - and I prefer to highlight you here some problems:

    1) According to the user manual, page 560:

     

    In Edge-Time mode, the timer is configured as a 16-bit down-counter. In this mode, the timer is initialized to the value loaded in the GPTMTnILRregister. The timer is capable of capturing three types of events: rising edge, falling edge, or both.

    So your configuration of Timer 0 must be changed, two timers, split configuration. On 9B90 there are no alternative to that - this is Stellaris. One timer will be enough. With two timers you will have problems - there is no guarantee there are only one free timer inside nor they will be in sync. 

     

    You should also realize the generated PWM signal and the capture are two un-related events, so you don't know when one start or stop or takes more than usual (period and/or duty). So there is the possibility that an edge to come when the counter is at count=5, goes to 0 (over-roll) and reloads with 0xFFFF and the next edge is at 0xFFE0 - so you must make some math. But if either the duration or the period is longer than 0xFFFF maximum capacity, some more over-rolls may be present. You did not specified any boundary-limitations-parmeters of your pulse to be measured - so we must ask or signal the problem. Keep in mind this is important - any omision will force you to return to this problem and find out patches - so thinking from the beginning at the whole problem will be your benefit (not ours).

     

    Now about the measurement itself:

    Of coarse should be done only in interrupt - and you have some solutions:

    2) Start as you already done, with detecting both edges. But this means when in interrupt you must detect what was the edge - rising or falling. You may use a separate GPIO pin configured as input and to read its value, hi or low and then to make further calculations.

     

    3)Start with the capture for the positive edge and when interrupt is fired, change the settings for the negative edge.

    Your interrupt must respond also to overtime (over-roll) - and must be counted and taken into account. You must clean up the over-roll count at every edge change.

     

    Take care in this configuration the prescalers are not available - seems you already read about and choose to lower the system clock - but this is not a solution since some applications may need higher/highest system clock (USB, Ethernet, etc).

    L

  13. Like
    Lyon got a reaction from spirilis in The Datasheet "Book Club"   
    Hi,
    Spirilis, congratulations for the idea, it is very good.
    As for your comments, I have two small observations:
    1) ref yours #2: as far as I know, up to now, on TI boards is implemented only JTAG interface ( ICDI knows only that) but seems to be changing on TM4C129 boards. Other providers (IAR, Segger) implemented both JTAG and SWD on their uLink2 devices.
    2) ref yours #4: no, PRIMASK is not a replacement for global interrupt enable. This is still present and can/must be used with IntMasterEnable() function which is a wrapper to the asm instruction cpsie. The purpose of PRIMASK is to enhance the responsivity of application to real time events and to avoid disabling global interrupts, widely used in RTOSes. The feature is still not fully used by all RTOS authors. Now there are RTOSes which do not disable at all the global interrupt, improving the responsivness to real time events.
    L
  14. Like
    Lyon got a reaction from spirilis in Understanding ARM based controller (stellaris) through driverlib or through registers   
    Hi,
    To answer your questions: start first with TI's user manual to know peripherals. I should say: " A chapter a day, keeps the forum away" - this is the known fact these days the user manuals are very big, so one chapter each day is better, since you need to read it several times. Every time you can read also the ARM manuals - but these are made as for a " industry standard" they are a little bit harder to swallow.
    A second approach is to use the TI's ready made applications - and understand how are made and how the peripherals are used.
    Third - since it seems you are pressed to use on-board switches - see this tread, last item: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/327836.aspx
    This is for tutorials for correct use of switches. But I suggest to "switch" to this problem a little bit later, after you run several applications.
    For asm instructions - there is a document related to that on TI site - on the TIva processors page / application notes - try to find yourself and if you do not find it, I will come back with the right address. ( this is for learning how to find yourself the needed info. In fact, every application note from there must be read in time of coarse...)
    Last - please specify your toolchains to give you the right info (GCC is different from CCS and so on).
  15. Like
    Lyon got a reaction from bluehash in Understanding ARM based controller (stellaris) through driverlib or through registers   
    Hi,
    To answer your questions: start first with TI's user manual to know peripherals. I should say: " A chapter a day, keeps the forum away" - this is the known fact these days the user manuals are very big, so one chapter each day is better, since you need to read it several times. Every time you can read also the ARM manuals - but these are made as for a " industry standard" they are a little bit harder to swallow.
    A second approach is to use the TI's ready made applications - and understand how are made and how the peripherals are used.
    Third - since it seems you are pressed to use on-board switches - see this tread, last item: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/327836.aspx
    This is for tutorials for correct use of switches. But I suggest to "switch" to this problem a little bit later, after you run several applications.
    For asm instructions - there is a document related to that on TI site - on the TIva processors page / application notes - try to find yourself and if you do not find it, I will come back with the right address. ( this is for learning how to find yourself the needed info. In fact, every application note from there must be read in time of coarse...)
    Last - please specify your toolchains to give you the right info (GCC is different from CCS and so on).
  16. Like
    Lyon got a reaction from Vin255 in Understanding ARM based controller (stellaris) through driverlib or through registers   
    Hi,
    The ARM architecture is a complex one, so best thing to do is to read the user manual. This is because ARM depart from usual 8 or 16 bit implementations you may know from other brands.
     
    Some historical things first: ARM company sell only the project of the core and some peripherals. The buyer then add its own extra peripherals so the final product differ from company to company - so if you need to use a particular brand, first thing first is to read the user manual. For extra readings of the core, you may go to ARM an search their manuals and user documentation.
     
    As for API, you must know there are several approaches - one is CMSIS libray, the other one - TI - uses its own driverlib. There are not examples (except blinky program) without driverlib functions, because without it is very difficult to write and then read/understand/remember what you have done.
     
    My advise: read the TI docs you may find in Tiva/doc folder, there is one explaining the concept of driverlib and use these and in case of something unclear ask questions about - basically TI uses bit-banding - one macro to write to registers - this has the big advantage to be executed in one clock cycle, so the speed is big, compared to other approaches.
    L
  17. Like
    Lyon got a reaction from spirilis in Understanding ARM based controller (stellaris) through driverlib or through registers   
    Hi,
    The ARM architecture is a complex one, so best thing to do is to read the user manual. This is because ARM depart from usual 8 or 16 bit implementations you may know from other brands.
     
    Some historical things first: ARM company sell only the project of the core and some peripherals. The buyer then add its own extra peripherals so the final product differ from company to company - so if you need to use a particular brand, first thing first is to read the user manual. For extra readings of the core, you may go to ARM an search their manuals and user documentation.
     
    As for API, you must know there are several approaches - one is CMSIS libray, the other one - TI - uses its own driverlib. There are not examples (except blinky program) without driverlib functions, because without it is very difficult to write and then read/understand/remember what you have done.
     
    My advise: read the TI docs you may find in Tiva/doc folder, there is one explaining the concept of driverlib and use these and in case of something unclear ask questions about - basically TI uses bit-banding - one macro to write to registers - this has the big advantage to be executed in one clock cycle, so the speed is big, compared to other approaches.
    L
  18. Like
    Lyon got a reaction from bluehash in Tiva version 2.1   
    Hi,
    Today was released TivaWare version 2.1.0.12573 which can be downloaded from here:
    software-dl.ti.com/tiva-c/SW-TM4C/latest/index_FSD.htm
    This new release contain many news, including some compiler configuration needed to be changed - the famous TARGET_IS_BLIZZARD_REVxx
    was changed to TARGET_IS_TM4C123_REVxx.

     
    Also many driverlib functions were changed or moved to other .h files. As many users will try to update this, please it is wise to read first this document:
    SW-TM4C-RLN-2.1.0.12573.pdf which is located in /doc folder of your Tiva-2.1 installation.
    Regards,
    L
  19. Like
    Lyon got a reaction from bluehash in Understanding ARM based controller (stellaris) through driverlib or through registers   
    Hi,
    The ARM architecture is a complex one, so best thing to do is to read the user manual. This is because ARM depart from usual 8 or 16 bit implementations you may know from other brands.
     
    Some historical things first: ARM company sell only the project of the core and some peripherals. The buyer then add its own extra peripherals so the final product differ from company to company - so if you need to use a particular brand, first thing first is to read the user manual. For extra readings of the core, you may go to ARM an search their manuals and user documentation.
     
    As for API, you must know there are several approaches - one is CMSIS libray, the other one - TI - uses its own driverlib. There are not examples (except blinky program) without driverlib functions, because without it is very difficult to write and then read/understand/remember what you have done.
     
    My advise: read the TI docs you may find in Tiva/doc folder, there is one explaining the concept of driverlib and use these and in case of something unclear ask questions about - basically TI uses bit-banding - one macro to write to registers - this has the big advantage to be executed in one clock cycle, so the speed is big, compared to other approaches.
    L
  20. Like
    Lyon got a reaction from spirilis in Tiva version 2.1   
    Hi,
    Today was released TivaWare version 2.1.0.12573 which can be downloaded from here:
    software-dl.ti.com/tiva-c/SW-TM4C/latest/index_FSD.htm
    This new release contain many news, including some compiler configuration needed to be changed - the famous TARGET_IS_BLIZZARD_REVxx
    was changed to TARGET_IS_TM4C123_REVxx.

     
    Also many driverlib functions were changed or moved to other .h files. As many users will try to update this, please it is wise to read first this document:
    SW-TM4C-RLN-2.1.0.12573.pdf which is located in /doc folder of your Tiva-2.1 installation.
    Regards,
    L
  21. Like
    Lyon got a reaction from dubnet in Tiva version 2.1   
    Hi,
    Today was released TivaWare version 2.1.0.12573 which can be downloaded from here:
    software-dl.ti.com/tiva-c/SW-TM4C/latest/index_FSD.htm
    This new release contain many news, including some compiler configuration needed to be changed - the famous TARGET_IS_BLIZZARD_REVxx
    was changed to TARGET_IS_TM4C123_REVxx.

     
    Also many driverlib functions were changed or moved to other .h files. As many users will try to update this, please it is wise to read first this document:
    SW-TM4C-RLN-2.1.0.12573.pdf which is located in /doc folder of your Tiva-2.1 installation.
    Regards,
    L
  22. Like
    Lyon got a reaction from larryfraz in Using Hardware PWM on Tiva Launchpad   
    Hi,
    I apologize, my fault - the startup.gcc provided was from StrelarisWare version 9453, so the only correction is to add #include <stdint.h> at the beginning of startup_gcc.c file, and you need to place it as the first include, since there are already other two files.
    Please take care to provide an include path to the stdint.h file in your compiler installation if not already specified.
    L
  23. Like
    Lyon got a reaction from igor in Designing a Logic analyser using GPIO <-> DMA <-> USB   
    Hi,
    First some technical details about your sources of inspiration: 1) FX2L chip which is the base of Saleae product is an 8051 chip, with some heavy-duty hardware embedded - their GPIF stands for General Purpose InterFace - which has not a correspondent in TM4C123 chips. Also there is an high-speed USB interface, designed to run at maximum, 480M. Also the chip has a big 4K FIFO buffer. 2) So the corresponding sigrok software can be used only as a template, since it is specifically written for 8051. The hardware implementation also dictates the software, so you must be prepared to  hard work to cover/replace/adapt all these to the hardware of Cortex-M4 implemented by TI.   Now, about the concept TM4C123: GPIO >> DMA: GPIO as it is implemented  has irregular timing responses, due to on-chip bus arbitration and delays across bus bridges. Sampling rate cannot be specified - usually to realize sampling, you use a timer, but this will introduce delays due to interrupts. At most, you can use a continuous loop read of a port, but that also will depend on software. DMA is only triggered at pin events, which is not what you need.   But there are some good news: TM4C129 series has a module (EPI) similar to GPIF in FX2L chip - and the use of DMA is a good thing. Configuring the EPI in general purpose mode could be a good solution. The maximum sampling rate is 60MHz and is a predictable operation, which is a big advantage over usual GPIO. Remember, you need to make uniform sampling of signal and this must be done all the time, not only at edge changing. The sampling clock (EPI clock) can be easily configured for various EPI baud rates.   On more word: Saleae implementation does not use any triggered acquisition, which limits the usefulness of such tool (my opinion, since I need that, your may differ…)   But all these depend on your goals - for a demo or proof of concept you may try anything… but I will vote for EPI.   Regards,
  24. Like
    Lyon got a reaction from spirilis in Designing a Logic analyser using GPIO <-> DMA <-> USB   
    Hi,
    First some technical details about your sources of inspiration: 1) FX2L chip which is the base of Saleae product is an 8051 chip, with some heavy-duty hardware embedded - their GPIF stands for General Purpose InterFace - which has not a correspondent in TM4C123 chips. Also there is an high-speed USB interface, designed to run at maximum, 480M. Also the chip has a big 4K FIFO buffer. 2) So the corresponding sigrok software can be used only as a template, since it is specifically written for 8051. The hardware implementation also dictates the software, so you must be prepared to  hard work to cover/replace/adapt all these to the hardware of Cortex-M4 implemented by TI.   Now, about the concept TM4C123: GPIO >> DMA: GPIO as it is implemented  has irregular timing responses, due to on-chip bus arbitration and delays across bus bridges. Sampling rate cannot be specified - usually to realize sampling, you use a timer, but this will introduce delays due to interrupts. At most, you can use a continuous loop read of a port, but that also will depend on software. DMA is only triggered at pin events, which is not what you need.   But there are some good news: TM4C129 series has a module (EPI) similar to GPIF in FX2L chip - and the use of DMA is a good thing. Configuring the EPI in general purpose mode could be a good solution. The maximum sampling rate is 60MHz and is a predictable operation, which is a big advantage over usual GPIO. Remember, you need to make uniform sampling of signal and this must be done all the time, not only at edge changing. The sampling clock (EPI clock) can be easily configured for various EPI baud rates.   On more word: Saleae implementation does not use any triggered acquisition, which limits the usefulness of such tool (my opinion, since I need that, your may differ…)   But all these depend on your goals - for a demo or proof of concept you may try anything… but I will vote for EPI.   Regards,
  25. Like
    Lyon got a reaction from larryfraz in Using Hardware PWM on Tiva Launchpad   
    Hi,
    Some more useful things:
    L
    gcc-lk-start.zip
×
×
  • Create New...