Notice

The forum is in read only mode.

newlib (stdc) + uart + petit_fat integration

PhracturedBlue
Offline

04 Aug 2012 22:16 - 04 Aug 2012 22:16 #880 by PhracturedBlue

Replied by PhracturedBlue on topic newlib (stdc) + uart + petit_fat integration

Looks like you made great progress.
If you haven't noticed, petit_fat doesn't let you resize the filesize. I cheat by zeroing the last 12bits (which is legal because I inverted the filesystem in spi_flash, so I can write 000 to the flash FAT record and it results in a 4095byte file.
since all bytes are guaranteed to read as '0' that haven't been written, ini.c will stop on the 1st one.

Last edit: 04 Aug 2012 22:16 by PhracturedBlue.

PhracturedBlue
Offline

07 Aug 2012 15:41 - 07 Aug 2012 15:42 #945 by PhracturedBlue

Replied by PhracturedBlue on topic newlib (stdc) + uart + petit_fat integration

I'm having a really difficult time building the firmware on Windows. Mostly I can't seem to get a good compile toolchain that works properly.
I've tried building manually as well as pre-compiled, and have run into various issues.
I'm now trying a full build of the current summon-arm-toolchain (I previously followed the directions here: www.microbuilder.eu/Tutorials/SoftwareDe...ingGCCToolchain.aspx , but it doesn't have the necessary patches to work properly). Unfortunately compiling on mingw is extremely slow, and it takes something like 10 hours to build through the whole toolchain. Hopefully this time it will work

Edit: oops, I meant Windows

Last edit: 07 Aug 2012 15:42 by PhracturedBlue.

FDR
Offline

07 Aug 2012 15:52 #946 by FDR

Replied by FDR on topic newlib (stdc) + uart + petit_fat integration

Jeez, 10 hours!

At home on my Vista the compilation is quite slow, however on the XP at work is acceptable...

wuselfuzz
Topic Author
Offline

07 Aug 2012 16:17 #947 by wuselfuzz

Replied by wuselfuzz on topic newlib (stdc) + uart + petit_fat integration

You could as well grab VMWare Player and build on Linux.

What about yagarto? www.yagarto.de/

wuselfuzz
Topic Author
Offline

07 Aug 2012 16:24 #948 by wuselfuzz

Replied by wuselfuzz on topic newlib (stdc) + uart + petit_fat integration

I tried compiling the firmware with -O3 again, it still doesn't work after I added a couple of fixes.

Compiling with optimizer also results in a bunch of uninitialized values warnings.

PhracturedBlue
Offline

07 Aug 2012 16:28 #949 by PhracturedBlue

Replied by PhracturedBlue on topic newlib (stdc) + uart + petit_fat integration

10hrs is for the build building binutils/gcc/newlib, not deviation. the problem is that 'configure' is REALLY slow in mingw due to the fork penalty.

well, ideally, I want a 'summon' built toolchain. There are several patches to gcc that we want (removal of unwind code for instance). I tried a frankenstein approach of mixing my summon libgcc.a with a pre-built gcc, but the build didn't actually work on the Tx. Yagarto has not been kept up to date as far as I know. I tried using it once (on linux) and was unable to compile libopencm3 for instance.

I may try cygwin. I believe it doesn't pay as much fork penalty as mingw does (though it is slower in many other situations)

I already use a virtualbox setup myself on my Windows machine to boot an Ubuntu image. I may get to the point where that is what FDR needs to use to build, but I'm going to try building the summon toolchain one more time 1st.

PhracturedBlue
Offline

07 Aug 2012 16:32 #950 by PhracturedBlue

Replied by PhracturedBlue on topic newlib (stdc) + uart + petit_fat integration

I had -Os working at one time. It saved a lot of space compared to a regular build. I see it still compiles fine, though I didn't try loading it onto the Tx. Using -Os (without -g) was may plan for production releases

wuselfuzz
Topic Author
Offline

07 Aug 2012 16:35 #951 by wuselfuzz

Replied by wuselfuzz on topic newlib (stdc) + uart + petit_fat integration

As long as everything fits, I'd use -O2 instead of -Os for a possibly higher refresh rate.

-O3 is a killer, though, that will inline a lot of functions in my experience and create HUGE code.

The optimized version crashes pretty early on, no UART output at all.

PhracturedBlue
Offline

07 Aug 2012 16:50 #952 by PhracturedBlue

Replied by PhracturedBlue on topic newlib (stdc) + uart + petit_fat integration

Well, we can try, but refresh speed is almost entirely based on the bandwidth of the FSMC and SPI links. I don't think performance will mater much.
The current code compiles:
118kB -Os
131kB -O1
126kB -O2
156KB -O3

So it isn't like we are in trouble space-wise yet

wuselfuzz
Topic Author
Offline

07 Aug 2012 17:17 #953 by wuselfuzz

Replied by wuselfuzz on topic newlib (stdc) + uart + petit_fat integration

Found the issue with the optimizer.

Global variables that are modified in an interrupt should always be declared volatile! I did this for Channels[] in an earlier version today, but there's also the tick timer msecs.

volatile makes sure that the value is actually read on memory when you use the variable, so the optimizer doesn't assume that the variable never changes.

