Jump to content


  • Content Count

  • Joined

  • Last visited

About Vin255

  • Rank

Profile Information

  • Gender
  1. many many thanks L.R.A and igor. both the posts have solved most of the doubts! ok, so only we have: static const char myname[] ={"Vin"}; to keep the array in flash since we know that this variable is not intended to be changed in the prog. and save some space on the RAM which is small. If I get some doubt again, I will continue here.Thanks once again:-) Regards Vin255
  2. Hello all, I have few concepts which I need to clear! Please provide your important experience and knowledge. I keep on reading different controllers with different ratings of flash memory and SRAM. MSP has FRAM. Queries; 1. Usually flash memory is usually much larger than SRAM, because of cheaper price? 2. I know that prog is stored in flash and variables in SRAM. But the variable can be stored in flash also. right? 3. I know that FRAM is faster, less power consuming, longer life than flash.. Only MSP has this FRAM technology right? I know that most of the ARM controllers to
  3. Hello all 1 small query regarding Table 10-1. GPIO Pins With Special Considerations 1. Here PA[1:0] has UART0 ( a peripheral function) but the AFSEL for these pins in the table is 0. But in the description of GPIOAFSEL register: the corresponding bit is 1 for the pin to function as a peripheral function. and it is mentioned as : "The reset value for this register is 0x0000.0000 for GPIO ports that are not listed in Table 10-1 on page 650" but when I downloaded a simple code the reset value for PORTA (which is listed in the table) was 0x0000.0000
  4. Thanks for the clarification. In the example should it be GPIOF->DATA[4U << PIN] = -1; instead of 1U << PIN ? regards Vin255
  5. Hello Lyon, pabigot and others I have one question regarding the bit banding for GPIODATA. I can turn on the GREEN LED using 2 approaches: 1. In the API GPIOPinWrite(GPIO_PORTF_BASE, LED_GREEN, LED_GREEN); (Here LED_GREEN = 0x000000008 , Pin3 ) in the API definition the pins used are left shifted by 2 since in the Datasheet it is told that the address[9:2] acts as a mask to read/write values to GPIODATA HWREG(ulPort + (GPIO_O_DATA + (ucPins << 2))) = ucVal; Here ulPort = GPIO_PORTF_BASE = 0x4002.5000 GPIO_O_DATA =0, offset is 0 so at the ad
  6. @pabigot: thanks for the discussion on RMW and bit-banding. I will try to understand these terms. Yes, I accept that we need to just use the driverlib since it is practical as a beginner. I only wanted to understand the architecture. Now, reading the driver lib user guide. It is giving good overview of the architecture. In parallel, I'm going into the Data sheet to know the specific registers and their settings. Thanks regards Vin255
  7. @pabigot: oh, ok, I wish the CMSIS was supported by TI. It needs lot of experience and modifications to use directly the CMSIS. I will stick with driverlib initially. @ rickta59 an @@Lyon : I agree with both of you that there are lot of differences between different brands as you have pointed out. The reason why I want to try the register programming in parallel to driverlib is to understand the architecture of cortex m4. There are technical ref manual for the cortex architecture at ARM & TI website, but only by programming a device(a particular implementation of that architec
  8. Hi Pabigot yes, I agree about struct-pointer. I have downloaded the CMSIS files from the link and will have a look at them later. Ok, I will stick with the driverlib for now. In E2E forum they didnt even reply! Hope some one there wakes up to this confusion. The only reason why I want to program through the registers is that it will give good understanding about the complexities of ARM architecture and If we learn deeply one ARM architecture then other variants of it are almost similar. thanks. Regards Vin255
  9. @ Bingo: many many thanks for the link. very helpful. regards Vin255
  10. Hello all, The posts here indicates that people do have lot of knowledge and are willing to help. I too have lot to learn.Long way to go. I had 2 questions which is related to my initial query of programming the registers instead of using API: 1. in stellaris peripheral driverlib pdf, they have mentioned that in inc/lm4f120h5qr.h lot of address are defined for direct register access. for ex: #define GPIO_PORTA_DATA_R (*((volatile unsigned long *)0x400043FC)) Even bit masks are defined.I know APIs make things easy,safe and faster but I also wanted to learn the register level
  11. Hi Lyon thanks for your priceless guidance regarding the manuals! Yes, I'm currently reading them. Ok, I will try to run the application codes to understand the configuration. Yes, I need to understand how to find the info and where to find them. This experience will help me in future. tool chains: CCS 5.3 with the all the drivers. Even SYSBIOS is available when I open the TI Resource explorer. I will try the RTOS examples much later. Thanking you. Regards Vin255
  12. Hi spirilis Many thanks for your detail, well informed help. I now understand the ROM_ and MAP_ which I read in lot of posts.It is very clear for me now Just 2 more last guidance needed: 1. I know that we cannot keep on reading the whole user data (manual here of LM4F230H5QR is 1000+ pages) but we should learn how to find the information needed. I also agree that only by programming simple modules we can understand its working. I want to learn the modules slowly one after another. Now I learnt GPIOs, then I want to turn them ON by switches. then by timer. etc. --> Is this approa
  13. Hi Lyon, Igor and Spirilis Thanks for your views. yes, I understand how ARM just licenses the architecture. few questions: 1. @ Lyon: by user manual you mean the manual of arm cortex m4 from ARM site or the user manual of LM4F230H5QR controller in the launchpad? Or should I read both ? Ok. driverlib is the fastest and efficient to program the particular family. I get it. 2. When I checked the dissasembly my prog did not fit in the flash memory since the driverlib funcitons took most of the space in flash memory. Therefore I have to reprogram every time I disconnect the launch
  14. Hello friends, I just now got the stellaris launchpad to have hands on experience with ARM architecture. I have installed the driverlib and I can blink the LEDs through the APIs. The driverlib makes it easy to program the stellaris but with these APIs we cannot understand how the registers are programmed even when we look at the definitions of the APIs. These APIs are specific to a particular family. Thus, I wont be able to understand the ARM architecture. I request you all to please guide me regarding this problem. It would be great if I could find online training material
  • Create New...