ATA Design - Revision history

Kscz at 21:23, 2 January 2024

2024-01-02T21:23:58Z

← Older revision		Revision as of 14:23, 2 January 2024
Line 11:		Line 11:
	* Availability - pre-made modules like the RaspberryPi are hard to get a hold of in reasonable quantities; cheaper linux-capable processors like Allwinner's stuff is hard to get from trustworthy sources like Digikey/Mouser		* Availability - pre-made modules like the RaspberryPi are hard to get a hold of in reasonable quantities; cheaper linux-capable processors like Allwinner's stuff is hard to get from trustworthy sources like Digikey/Mouser
	* Cost - these will be more expensive to manufacture and/or require more-expensive pre-made modules		* Cost - these will be more expensive to manufacture and/or require more-expensive pre-made modules
			* Real-time issues - making sure you get consistently paced DAC readings and push out consistent ADC updates may require extra support from the audio chipset
			* GPIO limitations - we may need a separate low-power MCU to control the real-time bits/interface with higher-power domains as linux-capable MCUs generally don't have much GPIO strength

	Big upsides:		Big upsides:

Kscz at 21:14, 2 January 2024

2024-01-02T21:14:44Z

← Older revision		Revision as of 14:14, 2 January 2024
Line 16:		Line 16:
	* Scriptability/hackability - people will be able to use/modify/add behaviors without recompiling firmware		* Scriptability/hackability - people will be able to use/modify/add behaviors without recompiling firmware
	* CPU power - if we need to run several encode/decode streams, pretty much everything linux-capable will be able to keep up		* CPU power - if we need to run several encode/decode streams, pretty much everything linux-capable will be able to keep up
			* Memory - pretty much every linux-capable setup will have more than enough RAM to run several SIP streams simultaneously

			For a quick rundown of the complexities of building a linux-capable system: https://jaycarlson.net/embedded-linux/

	=== Processor Capabilities ===		=== Processor Capabilities ===
Line 28:		Line 31:
	* Allwinner - I don't feel super confident evaluating these options, and so I've left them off		* Allwinner - I don't feel super confident evaluating these options, and so I've left them off
	* RaspberryPi		* RaspberryPi
	* Beaglebone Black		* Beaglebone Black/Green

			It would be nice to have WiFi, but I couldn't find any options for this aside from the the ESP32. Any option could be paired with an ESP32-C3/ESP8266 to provide wifi.

			All options could be paired with something like an SPI-to-ethernet adapter. The esp-idf supports a number of such devices - https://github.com/espressif/esp-idf/blob/master/components/esp_eth/include/esp_eth_phy.h

			==== Decode/Encode ====
			The MCU/Processor should be powerful enough to handle a few ports worth of real-time audio - this will require some benchmarking! I think this will disqualify most MCUs which don't have a FPU, but I am unsure.

			How powerful the MCU is sets which codecs we can support and how many FXS ports our ATA can handle.

			RAM utilization also needs to be tested - multiple concurrent encode/decode streams, along with SIP management will probably require a fair bit of memory.

	~~It would be nice~~ to ~~have WiFi~~, but I ~~couldn't find any options for this aside from the the ESP32~~		==== Audio input/Output ====
			The MCU/Processor will either need a really good ADC and DAC per FXS port we support, or it will need to support interfaces which can run to DAC/ADC audio devices. This should probably mean I2S support, but I need to do a deeper dive on it.

	==== ~~Decode/Encode =~~====		==== Ease of Assembly ====
	~~The MCU~~/~~Processor~~ should ~~be powerful enough~~		When building these boards, it would be convenient to have an option which doesn't require complex soldering. This would effectively limit us to boards which have easy-to-utilize, cheap devboards - the beaglebone/raspberrypi (we would build this as a cape/hat), the teensy4 and the i.mxrt106x, or the ESP32 and its many variants. I'm not sure how strongly we should adhere to this idea.

Kscz: /* Linux-capable */

2024-01-02T20:32:46Z

Linux-capable

← Older revision		Revision as of 13:32, 2 January 2024
Line 9:		Line 9:
	The big downsides to Linux-capability are:		The big downsides to Linux-capability are:
	* Complexity - these parts require a lot more support circuitry		* Complexity - these parts require a lot more support circuitry
	* Availability - pre-made modules like the RaspberryPi are hard to get a hold of in reasonable quantities		* Availability - pre-made modules like the RaspberryPi are hard to get a hold of in reasonable quantities; cheaper linux-capable processors like Allwinner's stuff is hard to get from trustworthy sources like Digikey/Mouser
	* Cost - these will be more expensive to manufacture and/or require more-expensive pre-made modules		* Cost - these will be more expensive to manufacture and/or require more-expensive pre-made modules

Line 15:		Line 15:
	* Libraries - most of the software will be done for free, we'll basically be plugging lego blocks together for most of it		* Libraries - most of the software will be done for free, we'll basically be plugging lego blocks together for most of it
	* Scriptability/hackability - people will be able to use/modify/add behaviors without recompiling firmware		* Scriptability/hackability - people will be able to use/modify/add behaviors without recompiling firmware
			* CPU power - if we need to run several encode/decode streams, pretty much everything linux-capable will be able to keep up

	=== Processor Capabilities ===		=== Processor Capabilities ===

Kscz at 20:26, 2 January 2024

2024-01-02T20:26:01Z

