Jump to content

Vin255

Members
  • Content Count

    14
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Vin255 reacted to igor in what is the difference between Flash memory and SRAM.   
    As I understand it erases "wear" a flash memory, I have not seen indication that writes do also.
    (Of course between erases all you can write to a flash are 0 bits, so there is a practical limit to the number of meaningful writes you can do between erases).
    http://en.wikipedia.org/wiki/Flash_memory
     
    On question 2.
    Variables are not normally stored in flash (unlike RAM or FRAM you need a special procedure to write to flash, while a programming language could do that behind the scenes to allow variables to be stored in flash, this is not typically done.)
    Constants on the other hand are typically stored in flash.
    const int i = 3;  // Stored in flash int j = 3; // Stored in RAM, but initial value stored in flash and copied to RAM by startup code. You didn't ask, but just for completeness, the other kind of RAM you will encounter on Stellaris/Tiva processors is EEPROM.
    (Electrically Erasable Programmable Read Only Memory).
     
    Flash is a kind of EEPROM.  The EEPROMs on the Tiva processors are smaller than RAM.
    They can typically be erased a word at a time (vs. Flash which is typically erased in blocks), and you do not have to explicitly erase before writing.
    The EEPROM also has some protection mechanisms to control access to pages.
    Other than that pretty similar to Flash (non-volatile, limited number of erasures, slower than RAM).
     
    Typically used for storing configuration values (e.g. MAC or IP address for a network device)  (i.e. information that is changed occasionally but needs to be retained while the device is off).  Since it is in a separate address area one does not have to worry about not overwriting program data (as one would with storing values in Flash).
     
     
    There is also a bit of ROM on the chip - holds built in libraries, etc.
  2. Like
    Vin255 reacted to L.R.A in what is the difference between Flash memory and SRAM.   
    Well i'll try to explain.
     
    Flash is a non-volatile memory, meaning that it retains the memory stored even when you stop powering it. The RAM is volatile so it loses all the data store when you stop powering it. FRAM is a type of RAM but it retains the data even after power off.
     
    Flash is the least expensive of the 3 so it's normally bigger and due to being non-volatile you use it to store the code and you can also save there data, like your HDD in your computer. Flash is also the slowest of them all and it has a life time, i think the MSP flash has about 100k erase-write cycles. Note that although flash is access and writing is much slower than a RAM it's faster than a HDD, it's like a SSD.
     
    RAM is very fast and can be accessed tons of times without wearing out. It's volatile so you can't use it to save a permanent code, although you can save there code and run from there, if you power down the MCU then you lost all the code. It's more expensive than the flash hence the smaller size compared to Flash. It's the best to store variable since it's the fastest and that i necessary when doing math and other operations. 
     
    FRAM is the most expensive of the 3. It can work as a Flash since it's non-volatile and you can use it as a RAM since it's so fast. It's faster, less power consuming and it lasts even longer than a RAM.
    FRAM is also a RAM because RAM stands for random access memory. RAM doesn't exactly stand for a volatile memory although that is mostly the case.
    I think MSP is the first micro controller with the FRAM 
    Note that unlike the Flash the FRAM wears out even with just reading it while the Flash is just with erase and write. Also the FRAM is slower than SRAM is remember right. One big advantage i read up is that since it's so fast compared to Flash, you can execute a code quicker (you read it quicker) so you can then have the MCU in standby by a longer percentage of time, so it's good to save power
  3. Like
    Vin255 reacted to pabigot in Understanding ARM based controller (stellaris) through driverlib or through registers   
    No; DATA is an array of uint32_t so the indexing operation multiplies by four.
  4. Like
    Vin255 reacted to spirilis in The Datasheet "Book Club"   
    Ok so this was an idea that came to mind last night; These datasheets and related documents are huge, and sometimes have surprising & interesting details nestled into their labyrinth-like chapters.  Why not start a thread for sharing noteworthy details?  No need to be a pack of lone wolves about these things...
     
    I'll start - with the TM4C123GH6PM datasheet: http://www.ti.com/lit/ds/symlink/tm4c123gh6pm.pdf
     
    Reading through Chapter 2 yesterday, "The Cortex-M4F Processor", a few details stuck out that I hadn't realized before-
     
    1. Didn't realize there is a 16-bit SIMD vector processing unit.  How do you access/use it from GCC I wonder?
     
    2. Debug - SWV, Serial Wire Viewer, is a feature where you can export a stream of software-generated messages, data trace, profiling information.  Software-generated messages -- How do we access that?  I assume we need OpenOCD to use this feature, but is there an API for writing to this debug interface?
     
    3. Like most complicated processors, there is a notion of "privileged" vs "unprivileged" execution modes.  The Cortex-M4F extends this further by declaring two operational modes too--"Thread" mode (i.e. normal application runtime, either privileged or unprivileged) and "Handler" mode, exclusively privileged and only available as the context for ISR handlers.
     
    4. Coming from MSP430 land, I'm always looking for analogies to the MSP430 in here.  The equivalent for the "GIE" (global interrupt enable) bit is the PRIMASK register; when bit0 is set, it disables all interrupts (of configurable priority, so RESET/NMI/Fault interrupts still fire).  This is important for sleep modes below...
     
    5. Interrupt priorities run from 0-7, with *lower* numbers being of "higher" priority.  Default priority for all interrupts is 0 (the highest).  BASEPRI register declares the minimum priority required to fire, and besides setting 0 (=no exceptions masked), the setting masks all interrupts of that priority and those higher in number ("lower" in priority).
     
    6. The CONTROL register has an interesting bit, "FPCA", which will adjust the latency for entering an interrupt ISR; it determines whether or not the Floating Point Unit's registers should be pushed onto the stack during ISR entry or not.  This makes a substantial difference, as seen on page 109; the difference between FPCA=1 exception frame and FPCA=0 exception frame is many-fold.  So folks not using floating point would do well to keep that disabled (not 100% sure how GCC handles this yet, i.e. whether there's a builtin, a TivaWare ROM_* function or if you have to do an inline ASM code).
     
    7. Bit-banding is available for everything; flash, SRAM, peripherals.  I think TivaWare has some macros to make that easy, need to look into it.  It's a feature for doing single atomic writes or reads to a single bit of any byte in the address space, by writing/reading a 32-bit word (0x00000000 for bit 0, 0x00000001 for 1).
     
    8. The Cortex-M4F provides two user IRQs for operating system support; SVCall (Supervisor Call) and PendSV (pendable, interrupt-driven request for system-level service--typically used for context switching).
     
    9. Sleep modes.  The Cortex-M4F uses instruction-based sleep entries, but it has some features that allow the MSP430's "event driven" paradigm too.
    9a. WFI = Wait For Interrupt, goes to sleep and will wake up only if an unmasked interrupt occurs.
    ** Sometimes waking requires a common "clean-up" or reinitialization routine to run; to support this, your app would enter WFI inside an idle loop with PRIMASK enabled so that the CPU wakes up, but does not enter the ISR right away; does its cleanup work; then disables PRIMASK so the Cortex immediately jumps to the highest-priority IRQ's ISR.
    9b. WFE = Wait For Event, goes to sleep and will wake up if ANY interrupt occurs, even if it's masked; If it is masked, the CPU will not branch to its ISR but just continue from the point where the WFE instruction occurred.  If it is unmasked, then the CPU will jump to the ISR immediately.
    9c. Sleep-on-Exit; if the SLEEPEXIT bit of SYSCTRL is set, then the CPU will return to sleep mode after servicing ISRs.  Similar to MSP430's LPM modes if the ISR does not issue a __bic_SR_register_on_exit(LPMx_bits); type of call.
     
    That's all for now.  Chapter 3 later today.
  5. Like
    Vin255 reacted to pabigot in The Datasheet "Book Club"   
    A subset of the lessons I learned today (references are to the TM4C123GH6PM data sheet):
    5.2.6 "System Control" specifies a delay of 3 system clocks after a peripheral module clock is enabled in the SYSCTL->RCGCmodule register before the module registers are accessed. (A comment in driverlib/sysctl.c says five clock cycles.) Failure to satisfy this delay results in a HardFault. 
    Unfortunately, gcc-arm doesn't have a __delay_cycles() function.
    Today was my day to discover commit control (10.2.4) and the need to unlock PC0-PC3, PD7, and PF0 before setting AFSEL or DEN if you actually want a peripheral on those pins to work. Much example code for the unlock process looks like:
    HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY; HWREG(GPIO_PORTD_BASE + GPIO_O_CR) |= 0x80; HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = 0; This isn't wrong, but the second assignment to LOCK is unnecessary because writing to CR automatically releases the lock (description of GPIOLOCK register on page 684). It's annoying that the CMSIS structure declaration for the GPIO registers marks the CR register as read-only so you have to cast away the const in order to set the commit bits.
  6. Like
    Vin255 reacted to pabigot in Understanding ARM based controller (stellaris) through driverlib or through registers   
    But this is not true. AFSEL is a single register that is not accessed using bitbanding: the TivaWare code that implements the equivalent to the CMSIS operation is:
    HWREG(ui32Port + GPIO_O_AFSEL) = ((ui32PinIO & 2) ? (HWREG(ui32Port + GPIO_O_AFSEL) | ui8Pins) : (HWREG(ui32Port + GPIO_O_AFSEL) & ~(ui8Pins))); Which is just as much an RMW operation as the CMSIS version. 
    Bit-banding is relevant for operations on a GPIO DATA register, which is (in the CMSIS-based modification I used) declared as an array, and:

    GPIOF->DATA[GPIO_PIN_2 | GPIO_PIN_6] = 0xFF does use bit-banding and only affects pins 2 and 6. 
    My example showed that CMSIS is smaller and faster, because TivaWare involves function calls into ROM for operations that should be inlined. Thus the price of using the vendor's custom library is code size and execution time.
     
    I absolutely think there is a value in vendor-provided functions that go beyond simple peripheral register manipulations to provide higher-level functions. Much of driverlib does not meet this level of functionality, and is simply bloated and obscure.
     
    I didn't mean to imply that use of a CMSIS-based peripheral gives you portability across Cortex-M chips; it certainly does not, as peripherals are explicitly open to variation by the silicon vendor. What it does give you is a common programming model that is re-usable: you manipulate Cortex-M peripheral and MCU registers with C language expressions involving pointers to mapped registers, not through vendor-specific function calls. The available registers, and how they're used, are specific to a particular peripheral implementation, but that variation is not nearly so large as whether it's spelled GPIO_PinOutSet(port, pin) as in emlib or GPIOPinWrite(port, pin, value) as in TivaWare.
     
    This is the heart of a discussion on this topic elsewhere. The answer is that in most cases yes, you should suck it up and use them, even when they're demonstrably poor, because re-implementing them is a boatload of work and makes you incompatible with other people targeting the same chips. 
    But when the vendor is promoting their product as an ARM Cortex-M chip, but does not support the ARM standard interface designed for Cortex-M chips as other vendors do, this is IMO poor practice, and is enough to drive me to vendors that are more willing to cooperate within the ecosystem that they have chosen to join.
  7. Like
    Vin255 reacted to Lyon 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
  8. Like
    Vin255 reacted to pabigot in Understanding ARM based controller (stellaris) through driverlib or through registers   
    So I've played with the github CMSIS stuff enough to know it can be made to work, though there are bugs in it (the GPIOA_Type structure is wrong for the DATA field, which should be an array of 256 words at the start of the struct, rather than a single word after 255 words of padding). Also a lot of defines for bit fields within the registers are missing.
     
    Here's a taste of some examples translating code from the ek-tm4c123gxl uart_echo demonstration from driverlib to CMSIS:

    // Get and clear the interrrupt status, then loop while the RX // FIFO has data #if CMSIS - 0 UART0->ICR = UART0->MIS; #define UART_FR_RXFE 0x10 while(! (UART_FR_RXFE & UART0->FR)) { UART0->DR = UART0->DR; GPIOF->DATA[GPIO_PIN_2] = GPIO_PIN_2; SysCtlDelay(SysCtlClockGet() / (1000 * 3)); GPIOF->DATA[GPIO_PIN_2] = 0; } #else { uint32_t ui32Status; ui32Status = ROM_UARTIntStatus(UART0_BASE, true); ROM_UARTIntClear(UART0_BASE, ui32Status); while (ROM_UARTCharsAvail(UART0_BASE)) { ROM_UARTCharPutNonBlocking(UART0_BASE, ROM_UARTCharGetNonBlocking(UART0_BASE)); GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, GPIO_PIN_2); SysCtlDelay(SysCtlClockGet() / (1000 * 3)); GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, 0); } } #endif /* Write next char to UART */ #if CMSIS - 0 #define UART_FR_TXFF 0x20 /* NB: This one waits for tx space */ while (UART_FR_TXFF & UART0->FR) { /* spin */ } UART0->DR = *pui8Buffer++; #else /* This one does not, and can drop chars */ ROM_UARTCharPutNonBlocking(UART0_BASE, *pui8Buffer++); #endif // Set GPIO A0 and A1 as UART pins. #if CMSIS - 0 GPIOA->PCTL |= 0x11; GPIOA->AFSEL |= GPIO_PIN_0 | GPIO_PIN_1; GPIOA->DR2R |= GPIO_PIN_0 | GPIO_PIN_1; GPIOA->DEN |= GPIO_PIN_0 | GPIO_PIN_1; #else GPIOPinConfigure(GPIO_PA0_U0RX); GPIOPinConfigure(GPIO_PA1_U0TX); ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1); //PinTypeUART is equivalent to: //GPIODirModeSet(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1, GPIO_DIR_MODE_HW); //GPIOPadConfigSet(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD); #endif // Enable the GPIO pins for the LED (PF2). #if CMSIS - 0 GPIOF->DR2R |= GPIO_PIN_2; GPIOF->DEN |= GPIO_PIN_2; GPIOF->DIR |= GPIO_PIN_2; #if 1 { /* HardFault exception raised if there isn't a delay here */ volatile uint16_t dd = 0; while (--dd); } #endif #else ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_2); // Above is equivalent to: //GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_2, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD); //GPIODirModeSet(GPIO_PORTF_BASE, GPIO_PIN_2, GPIO_DIR_MODE_OUT); #endif That last one is interesting; may be that driverlib's slowness obscures a bug (or may be that they're relying on it being slow to avoid having to put in some delay that I don't know about). 
    The CMSIS version, using my build environment, drops from 3024 code bytes to 2812 code bytes (the original with TI's ldscript is 1720 bytes, but I've got some extra stuff in mine to help diagnose problems).
     
    If TI would provide a supported CMSIS environment, I'd definitely use it instead of driverlib. Which, as @@bluehash pointed out earlier, is probably part of why they don't provide CMSIS.
  9. Like
    Vin255 reacted to Bingo600 in Extremely simple ARM assembly example with Tiva C?   
    Have a look here
     
    He's got some small examples
    http://users.ece.utexas.edu/~valvano/arm/
     
    /Bingo
  10. Like
    Vin255 reacted to pabigot in Understanding ARM based controller (stellaris) through driverlib or through registers   
    The approach I'm taking will probably only work with arm-gcc (maybe CodeSourcery too).  It uses an external MCU-specific file to provide the contents of the vtable so the startup file is shared,  and the same external memory.ld file I used in MSP430 so the linker script is shared.  It uses CMSIS 4.0 standard global handler names, instead of TI's names; driverlib/sensorlib should work, but the TivaWare examples will probably need to be edited.  It also sucks in more of the standard arm-gcc CRT infrastructure than TI's setup, increasing base code size by about 1 kiB, which is something that bothers me and I'm investigating to see if there's value there.
     
    In any case, I want this to work with EFM32, Tiva-C, and the CC2538, so that's the requirement I'm working towards.  At the moment I have no evidence it can't be done, but I won't push anything out until I have confirmed solutions on those three platforms, which might be a week or two since I'm finding it really demotivating to have to keep spending time fixing up infrastructure instead of doing something cool.  (Control issues?  No, I don't have control issues....)
  11. Like
    Vin255 reacted to zborgerd in We need more posts!   
    Just my personal opinions on the subjects.
     
    I think that the forums for all three of your TI chip sites should be merged.  I've alays felt that three sites with many of the same userbase makes it more difficult to collaborate.  43oh is a great site and has such a large base, and many projects are shared between all three platforms.  This is especially true since most users work with the various Launchpad parts.  You could still have separate portal sites, if you wish, but the forums should be combined with separate sections for each chip.  For example, AVRFreaks has the AVR8 and 32 products in a single forums.  Some of the stuff, like "Test Equipment Deals" and "Buy / Sell / Trade" are generic.  I tthink that you are already even forwarding some of these to 43oh currently.  But that just requires registration on multiple sites.
     
    My thoughts:  Giving all 43oh forum members immediate forum access to to posts and info on both of these 32-bit architectures would immediately jumpstart interest in both sites.  Migrate all (non-duplicate) C2kCentral and Stellarisiti users over to 43oh forums, and merge the existing database content for these two sites into new forum sections.  Or, just do the database post content.  There are so many users here that are already on all three sites that it might be easiest to just have people re-register.
     
    As for the C2000, there is no real incentive right now to use the chip for most projects.  ARM support is very good on all platforms, as is MSP430.  In spite of its benefits, C2000 is a pain to use due to a lack of GNU tools and a mechanism to debug without CCS.  Additionally, just about everyone is only using ARM for 32-bit projects these days.  The C2000 is powerful and has many good applications, but unless it can get a larger userbase, it will probably fade into obscurity in the same way that many other MCU companies are dumping their other 32-bit cores as they migrate to ARM.  Additionally, the C2000 Launchpad is more expensive compared to the other two Launchpads and many of the other ARM low-cost project boards.  Most people have managed to obtain STM32 Discovery boards for free through promos.  We know that the MSP430 Launchpad has always been an outstanding deal.  And the Stellaris Launchpad had great intro pricing in spite of delivery delays.  I've picked up several of each.  I have a Piccolo stick, but haven't felt any desire to pick up a C2000 Launchpad.  By comparison, I love the MSP430 and Stellaris Launchpad boards and work with them often.
     
    TI contracted Mentor / Code Sourcery to write a GCC port for C6X with GCC 4.7, but support for lower-end TMS320 chips was mysteriously ignored.
     
    The C2000 Launchpad part is simply not well-positioned for hobbyist projects.  I know that $17.00 is not that much money, but a hobbyist is going to probably pick up the option that is only 1/2 or 1/3 of the price, especially if the other chips are better-supported with example code, and code is generally more portable.  Unless you have a project for motor or power control, the C2000 is probably not the best part for a hobbyist to use.  Higher-end TMS320 chips seem to have better overall support, but even OMAP has been rumored to have a questionable future.
     
    As an example, I can largely reuse well-established ARM code across both my TI Stellaris and my STM32-based projects with GCC.  Need an RTOS with C2000?  You pretty much have TI RTOS / BIOS.  Need an RTOS for ARM Cortex M4F?  Take your pick.
  12. Like
    Vin255 reacted to spirilis in Understanding ARM based controller (stellaris) through driverlib or through registers   
    Be sure to:
     
    #define TARGET_IS_BLIZZARD_RB1
    (for TM4C123)
    or #define TARGET_IS_SNOWFLAKE_RA0
    (for TM4C129)
     
    before including "driverlib/rom.h"
     
    That should do the trick.
     
    FYI, if you are using TivaWare 2.1 (latest), you might want to get in the habit of using the new TARGET_IS #define's instead:
     
    #define TARGET_IS_TM4C123_RB1
    or
    #define TARGET_IS_TM4C129_RA1
     
    Those #define's, btw, inform the driverlib/rom.h which ROM functions are actually available since they differ from subfamily to subfamily.  (mainly going from TM4C123 to the new TM4C129; the available functions differ slightly, as the clock system has changed)
     
    Example (pre-TivaWare 2.1 here, so I'm using #define TARGET_IS_BLIZZARD_RB1)
    /* ssi_hello.c */ // needed for driverlib rom stuff #define TARGET_IS_BLIZZARD_RB1 1 #include <stdint.h> #include <stdbool.h> #include "inc/tm4c123gh6pm.h" #include "inc/hw_types.h" #include "inc/hw_memmap.h" #include "driverlib/sysctl.h" #include "driverlib/rom.h" #include "driverlib/rom_map.h" #include "driverlib/gpio.h" #include "driverlib/pin_map.h" #include "driverlib/ssi.h" int main() { uint32_t spiword; MAP_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ); // 80MHz CPU; speed is calculated as 200MHz/SYSDIV MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB); MAP_GPIOPinConfigure(GPIO_PB4_SSI2CLK); MAP_GPIOPinConfigure(GPIO_PB6_SSI2RX); MAP_GPIOPinConfigure(GPIO_PB7_SSI2TX); MAP_GPIOPinTypeSSI(GPIO_PORTB_BASE, (GPIO_PIN_4 | GPIO_PIN_6 | GPIO_PIN_7)); MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI2); MAP_SSIConfigSetExpClk(SSI2_BASE, MAP_SysCtlClockGet(), SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, 1000000, 8); MAP_SSIEnable(SSI2_BASE); spiword = 0xA5; MAP_SSIDataPut(SSI2_BASE, spiword); MAP_SSIDataGet(SSI2_BASE, &spiword); spiword = 0x55; MAP_SSIDataPut(SSI2_BASE, spiword); MAP_SSIDataGet(SSI2_BASE, &spiword); while(1) ; } Note if you also #include "driverlib/rom_map.h" you get MAP_ versions of each call, which automatically get replaced with the ROM_ version if it's available or uses a flash-built copy (e.g. "SSIEnable()" rather than "ROM_SSIEnable()") if it's not.  In practice this probably isn't necessary... since all the driverlib stuff is in ROM.
  13. Like
    Vin255 reacted to spirilis in Understanding ARM based controller (stellaris) through driverlib or through registers   
    I've heard there's an up and coming Open Source library called libopencm3 (formerly libopenstm32?) that aims to become a unified driverlib for multiple Cortex-M families. I think someone here started a port for the LM4F/TM4C series too. @@Rickta59 told me about it on IRC. But one disadvantage is this library won't be in ROM so it will take up flash space and run a tad slower at high speeds (due to flash wait states that don't apply to the onboard ROM) - whether this makes any darned difference remains to be seen IMO. Probably not.
     
    So if you have misgivings about driverlib, maybe give that a peek and/or make it better for us
  14. Like
    Vin255 reacted to igor in Understanding ARM based controller (stellaris) through driverlib or through registers   
    Are you interested in the CPU architecture (ARM, etc. which would apply to most any Cortex M4F)  Or are you interested in understanding the details of the peripherals (TI).
     
    If you want the CPU architecture (instruction set, registers, etc.) then driverlib doesn't matter for the most part.  (Basically want information on assembly programming for ARM.)
    If you are interested in the particulars of TI's peripherals, then read the TI documentation on the processor, and study the library source code (driverlib and probably CMSIS as well).
    (The driver library code gives examples of how to program the peripherals at a low level.)  Of course the particulars of these peripherals only apply to whatever family of
    processors TI puts them in, so may not be a lot of point in delving in to that level unless you need to do something that the libraries don't offer.
     
    (e.g. the CAN peripheral can do loopback, but the libraries don't provide a way to do that.  So I put together a function that just enabled/disabled the loopback,
    but use the libraries for the rest.)
  15. Like
    Vin255 reacted to Lyon 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
  16. Like
    Vin255 reacted to ganapathi in Timer overflow interrupt in edge-time mode   
    #include "inc/hw_ints.h"
    #include "inc/hw_memmap.h"
    #include "inc/hw_types.h"
    #include "driverlib/sysctl.h"
    #include "driverlib/interrupt.h"
    #include "driverlib/gpio.h"
    #include "driverlib/timer.h"
    Hi im using stellaris launchpad and was trying to enable the timer overflow flag when the timer is configured as capture edge-time mode?
    is this possible?

    when i execute the below code timer overflow interrupt is never called. on negitive edge on the pin calls the interrupt.
    Any help on what im doing wrong

    Thanks in advance

    #define  PART_LM4F120H5QR true


    int main(void)
    {
      unsigned long ulPeriod;


      SysCtlClockSet(SYSCTL_SYSDIV_5|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);


      SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
      SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);


      SysCtlPeripheralEnable(SYSCTL_PERIPH_WTIMER0);




    //Pc4 is used for capture


      GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_2);
      GPIOPinConfigure(GPIO_PC4_WT0CCP0);
      GPIOPinTypeTimer(GPIO_PORTC_BASE, GPIO_PIN_4);


      GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, 0);




      TimerControlEvent(WTIMER0_BASE, TIMER_A, TIMER_EVENT_NEG_EDGE); // Neg edge count
    // timer confgures to run as 32 bit and capture mode
      TimerConfigure(WTIMER0_BASE,TIMER_CFG_SPLIT_PAIR|TIMER_CFG_A_CAP_TIME);


      TimerLoadSet(WTIMER0_BASE, TIMER_A, 0x0000FFFF);


      IntEnable(INT_WTIMER0A);


      TimerIntEnable(WTIMER0_BASE,TIMER_CAPA_EVENT|TIMER_TIMA_TIMEOUT);
      IntMasterEnable();


      TimerEnable(WTIMER0_BASE,TIMER_A);


      while(1)
      {
      }
    }


    void wTimer0IntHandler(void)
    {
    // Clear the timer interrupt
    TimerIntClear(WTIMER0_BASE, TIMER_TIMA_TIMEOUT|TIMER_CAPA_EVENT);


    // Read the current state of the GPIO pin and
    // write back the opposite state
    if(GPIOPinRead(GPIO_PORTF_BASE, GPIO_PIN_2))
    {
    GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3, 0);
    }
    else
    {
    GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, 4);
    }
    }


×
×
  • Create New...