New hardware support or replacement proposal

E:V:A xdae3v3a at
Fri Mar 17 11:30:43 UTC 2017

Dear SIMtrace Developers,

After having spent a few days reviewing your SIMtrace hardware and FW
and its development,
I would like to propose you to consider supporting the following project.


The current SIMtrace processor (AT91SAM7) is based on the 55 MHz
ARMv4T uP, whereas the next generation SIMtrace2 is to use (AT91SAM3)
which is based on a 96 MHz Cortex-M3. This is all great and dandy, but
it does limit the hardware and software development to people who are
already very familiar with that hardware. Why are these needed? They
are needed so that we can have 2 SIM (USART) interfaces and that we
can translate the signals found on those to/from a USB endpoint on the
USB port. This is all done in the firmware, written in C + Assembly.


The new project would utilize a RaspberryPi-Zero-W in the external
slave configuration or a RPi3 doubling as a host. The RPi-0 is a 1GHz
ARM processor (ARM1176JZF-S) and could possibly also be used as a
headless host via WiFi. (RPi0 has OTG USB, RPi3 doesn't.) The Rpi3 is
a quad-core 64-bit Cortex-A53, that can be used as anything. Thus
porting A53 to M3 might be more easy.


There are too many advantages to ignore...
- The huge RPi developer community
- The high clockspeed and 512+ Mb of RAM
- All interfaces you can dream of, except JTAG
- A huge reduction on the BOM. I've counted that we may remove about
50 components by using this solution instead of the current v1.3 one.
- A huge reduction to about 1/3 of what is currently used of the PCB footprint.
- A large reduction of production price due to above.
- Easy to port drivers when understood
- Provide a more attractive and useful product combo (RPi-0 + ST hat)
than what is currently offered.


- Need porting of current FW drivers to RPi's
- Possible proprietary limitation to the complete Broadcom datasheets
- Need to CAD and manufacture a new PCB
- New Rpi-0/3 drivers would need testing for use with 2 SIM IF's.


The RPi's only has one UART so to get a second, we need to use
bit-banging of their GPIO,SPI or I2C. There are already solutions out
there and the much higher clock-rate of both devices allow you to run
up to 250 MHz on a single GPIO pin, so that would allow you to
multiplex a number of virtual/emulated UARTs. (Perhaps similarly to
what was already done when SIMtrace was using the FT232r?) The library
used for this is the PGPIO from here:
and a Python based test-script can be found here:

Finally, please don't get me wrong. This is not at all a critique of
what has already been done. The development of the ST is a great piece
of work and obviously very flexible and cross platform compatible by
using USB, but for compact embedded devices, such as RPi's etc, all
that extra HW is redundant and expensive to produce and maintain. Even
more so than combining the RPi + this add-on, while improving cross
platform connectivity and IoT support.

I would love to hear what the community and Osmocom think about this.


More information about the simtrace mailing list