New hardware support or replacement proposal

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. Background: 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. Proposal: 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. Advantages: 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. Disadvantages: - 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. Other: 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: http://abyz.co.uk/rpi/pigpio/download.html and a Python based test-script can be found here: https://www.rs-online.com/designspark/raspberry-pi-2nd-uart-a-k-a-bit-bangi… 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. Cheers, E:V:A