PWM/USB?

[Charles West]

This is a very interesting project!

I would love to give it a shot for my current robotics project. However, I don't see any support for hardware PWM or USB. I could probably swap UART for USB in my current project but PWM is rather required.

If I may ask, is there something I am missing or is it currently required to be done manually?

Thanks!
Charlie West

[Freddie Chopin]

Hello Charles!

On Fri, 2019-02-15 at 19:52 -0800, Charles West wrote:
> This is a very interesting project!

Thanks (;

> I would love to give it a shot for my current robotics
> project. However, I don't see any support for hardware PWM or
> USB. I could probably swap UART for USB in my current project but
> PWM is rather required.
>
> If I may ask, is there something I am missing or is it currently
> required to be done manually?

As you noticed, there's no USB or PWM support in current version of the
HAL, which (unfortunately) is still limited - as of today it supports
only USART (regular serial port or RS-485), SPI (SPI EEPROM and SD/MMC
card connected via SPI), GPIOs (input and output), DMAs and I'm working
on SDMMC right now (this should be ready in a few days).

However it is pretty easy to integrate ST's HAL library with distortos.
It literally requires just a few easy steps - notably:
- disabling any SysTick integration in HAL (SysTick is used as system
timer for distortos);
- defining SystemCoreClock variable to proper value (distortos takes
care of setting the clock);
- reimplementing HAL_Delay() with
distortos::TickClock::sleepFor(std::chrono::milliseconds{argument});

After you integrate HAL, it is then easy to also integrate ST's USB
device library.

I have ST's USB CDC/VCP tested extensively in multiple projects based
on STM32F4 - just make sure you disable dynamic allocation from the
interrupt (they supposedly fixed that in the recent versions, but I did
not check) and it works correctly.

I did not test PWMs in ST's HAL, so I cannot tell you whether this
works out of the box or not (it should, but you never know [; ). It is
also worth noting that complete timer configuration for PWM output is
maybe 5-10 lines long, so you may easily do that without ST's HAL (or
any HAL at all).

Anyway - if you would like to try integrating ST's HAL and USB libs in
distortos-based project (and/or using PWM timers directly), I will try
to help you with that. Just let me know what chip are you using and
where do you want to start (;

Regards,
FCh

[Charles West]

Hey Freddie,

Apologies for the delay, I got bogged down in some other parts of the project before returning to this one (GPS route calculation).  My main goal is to use one of my STM32F072B discovery boards to do USB -> PWM and potentially triggering/sending back timing from some ultrasonic sensors.  Other than the USB it is a fairly simple project.

I'm compiling the recommended bleeding edge tool chain now.  I am going to try to compile the distortosTest program and try to get a hello world working on my board as a first step.

Thanks,

Charlie West

P.S.

I appreciate the offer of help!  I am very likely to ask some questions as I move forward with this (thanks).

[Charles West]

Hmm.  Compiling the bleeding edge arm build seems to have failed.  If I may ask, do you have any advice (thanks)?

/home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/installNative/arm-none-eabi/bin/ranlib libgcc.a
# Now that we have built all the objects, we need to copy
# them back to the GCC directory.  Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
make install-leaf DESTDIR=../../../../.././gcc \
  slibdir= libsubdir= MULTIOSDIR=arm/v5te/softfp
make[5]: Entering directory '/home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/buildNative/gcc-8.3.0-final/arm-none-eabi/arm/v5te/softfp/libgcc'
/bin/bash /home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/sources/gcc-8.3.0/libgcc/../mkinstalldirs ../../../../.././gcc/arm/v5te/softfp
/usr/bin/install -c -m 644 libgcc.a ../../../../.././gcc/arm/v5te/softfp/
chmod 644 ../../../../.././gcc/arm/v5te/softfp/libgcc.a
/home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/installNative/arm-none-eabi/bin/ranlib ../../../../.././gcc/arm/v5te/softfp/libgcc.a
/usr/bin/install -c -m 644 libgcov.a ../../../../.././gcc/arm/v5te/softfp/
chmod 644 ../../../../.././gcc/arm/v5te/softfp/libgcov.a
/home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/installNative/arm-none-eabi/bin/ranlib ../../../../.././gcc/arm/v5te/softfp/libgcov.a
parts="crtbegin.o crtend.o crti.o crtn.o crtfastmath.o";                \
for file in $parts; do                    \
  rm -f ../../../../.././gcc/arm/v5te/softfp/$file;        \
  /usr/bin/install -c -m 644 $file ../../../../.././gcc/arm/v5te/softfp/;    \
  case $file in                     \
    *.a)                        \
      /home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/installNative/arm-none-eabi/bin/ranlib ../../../../.././gcc/arm/v5te/softfp/$file ;;    \
  esac;                            \
done
make[5]: Leaving directory '/home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/buildNative/gcc-8.3.0-final/arm-none-eabi/arm/v5te/softfp/libgcc'
make[4]: Leaving directory '/home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/buildNative/gcc-8.3.0-final/arm-none-eabi/arm/v5te/softfp/libgcc'
make[4]: write error: stdout
Makefile:1201: recipe for target 'multi-do' failed
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory '/home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/buildNative/gcc-8.3.0-final/arm-none-eabi/libgcc'
Makefile:123: recipe for target 'all-multi' failed
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory '/home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/buildNative/gcc-8.3.0-final/arm-none-eabi/libgcc'
Makefile:11731: recipe for target 'all-target-libgcc' failed
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory '/home/charlesrwest/cpp/libraries/bleeding-edge-toolchain/buildNative/gcc-8.3.0-final'
Makefile:898: recipe for target 'all' failed
make: *** [all] Error 2

[Freddie Chopin]

On Tue, 2019-02-26 at 12:28 -0800, Charles West wrote:
> Hmm. Compiling the bleeding edge arm build seems to have failed. If
> I may ask, do you have any advice (thanks)?
>

> > make[4]: write error: stdout
> > Makefile:1201: recipe for target 'multi-do' failed

Hmm... This is something I did not ever see... Do you have enough disk
space for the whole compilation? Unfortunately the process itself takes
quite a lot of space on your drive. I'd say that 5-10 GB is required.

Could you show me the command line you executed (all the options you
passed to the script)?

What system are you using? I've found some info online that the "write
error: stdout" may be related to various things really...

https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1814393

A quick and dirty fix - find all occurences of "-j$(nproc)" in the
build-bleeding-edge-toolchain.sh script (I counted 12) and remove them,
which will effectively disable parallel builds.

Another quick solution for a while - you could try this toolchain:
http://distortos.org/files/travis-ci/arm-none-eabi-gcc-8.3.0-
190223.tar.xz

It generally should work on your PC, but there's no guarantee for
that...

Regards,
FCh

[Charles West]

I'm running Ubuntu 18.04 (64 bit). 

Commands:

git clone --recursive https://github.com/FreddieChopin/bleeding-edge-toolchain.git

cd bleeding-edge-toolchain/

./build-bleeding-edge-toolchain.sh >buildLog.txt  2>buildErrors.txt

I recompiled it again and have uploaded the build log and error log (fair warning, the build log is 200+ Mb).

Build Log:

https://drive.google.com/open?id=1ypc8VASoKBo-hwgNE-4harUqYuw2-F3I

Error Log:

https://drive.google.com/file/d/1W73ASe_39BMNTA8anyWgjlxbSGvNiQoT/view?usp=sharing

Thanks,

Charlie West

[Charles West]

Also, there is 200+ GB of disk space left after compilation so that is probably not the issue.

[Freddie Chopin]

Hello again Charles!

Sorry for the trouble you have to experience - I know that searching
for the cause and solution of such problems is extremely frustrating...

> I recompiled it again and have uploaded the build log and error log
> (fair warning, the build log is 200+ Mb).
>
> Build Log:
> https://drive.google.com/open?id=1ypc8VASoKBo-hwgNE-4harUqYuw2-F3I
>
> Error Log:
> https://drive.google.com/file/d/1W73ASe_39BMNTA8anyWgjlxbSGvNiQoT/view?usp=sharing

Hmm... I think that your toolchain was actually built correctly this
time. The end of both logs you uploaded suggests that the script
finished successfully, the toolchain is packaged and everything is
done:

End of build log:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

[1m********** Post-cleanup (B [m
[1m********** Package (B [m
[1m********** Done (B [m

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

End of error log:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

strip:installNative/build-bleeding-edge-toolchain.sh: File format not recognized
strip:installNative/lib/gcc/arm-none-eabi/8.3.0/install-tools/mkheaders: File format not recognized
strip:installNative/lib/gcc/arm-none-eabi/8.3.0/install-tools/mkinstalldirs: File format not recognized
strip:installNative/lib/gcc/arm-none-eabi/8.3.0/install-tools/fixinc.sh: File format not recognized
strip:installNative/bin/arm-none-eabi-gdb-add-index: File format not recognized
(stdin): 108.2 MiB / 1,763.1 MiB = 0.061, 2.0 MiB/s, 14:34

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

(the last line is the compression, previous lines are expected errors
from the post-cleanup phase)

In the logs you posted there's no "write error: stdout" or "write
error", so it really seems that this time it worked correctly!

Anyway - your symptoms start to really fit what is mentioned in this
bug report:
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1814393
1. It affects Ubuntu.
2. It happens on "huge" compilation jobs.
3. It happens when compilation jobs are multithreaded.
4. It is most-likely related to redirection of stdout/stderr (when you
redirected the output to files it worked fine, previously - with no
redirection - it failed).
5. It doesn't happen all the time.

If your `uname -a` tells you that your kernel version is 4.15.0-44 or
4.15.0-45, then I guess this would really be the cause of the problem.

Some solutions:
- If you also think the symptoms fit, maybe it would be possible for
you to downgrade to kernel 4.15.0-43 (posts in the bug report suggest
that this is a workaround)? Or to upgrade to something above 4.15.0-45
if that is possible?
- Redirect script's output to files (it seems that this actually
"solved" the problem for you).
- Disable parallel build by removing all "-j$(nproc)" from the script.

Let me know what kernel version are you using and whether any of the
above helps. But first of all check whether there's a package with the
toolchain in your build folder - a 108.2 MB file named "arm-none-eabi-
gcc-8.3.0-YYMMDD.tar.xz" (with "YYMMDD" most likely being "190226").

Regards,
FCh

[Charles West]

Hello Freddie,

I do have that kernel version:

Linux Telos 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

With the second compilation at least, that file does appear:

arm-none-eabi-gcc-8.3.0-190226.tar.xz

If I may ask, what is the best way to install the files after they have been built?  Is there an option I should pass or does it need to be done manually?

Thanks,

Charlie West

[Freddie Chopin]

On Wed, 2019-02-27 at 06:34 -0800, Charles West wrote:
> If I may ask, what is the best way to install the files after they
> have been built? Is there an option I should pass or does it need to
> be done manually?

Personally I don't install them at all, because I use like (at least) 3
different versions for different projects (; I just extract them into
my ~/ folder and add the one I'm using the most to my local PATH
variable (via ~/.xprofile file, which contains just this: `export
PATH=/home/freddie/arm-none-eabi-gcc-8.2.0-180815/bin:$PATH`). For
projects which need a different version I manually configure PATH
variable via IDE settings for each of them.

With most recent version of distortos this may be even simpler, as it
uses CMake exclusively - you need to modify PATH only once - when you
first create the build folder and initialize CMake in it.

If you really want to "install" it you may drop it into some typical
folder like /usr/local, but then you may have a lot of trouble to
actually remove it someday...

Regards,
FCh

[Charles West]

Editing the Path did it.  I was a little worried that it might potentially break things, so this is a happy solution.

I've made a simple board yaml file and tested it with the STM32 Discovery-F072B.  It appears to work as expected with the test program and I have submitted a pull request for it.

I am now going to make a simple hello world and then see about PWM.  Thanks.

[Charles West]

Hey Freddie,

I'm afraid I am going to go with ChibiOS for now.  I'm getting some pretty weird errors when trying to mess with the hello world.  The files that you submitted appeared to get a different binary size than when I generated them (though it is possible that I made some sort of mistake).  Neither appears to be working for the test.

Further investigation trying to get things to work indicates that there is a problem with M0 processors and GCC versions higher than 5.  With ChibiOS I was getting random crashes until I downgraded GCC to 5, even using the bleeding edge build that you created.  It seems quite possible that this might be related to the errors I am seeing.

In any case, I have to move forward because the embedded portion of this project is one of the smaller pieces.  In thanks for your help though, I would like to send you a STM32F0-Discovery board.  Is the following address OK?  I intend to use Mouser (or failing that, Digikey).

DISTORTEC
ul. Nowomiejska 18
42-400 Zawiercie
POLAND

Thanks,

Charlie West

[Freddie Chopin]

Hello Charles!

On Mon, 2019-03-04 at 07:29 -0800, Charles West wrote:
> I'm afraid I am going to go with ChibiOS for now.

Sorry to hear that... Let me know if there's anything I could do to
improve for the future, maybe you'll want to try distortos again - who
knows...

> I'm getting some pretty weird errors when trying to mess with the
> hello world. The files that you submitted appeared to get a
> different binary size than when I generated them (though it is
> possible that I made some sort of mistake). Neither appears to be
> working for the test.

I would really, really like to help you (and obviously help distortos,
if there is some problem there), but I just cannot do that with so
little data. Why don't you compress your entire folder with distortos
(or several versions if you have them) and send them over to me? I
would then be able to analyse the problem and see what is going on. For
now I just have no information except that "it doesn't work"... Please
send me these files, and especially the files you generated for the
board yourself so I could compare them with mine. Please tell me what
are these "pretty weird errors" with the hello world application? Maybe
you could send me this application (possibly entire source tree) too?

> Further investigation trying to get things to work indicates that
> there is a problem with M0 processors and GCC versions higher than
> 5. With ChibiOS I was getting random crashes until I downgraded GCC
> to 5, even using the bleeding edge build that you created. It seems
> quite possible that this might be related to the errors I am seeing.

I'm almost certain that there's no problem with M0 and GCC, as I
regularly run the test application with all versions of GCC (especially
the most recent one) and almost all boards that I have (including
boards with M0 core - one with L0 chip and another one with F0 chip) -
it all works as expected.

I've also done a no-RTOS project with GCC 8 and STM32F042K6 chip in
September-October 2018, which also worked as expected, no random
behaviour at all.

If anything, I would say that the more recent GCC version you use, the
better behaviour you get. GCC 5 is actually - in my opinion -
absolutely minimum version if you want to have C++11 with no extremely
strange bugs.

Don't get me wrong, I do believe that you face some issues, but in
reality when someone says that the problem is in the toolchain, in
99,666% of these cases it turns out to be a problem of the user
application, not the compiler... I also cannot help you solve them, as
you don't provide any more details...

> In thanks for your help though, I would like to send you a STM32F0-
> Discovery board. Is the following address OK? I intend to use
> Mouser (or failing that, Digikey).
>
> DISTORTEC
> ul. Nowomiejska 18
> 42-400 Zawiercie
> POLAND

Yes, the address is correct. I assume you are talking about the "new"
32F072BDISCOVERY board, right? I actually have the "old"
STM32F0DISCOVERY board (the one with STM32F051R8), but there are no
files for that in the repository of distortos. I could actually include
it (as I did with NUCLEO-F042K6), but I did not do that yet... Both of
them have very little RAM, so actually not very useful for a RTOS...
STM32F072RBT6 found on 32F072BDISCOVERY is a bit better with 16 kB of
RAM, which I would say is a minimum for a multithreaded application if
it should do anything more complex.

Anyway - I hope you did not lost all faith in distortos and that maybe
we could solve the issues you faced with just a bit more info (like the
archives with your source tree).

Regards,
FCh