← Older revision		Revision as of 13:26, 2 January 2024
Line 1:		Line 1:
	This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones).		This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones).

	== MCU Selection ==		== MCU/Processor Selection ==
			There needs to be a main processor, and this section runs through my thoughts as I consider the available options.

			=== Linux-capable ===
			Being Linux-capable would be nice! It's not a requirement because... well we don't need it!

			The big downsides to Linux-capability are:
			* Complexity - these parts require a lot more support circuitry
			* Availability - pre-made modules like the RaspberryPi are hard to get a hold of in reasonable quantities
			* Cost - these will be more expensive to manufacture and/or require more-expensive pre-made modules

	~~There needs to~~ be ~~a main processor~~, ~~and this section runs through my thoughts as I consider the available options.~~		Big upsides:
			* Libraries - most of the software will be done for free, we'll basically be plugging lego blocks together for most of it
			* Scriptability/hackability - people will be able to use/modify/add behaviors without recompiling firmware

	=== Processor Capabilities ===		=== Processor Capabilities ===

	I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for fun, I don't want to spend my time hyper-optimizing just to get basic functionality working. This means I won't be looking at the Microchip PIC8/12/14/16/18, the Atmel Atmega line, or TI's MSP430. What it leaves on the table is: Arm (bunch of manufacturers), Microchip's dsPIC line, Risc-V, and the ESP32-variants using the Xtensa CPUs. There may be others, but this is all I'm considering to start, mostly because it's what I know!		I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for fun, I don't want to spend my time hyper-optimizing just to get basic functionality working. This means I won't be looking at the Microchip PIC8/12/14/16/18, the Atmel Atmega line, or TI's MSP430. What it leaves on the table is: Arm (bunch of manufacturers), Microchip's dsPIC line, Risc-V, and the ESP32-variants using the Xtensa CPUs. There may be others, but this is all I'm considering to start, mostly because it's what I know!

	==== Connectivity ====		==== Connectivity ====

	At a bare minimum, we'd like everything to have Ethernet. This is actually quite limiting! Things which still qualify:		At a bare minimum, we'd like everything to have Ethernet. This is actually quite limiting! Things which still qualify:
	* TI's ARM-R5 line and TMC129x line (Cortex-M4F)		* TI's ARM-R5 line and TMC129x line (Cortex-M4F)
			* NXP has a few offerings in the LPC line, Kinetis/MK line, and the MIMXRT line
			* Microchip/Atmel has a bunch of offerings - a number of ARM9 and Cortex-A5/A7 linux-capable units, and the ATSamE53x (Cortex-M4F, 120Mhz) and ATSamE7x (Cortex-M7, 300Mhz) lines
			* Espressif currently only has the original ESP32 with ethernet, though for reasons described below, I'll keep the ESP32-S3 in the running as well
			* Allwinner - I don't feel super confident evaluating these options, and so I've left them off
			* RaspberryPi
			* Beaglebone Black

			It would be nice to have WiFi, but I couldn't find any options for this aside from the the ESP32

			==== Decode/Encode =====
			The MCU/Processor should be powerful enough

Kscz at 17:03, 2 January 2024

2024-01-02T17:03:22Z

← Older revision		Revision as of 10:03, 2 January 2024
Line 1:		Line 1:
	This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones).		This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones).

	# MCU Selection		== MCU Selection ==

	There needs to be a main processor, and this section runs through my thoughts as I consider the available options.		There needs to be a main processor, and this section runs through my thoughts as I consider the available options.

	## Processor Capabilities		=== Processor Capabilities ===

	I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for fun, I don't want to spend my time hyper-optimizing just to get basic functionality working. This means I won't be looking at the Microchip PIC8/12/14/16/18, the Atmel Atmega line, or TI's MSP430. What it leaves on the table is: Arm (bunch of manufacturers), Microchip's dsPIC line, Risc-V, and the ESP32-variants using the Xtensa CPUs. There may be others, but this is all I'm considering to start, mostly because it's what I know!		I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for fun, I don't want to spend my time hyper-optimizing just to get basic functionality working. This means I won't be looking at the Microchip PIC8/12/14/16/18, the Atmel Atmega line, or TI's MSP430. What it leaves on the table is: Arm (bunch of manufacturers), Microchip's dsPIC line, Risc-V, and the ESP32-variants using the Xtensa CPUs. There may be others, but this is all I'm considering to start, mostly because it's what I know!

	~~###~~ Connectivity		==== Connectivity ====

	At a bare minimum, we'd like everything to have Ethernet. This is actually quite limiting! Things which still qualify:		At a bare minimum, we'd like everything to have Ethernet. This is actually quite limiting! Things which still qualify:
	* TI's ARM-R5 line and TMC129x line (Cortex-M4F)		* TI's ARM-R5 line and TMC129x line (Cortex-M4F)
	*

Kscz: Created page with "This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones). # MCU Selection There needs to be a main processor, and this section runs through my thoughts as I consider the available options. ## Processor Capabilities I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for..."

2024-01-02T17:02:43Z

Created page with "This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones). # MCU Selection There needs to be a main processor, and this section runs through my thoughts as I consider the available options. ## Processor Capabilities I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for..."

New page

This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones).

# MCU Selection

There needs to be a main processor, and this section runs through my thoughts as I consider the available options.

## Processor Capabilities

I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for fun, I don't want to spend my time hyper-optimizing just to get basic functionality working. This means I won't be looking at the Microchip PIC8/12/14/16/18, the Atmel Atmega line, or TI's MSP430. What it leaves on the table is: Arm (bunch of manufacturers), Microchip's dsPIC line, Risc-V, and the ESP32-variants using the Xtensa CPUs. There may be others, but this is all I'm considering to start, mostly because it's what I know!

### Connectivity

At a bare minimum, we'd like everything to have Ethernet. This is actually quite limiting! Things which still qualify:
* TI's ARM-R5 line and TMC129x line (Cortex-M4F)
*