Jump to content
43oh

Lyon

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Lyon

  1. Hi, The main problem with 129 series when migrating software is system clock setting, which changed a lot - new options for PLL settings at 320/480MHz - so check the system settings clock and to be sure it works correctly. But as no inside is available for measuring frequency, the best idea is to use either UART and see if working OK or a PWM generating a prescribed waveform. Also you can check the Tiva software, code is open. The example program qs-iot uses ADC, sample sequencer 3 to measure temperature. L
  2. Hi, @@pabigot, It would be interesting to see (if you can post) some 5-6 .asm instructions before your "nop" and 1-2 instructions after. Could be just pipe line flushing, so that behavior of 3 cycles delay. Also replacing with a mov rx,rx could reveal something interesting. Regards, L
  3. Hi, In my previous post about "nop" I indicated the CCS syntax since that was the user's IDE. The operation (behavior) should be the same on all systems, since all should have in mind the core hardware, as licensed by ARM. If you need extremely short delays, one system clock, best idea is to use .asm instructions like "mov r5,r5", which does not harm or push/pop combination. NOP is treated by ARM as 'hint' instruction, which does not necessarily do something. L
  4. Hi, Nothing new under the sun, just weird things: the below comments are from peripheral driverlib/sysctl.c file: SysCtlPWMClockGet: //! This function returns the current PWM clock configuration. //! //! \return Returns the current PWM clock configuration; is one of //! \b SYSCTL_PWMDIV_1, \b SYSCTL_PWMDIV_2, \b SYSCTL_PWMDIV_4, //! \b SYSCTL_PWMDIV_8, \b SYSCTL_PWMDIV_16, \b SYSCTL_PWMDIV_32, or //! \b SYSCTL_PWMDIV_64. So no frequency, just configuration. Just check for your case - help yourself with the user manual Regards, L
  5. Hi, Please review your post - you used twice the word "SysCtlPWMClockGet" - Also can you tell us what Tiva library version do you use? L
  6. Hi, Please see this package: http://www.ti.com/tool/sw-ek-lm3s3748 has a nice oscilloscope implementation, with USB. Maybe not the fastest in the world, but could be a good starting point for improving. Full code available, drivers... L
  7. Hi, I think is a problem of paths. But to solve it, you must first import a good working project, made by TI - go to Project | Import CCS projects.. and just import one, even qs_iot - and then do several things: - compile it and be sure you do not get any errors (just tested that on my version 6.0 and compiles OK). - open Project | Properties and look to all settings - learn, note down and keep this project for further reference. - On the left side of the IDE, in Project Explorer, expand all folders one by one and look for files which have a small arrow to NW near the file's icon - these a
  8. Hi, This code is part of application qs_ek-lm3s6965 - it uses a sys timer interrupt at 10 ms to make several things, including scanning all switches. You may read the .c file for all variables declared there and their meaning. Mainly it uses a static variable and a temporary one; XORing both determines if a switch was pressed or not. ulData is the state of switches - please note how different ports (E and F) are read and mixed to have all five switches info in a single variable. The last ulDelta has a 1 for a pressed switch ( inverted info in previous stages, since the real info is a 0 ) -
  9. Hi, Read this - is an excerpt from the application qs_ek-lm3s6965.c file: // // Read the state of the push buttons. // ulData = (GPIOPinRead(GPIO_PORTE_BASE, (GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3)) | (GPIOPinRead(GPIO_PORTF_BASE, GPIO_PIN_1) << 3)); // // Determine the switches that are at a different state than the debounced // state. // ulDelta = ulData ^ g_ucSwitches; // // Increment the clocks by one. // g_ucSwitchClockA ^= g_ucSwitchClockB; g_ucSwitchC
  10. Hi, I understand - first step is to use a uniform timing for all switches - and only one timing, not separate times for each switch. I presume you got into this by the fact you have to scan PF1 which is on separate port. But I think there is a possibility to manage that - allow me some time to think. Also you can reduce the scanning interval - 100 ms is too much - 10 ms would be better, since actual switches need only 1 ms debuncing time (data sheet). L
  11. Hi, To initialize PF1: GPIOPinTypeGPIOInput(GPIO_PORTF_BASE, GPIO_PIN_1); GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_1, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU); And yes, you may have problem(s) scanning... L
  12. Hi, If you use the development board, the buttons are placed on PE0…PE3, but you changed from PE1… maybe is a custom board... Try this in your initialization: // // Configure the GPIOs used to read the state of the on-board push buttons. // GPIOPinTypeGPIOInput(GPIO_PORTE_BASE, GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3); GPIOPadConfigSet(GPIO_PORTE_BASE, GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU); L
  13. Hi, OK, my misunderstanding, due to this line: // Enable the GPIO pins for digital function (PF0). About your code - I have doubts it works correctly - once the "state" variable is set up, the other cases do not check other buttons - maybe removing the break statement will restore the whole scanning (or better to think different and re-write this task). L
  14. Hi, The first obvious thing seen from your code is the PF0 needs a special treatment, since this pin is NMI enabled by default, so you must revert it to true GPIO behavior by unlocking it with the following code: HWREG(GPIO_PORTF_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY; HWREG(GPIO_PORTF_BASE+GPIO_O_CR) |= 0x01; GPIOPinTypeGPIOInput(GPIO_PORTF_BASE,GPIO_PIN_0); You can simplify your code - no need for separate timers for each button - just play with all at once and if a button is pressed, just send a message. L
  15. Hi, First thing: did you debounced all buttons? Any mechanical switches must be debounced. Second: can you post a code snippet to see where the real problem is? Just "not working" does not say much to think about. L
  16. Hi, Here is my solution, for changing pins 1 and 2. Adapt for your case: static uint8_t ledonoff; GPIOPinWrite(GPIO_PORTF_BASE, \ (GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3), \ ledonoff^=(GPIO_PIN_1 | GPIO_PIN_2)); L
  17. Hi, As far as I know, a LED has only one pin to act on (beside the other which is at fixed potential, either Hi or Lo) - why do you "must" and on what pin is the LED mounted on? what about the other pins in your expression? L
  18. Hi, You said you use "mplab" - if this means Microchip, then you are on a wrong forum - here we share knowledge about TI's ARM Cortex-M4 micro controller. But the good news is you can find how to solve your problem in this link: http://www.8051projects.net/lcd-interfacing/lcd-custom-character.php - do no wary if about 8051, just got the idea. L
  19. 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
  20. Hi, Maybe it will be useful to show console window when there are errors, rather than problems window (shows the stage when the error occurred) - first it would be wise to upgrade to last version, 5.5 (although I understand that there is also version 6.0, but I did not checked that up to now). Second, there is something missing, "-l" is for a library to be specified in linker settings - check a good working Tiva project and compare with yours - (lm, lc,) L
  21. HI, It will be a little cheating, but for learning purposes will work, as long as nobody knows what you have done: just compile the driverlib routine write_to_flash, generate a listing and try to understand how the writing should be done, then adapt it for your needs. L
  22. 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
  23. Hi, Yes, there is not a constant TIMER_A (or if it is) it has not the value 35 needed to specify the vector interrupt location 35 in vector interrupt table. Simply the interrupt is not taken because it is not found. The correct interrupt number is to be found in file hw_ints.h. L EDIT: found it - TIMER_A is specified and has the value 255, not 35, so the interrupt vector is not taken (more likely to generate a hard fault..)
  24. Hi, Mircea, when defining interrupts number, that one for timer A is Timer 0 sub timer A, so your call to enable interrupts for timer 0 A should be: IntEnable(INT_TIMER0A); @ example was good, - compare with yours. L
  25. Lyon

    SSI and LM4F120XL

    Even worse - to specify an address then should set bit 6 to 1- of coarse by ORing with 0x40. L
×
×
  • Create New...