ATA Design: Difference between revisions

From kitwiki
Jump to navigation Jump to search
No edit summary
No edit summary
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

Revision as of 13:26, 2 January 2024

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/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

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

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)
  • 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

Retrieved from "http://wiki.h5yy.com/mediawiki/index.php?title=ATA_Design&oldid=27"