¿ªÔÆÌåÓý

Re: raduino v1.27 released (improved suppression of spurious burst)


 

¿ªÔÆÌåÓý

I actually like the idea of two separate platform paths. ?Ot keeps competition between the two alive but allows porting of code ideas from one path to another. ? It also gives new people a choice of directions to pursue and gives a better range of options. ? Plus more programmers are engaged specific to their platforms. ?And it could be that the cross over and there are both in one box!


Dr.?William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch ¨C K9ZC

Staunton, Illinois

?

Owner ¨C Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it:


email:??bill@...

?


On Nov 9, 2017, at 1:11 PM, Mike Woods <mhwoods@...> wrote:

Thanks for all the suggestions around expanding the number of ports and processor capacity.

I already have a port expander (8 bit) in one of my BITX, but this is not going to solve the problem of SRAM and program space.? It really only exacerbates the problem!

There are lot of different views, as anticipated, around alternative processors. Some would prefer to stay with Arduino compatibility, others are happy to move to another platform (Teensy or Raspberry Pi, etc). There are advantages and disadvantages of each option.? To my mind a particular disadvantage of moving to the Pi is that this requires some familiarity with Linux and the addition of monitor, keyboard and mouse (unless you use remote control type software and control the pi from a laptop as suggested by Doug KD9CYF). However, I agree it is an attractive option for other reasons (e.g. remote radio control).

This got me thinking about the principles involved with modding the BITX40.? I agree with Allard's approach to date in retaining backwards compatibility.

To my mind this means retaining the existing Raduino intact and the mods that Allard's software supports. There is a way to have the best of both worlds:? backwards compatibility and the option to add an additional processor. The answer may lie in using the existing communication channel for other devices (I2C is already used to control the Si5351). However, it can also be used to communicate between two processors.? e.g. See for a simple example.

Another Aduino Nano or a Mega Mini costs no more than a port expander, and has more ports!? This appeals to me as it also increases processing capability.

The existing sketch could be modified to transfer out key data relating to hardware controls (PTT Sense, CW key down, etc.) whenever another slave processor was detected, and allow the slave to disable some functions (to my mind I would be particularly interested in disabling control of the Si5351 and the potentiometer on the Master).? It would also need to allow the passing in of data from the slave processor for display of information on the screen, and accept changes to parameters that are tied to board control (e.g. CW mode parameters).

This would provide an open platform then for whatever processor people wanted to add to their Raduino/Bitx.

What do you all think??? I would be particularly interested in Allard's thoughts on this, as he "owns" the current software that most of us are using.? I would be reluctant to fork it when it is still being actively developed!

73 de Mike ZL1AXG

On 8/11/17 11:34 AM, David wrote:
What about using a multiplexer chip to reduce the number of I/O lines needed. A bit old school but effective.

Sent from my iPhone



--
Mike Woods
mhwoods@...



Join [email protected] to automatically receive all group messages.