Nice to hear from you Stuart, you explained well. I also saw Rasberry Pie, it doesn't have much audio ports , as you need more aux ports for this system. Secondly, I don't require any USB, Ethernet, graphic displays or removable storage. Only Debugging port and audio ports needed.
On Tue, Jul 30, 2019 at 3:25 PM Stuart Longland <[email protected]> wrote: > On 30/7/19 6:19 pm, Al Beard wrote: > > Is there some reason why you want to run on less powerful hardware than > > a Raspberry Pi or > > clone? > > - Power consumption: a DSP or MCU will draw much less power than any > Raspberry Pi > > - Cost: Raspberry Pi is ~AU$60… STM32F407VG as used in the SM1000 is > $20, there are other options from NXP/Freescale, TI, etc that are even > cheaper. > > - Availability: Broadcom won't sell you the bare SoC in the Raspberry Pi > unless you're buying tens of thousands of units. Closest you get is a > SoM like the Raspberry Pi Compute module. There are lots of MCUs on the > market, and most can be easily obtained in single units. > > - Complexity: MCU just runs bare-metal code from flash, Raspberry Pi has > a boot-loader, a kernel (usually Linux), an operating system (usually a > Debian derivative) *then* the application running on top. Much more to > go wrong. > > - Audio capability: the Raspberry Pi has no audio inputs, just one lone > stereo audio output. As that audio output shares its power source with > all other 3v3 peripherals, it has _lots_ of noise. (Found this out the > hard way on Friday evening.) More recent models have improved on this > somewhat, but your mileage may vary. > > > BUT: No USB ports, no Graphic display, no ethernet port. No easily > replaceable program SD card. > > No SIMD instructions for any future modes such as LPCnet. > > Suppose the application Ammar has in mind does not require USB, > Ethernet, graphic displays or removable storage? Maybe such things are > undesirable. > > As for SIMD, you do realise that SIMD instructions were developed *for* > digital signal processing applications don't you? Maybe the TMS320C6713 > has different SIMD functions to what's used in LPCNet, but that doesn't > mean it can't be ported by someone who has a good foundation in the field. > > It really depends on what you're trying to achieve. If you want a > general-purpose, highly flexible system, the single board computers may > be a viable option. > > Brisbane WICEN recently did a RFID/APRS integration project, and I made > the decision to use the PocketBeagle over a smaller device like the > Arduino Mega on the grounds that the only thing the Arduino Mega had in > its favour was a couple of extra UARTs and a reduced power consumption. > > Given the radios and RFID readers we were going to be running *with* the > computers consumed orders of magnitude more power than the computers > themselves, I didn't see this as being that big issue. > > Long term, we may decide to port it over to a small MCU platform. We'll > see. The PocketBeagles are a bit under AU$40, and while the original > task could most definitely be done by an Arduino, it's looking like > we'll have to run a small database at the check-point, at which point > the PocketBeagle really starts to shine. > > We of course have the risk that sudden power down can corrupt an SD > card, however it's not a big problem in our situation to have a couple > of spare SD cards that can be quickly taken to a check-point. Plus, > there's always the pen-and-paper system as a back-up. > > If your aim though was to use a low-power radio like a Elecraft KX3 or > something and wanted a small embedded "modem" to do FreeDV however, the > SM1000 or something built on the TI DSP mentioned would definitely be a > more reliable option long-term, would have a lower hardware cost per > unit, and would consume less power. > > The trade-off is development cost. > > For us we needed to throw something together in a few week-ends. > Muggins wound up writing the foundations for an AX.25 stack in Python > (there are a few libraries, but they didn't want to play the game for > me), and I basically had a rudimentary system that could send APRS > messages via a standard KISS TNC. > > I could of course do what I've done so far in C on a microcontroller, > however it's looking like I'll need to access USB mass storage and embed > a database of some kind (right now I'm using SQLite3, but there are many > other options), things I don't fancy doing from a small microcontroller. > > So there's nothing wrong with Ammar going to a development board. If > the aim is to play with FreeDV it definitely is jumping in at the deep > end, however some people enjoy that sort of challenge. > > My thought would be to maybe have a look at the STM32F4 Discovery > development board, as that was the board used to actually develop the > SM1000 firmware. Once you poke it and see how it moves, it may be > possible to slowly port it over to the TMS320C6713. > -- > Stuart Longland (aka Redhatter, VK4MSL) > > I haven't lost my mind... > ...it's backed up on a tape somewhere. > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
