Jump to content

Vin255

Members
  • Content Count

    14
  • Joined

  • Last visited

About Vin255

  • Rank
    Member

Profile Information

  • Gender
    Male
  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 today have modified Harvard architecture with separate data and instruction cache and separate data and instruction buses. Data and instructions in the same memory. I want to clear some basic concepts. thanks a lot. Vin255
  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 address of 0x4002.5020 the value of 0x08 is written. 2. I can do the same using GPIO_PORTF_DATA_R |= 0x08; // where GPIO_PORTF_DATA_R = 0x4002.53FC as defined in lm4f120h5qr.h Here all the bits of address line [9:2] are set as 1. Therefore whatever value on the right hand side, it is stored in the correct location. My question here is the addresses are different in both the approaches but correct values goes into correct position! the green led is ON. Can anyone please clarify this doubt for me. Thanks a lot. Regards Vin255
  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 architecture, for ex: stellaris LP) by register we can understand and appreciate the complexity of the architecture. Here, I have bought stellaris launchpad from online store just to get in-depth knowledge of M4. In future, if I want to program any other controller then I will just be using only the driver libs but here I want to try register level also since this is my first ARM controller programming. Thanks for your views: regards Vin255
  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 programming in parallel so that a good understanding of ARM cortex M4 is obtained since this is my first experience with an ARM controller. And also, APIs are not efficient in size and speed. 2. I know that to program a peripheral lot of registers have to be programmed in a specific order. My plan is to understand this order by going through the APIs and then trying to repeat the same through the registers. Does it make sense? Thank you regards Vin255
  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 approach good or some other approach is needed? 2. I tried to understand the assembly code of my prog in the disassembly. Its complicated . I couldnt find certain instruction from the manual for ex; BCC.N ??main_1 // this will jump to label main_1 when negative flag is raised. ( .N indicates this) but I couldnt find this instruction in the instruction set of manual. Thank you. Regards Vin255
  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 launchpad. Is there any solution for this? I have read that by prefixing ROM_ to APIs we can call the functions from the ROM and save flash memory. I tried it but the function is undefined. I'm missing something here. Thanks! Regards Vin255
  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 with examples of stellaris, especially without the APIs so that internal complex architecture of ARM (cortex M4F) can be understood. Thanks & Regards Vin255
×
×
  • Create New...