This

    /* wait for system to start up and stabilize */
    while(msecs < 100)
        ;

is an endless loop with -O2/-O3, unless msecs is declared volatile.

PhracturedBlue
Offline

07 Aug 2012 18:06 #954 by PhracturedBlue

Replied by PhracturedBlue on topic newlib (stdc) + uart + petit_fat integration

wuselfuzz wrote: Found the issue with the optimizer.

Global variables that are modified in an interrupt should always be declared volatile! I did this for Channels[] in an earlier version today, but there's also the tick timer msecs.

Channels[] shouldn't be modified in an interrupt and should not need that change.
msecs certainly does need it.

wuselfuzz
Topic Author
Offline

07 Aug 2012 18:08 - 07 Aug 2012 18:09 #955 by wuselfuzz

Replied by wuselfuzz on topic newlib (stdc) + uart + petit_fat integration

But Channels[] is read in the timer interrupt sending out radio packets. Same rules apply here, the optimizer can't follow the code path. A variable that is only ever written (ok, Channels[] is read at other places, but that's not a given) could be completely removed.

Last edit: 07 Aug 2012 18:09 by wuselfuzz.

PhracturedBlue
Offline

07 Aug 2012 18:11 #956 by PhracturedBlue

Replied by PhracturedBlue on topic newlib (stdc) + uart + petit_fat integration

There is no way for channels to change while in the interrupt handler, so it doesn't need to be optimized as volatile. The purpose of volatile is to tell the compiler that between 2 reads the variable may have changed due to thread-switch or interrupt. That should not be possible with Channels[]
only variables that are written in the interrupt and read from the main code need this flag.

FDR
Offline

07 Aug 2012 18:46 #957 by FDR

Replied by FDR on topic newlib (stdc) + uart + petit_fat integration

PhracturedBlue wrote: 10hrs is for the build building binutils/gcc/newlib, not deviation.

Yep, I know, but they talked about some 90 minutes in the linked doc...

FDR
Offline

07 Aug 2012 18:47 #958 by FDR

Replied by FDR on topic newlib (stdc) + uart + petit_fat integration

Well, I don't insist on building the dfu myself!
You can supply one time to time...

PhracturedBlue
Offline

08 Aug 2012 03:37 #963 by PhracturedBlue

Replied by PhracturedBlue on topic newlib (stdc) + uart + petit_fat integration

Ok, wuselfuzz was right. YAGARTO was the way to go. I've updated the README with build instructions.
If you run into problems, you can download a ready-to go toolchain here (just unzip it into C:\mingw)
deviationtx.com/downloads/stm32.zip
I'm not sure how much spce we have, so if that 50MB file is too big, feel free to remove it. I also put it on a freebie site here:
www.filedropper.com/stm32

FDR
Offline

08 Aug 2012 05:41 - 08 Aug 2012 05:42 #965 by FDR

Replied by FDR on topic newlib (stdc) + uart + petit_fat integration

Can't make the libopencm3.
Is it because of the PREFIX in the makefile?

FDR@FDR-PC ~/src/libopencm3
$ make
  BUILD   lib/stm32/f1
  CC      vector.o
make[1]: arm-none-eabi-gcc: Command not found
make[1]: *** [vector.o] Error 127
make: *** [lib] Error 2

...or my path to the stm32 is not valid?

Last edit: 08 Aug 2012 05:42 by FDR.

PhracturedBlue
Offline

08 Aug 2012 05:48 #966 by PhracturedBlue

Replied by PhracturedBlue on topic newlib (stdc) + uart + petit_fat integration

FDR wrote: Can't make the libopencm3.
Is it because of the PREFIX in the makefile?
FDR@FDR-PC ~/src/libopencm3
$ make
  BUILD   lib/stm32/f1
  CC      vector.o
make[1]: arm-none-eabi-gcc: Command not found
make[1]: *** [vector.o] Error 127
make: *** [lib] Error 2
...or my path to the stm32 is not valid?

your path isn't right.
if you set your path in .profile, you need to restart your terminal.
otherwise, something else is wrong with it. what does 'echo $PATH' show?

I just noticed my instructions are wrong. it should be:

export PATH=/mingw/stm32/bin:$PATH

wuselfuzz
Topic Author
Offline

08 Aug 2012 07:08 #967 by wuselfuzz

Replied by wuselfuzz on topic newlib (stdc) + uart + petit_fat integration

Mirrored the toolchain on my server:

wuselfuzz.de/stm32.zip

I have 2 TB free traffic, bring it on.

FDR
Offline

08 Aug 2012 09:57 #968 by FDR

Replied by FDR on topic newlib (stdc) + uart + petit_fat integration

PhracturedBlue wrote:
FDR wrote: ...or my path to the stm32 is not valid?
your path isn't right.
if you set your path in .profile, you need to restart your terminal.
otherwise, something else is wrong with it. what does 'echo $PATH' show?

I just noticed my instructions are wrong. it should be:
export PATH=/mingw/stm32/bin:$PATH

Yep, I've found that too. Please correct the instructions for the rest who will try...
The compile succeeded (however with quite a few warnings), and I could build the dfu. Looks valid, but I can try it only later at home...

Time to create page: 0.059 seconds

Force desktop display