Jump to content
43oh

squalyl

Members
  • Content Count

    18
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by squalyl

  1. Else you will need 16+ GPIOs to drive the data bus, RD, WR, CS, etc... http://en.wikipedia.org/wiki/Parallel_ATA

     

     

    A digital audio stream is at least 44100sps * 2ch * 2bytes/sample = 176400 bytes per second that will have to be sent to an audio DAC via I2S.

    This seems doable but not interesting.

     

    You can still use the IDE interface to emit audio playback events (start, stop, seek) and read the TOC (track duration etc) but you'd better use a cd drive with an analog output. it was quite common in the IDE days. Some of them even have a TTL SPDIF output.

  2. hello

     

    I'm playing with my stellaris launchpad, I got openocd 0.7.0 working and I'm trying to write my own GPIO init code.

    I wrote this generic routine to initialize the uart pins.

     

    I've defined several flags, and according to the value of these flags, I'm attempting to write the appropriate GPIO configuration registers.

     

    For that, I'm using the AHB access method, writing to BASE+OFF where

     

    OFF is the offset of the required register (eg #define LM4F_GPIO_GPIODIR       0x400   // GPIO Direction)

     

    BASE is 0x40058000 + (port<<16)

     

    I'm using this because it's easier to compute the port base address.

     

    Note that this method is using the AHB bus.

    The other method, which I'm not using, relies on the APB bus, with a different base address, and an ugly hack for PE and PF.

     

    However, this does not work, what I get is a hardfault. With a combination of google searches, I've managed to determine that

    (hfsr = 1073741824= 0x40000000) => this is a forced hard fault

    (cfsr = 33280 = 0x00008200) => BFSR=0x82 this is an unhandled Bus Fault, BFAR is valid and this is a precise data bus error.

    PC correctly points to the faulting instruction, which is

    ldr    r1, [r2, #0]
    with:

    r2 = 1074103296 = 0x40058400

    which is the GPIO register I'm trying to read, before changing it and writing it back later.

    I can confirm this is the failing address because

    bfar = 1074103296 = 0x40058400

     

    Okay...

     

    So I'm wondering WHY I can't access the GPIO registers this way. Is this an "errata issue" ?

    Do I have to set something up before accessing AHB registers?

     

    I have already set the correct bit in the the RCGCGPIO register at 0x400FE000 + 0x608 with no problem, so the GPIO peripheral shall be working.

     

    Do you have any idea before I rewrite my code to use the APB?

     

    (please don't tell me that stellaristupperware already does this, because in my context, I cannot and will not use that).

     

    Best regards :)

     

    edit: this should work, see here: http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/60248.aspx

     

    edit 2: SysCtlGPIOAHBEnable(SYSCTL_PERIPH_GPIOF);

     

    haha. I knew it. Now I need to write code for that. Going to read the datasheet again.

  3. hello,

     

    I had the idea to start a french stellaris forum. But I have no time to manage it properly, and the activity is not so high, so I closed it.

     

    So I think a multilingual section is a more efficient way of doing things.

     

    Then maybe, could I redirect my DNS entry to the french speaking section?

  4. I just did like the github project.

     

    TARGET=arm-none-eabi

     

    the prefix is /opt/stella

    Do you have a preference for $PREFIX?

     

    the binaries have "natural" names, do arm-none-eabi-gcc et al.

     

    I know one can create a relocatable toolchain so that it does not depend on the prefix and can be installed elsewhere, I don't remember how to do this at the moment.

     

    I also cross-built binutils for mingw, working on gcc now.

  5. Based on the makefile from the github project above, I could build a native "vanilla" toolchain from official sources, with just two little glitches:

     

    -I have to manually create a $PREFIX/arm-none-eabi/usr/include folder before building gcc the second time, or it won't build! (but nothing gets installed there) I get a pretty message: "the directory that should contain system headers does not exist", but no one on the intarwebs seems to have a satisfying solution. I don't want to patch sources, the goal is to build from official tarballs.

     

    -ld cannot find crt0.o when running arm-none-eabi-gcc trivial.c (with an empty main function), but gcc -c does work. That may not be required for our platform.

     

    I used:

    binutils 2.22

    gcc 4.7.2 (dependencies gmp 5.0.0 and mpfr 3.1.1)

    newlib 1.20.0

     

    I will retry the build in a clean VM in an attempt to reproduce the issues, then attempt to cross build the toolchain for mingw. I did that before for cegcc.

  6. Hello from france here also.

     

    After a private discussion with bluehash, I have installed a french stellaris community at http://www.openstella.fr

     

    It's meant to be the french-speaking "arm" of this board, with a specific focus on open and free(as speech) tools and projects.

     

    For the moment it's empty but I'm busy writing some tutorials and explanations, while I'm waiting for my boards!

     

    Anyone is welcome on this board to share projects in french language. We plan to relay, with permission, useful information found on this board, with credits where due, to help promote this wonderful board to more people and encourage projects.

     

    Regards.

  7. hello,

     

    I've not yet received my stellaris boards, but I'm already starting to dig in the code.

     

    The Codesourcery toolchain seems to be a "lite" version; do you know what the restrictions are?

     

    And what is preventing anyone of us to build an arm toolchain from sources?

     

    regards

×
×
  • Create New...