ATA Design: Difference between revisions
No edit summary |
|||
| 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 === | ||
Revision as of 13:32, 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; 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
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
- CPU power - if we need to run several encode/decode streams, pretty much everything linux-capable will be able to keep up
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