Command languaje for tiny microcontrollers

[Picuino]

In addition, you can automate the sending of commands from the PC with a programming language, which you cannot do with a debugger.

[NorthGuy]

It doesn't matter what you thing debuggers are designed for. You can use them to read MCU registers, write MCU registers, dump memory, switch PC to the desired position, run code snippets, stop the code at the desired point etc - all these things that you want to do with "AVRShell". How can you not see the similarity?

And you still can't fathom any other use case. 

I am not talking about use cases. I'm talking about capabilities, which answer the question "what can you do?".  The use cases answer the question "What are you trying to accomplish?" If you really have a use case where you had to accomplish something on a tiny microcontroller and you used an interpreted language to do this faster and better, post it here. Then we'll see how it helped and perhaps how it could've been done differently.

You didn't notice that it implements multitasking, did you?   Go have a look at src/timer.S and src/process.S.  It's a cute little educational tool, helping new AVR programmers explore more than just the Arduino-like "loop plus interrupts".

If it accept commands and runs at the same time, it's got to be multitasked.

If you're talking about user thread, C and certainly do this, with RTOS, or otherwise. I don't see why there's a need for interactive shell for this.

Again, the AVRShell commands are used to access MCU state, without stopping everything running in it.  It is a complement to a debugger; more like a playground than a crude debugger you think it is.

As to accessing MCU memory (be it flash, RAM, or hardware registers), many debuggers allow you watching variables without halting, but not all the chips are able to do this.  For those chips which can the debugger is simply connected to the data bus. Thus, aside of bus contention, there's no overhead. If there's no such facilities, any debugger can halt-read-run with less overhead than AVRShell. Some debuggers support breakpoints at data reads/writes, which minimizes overhead even further.

Most importantly, the resource use is minimal, or not at all. Say, tiny PIC16F15213 with 2k flash and 256 bytes of RAM. You can debug it interactively without using any resources. You don't even need to write a sensible program. You can start the debugger and start exploring. Say, enable PWM, write to the duty cycle register and watch how this affects the things outside.

[Nominal Animal]

If it accept commands and runs at the same time, it's got to be multitasked.

So, where is your debugger that provides multitasking capabilities on the target?

Do consider going back to your day job, torturing customers as a tier-0 tech support.

[NorthGuy]

In addition, you can automate the sending of commands from the PC with a programming language, which you cannot do with a debugger.

You certainly can. Most debuggers have command line interfaces, so you can invoke it from your program and make it execute any commands you like.

But I don't think this is needed. If you want something on MCU with the interface, you just create the interface first, then use it.

Few years ago I had to make a machine which had 7 stepper motors which had to be controlled from PC. I created UART command interface between the MCU and PC. Then I buit a GUI application (could've been CLI as well) which let me issue commands - simple ones, such as moving a single motor, or more complex ones which move several motors in synch without bumping into each other. This let me explore how the motors move and adjust things. I kept modifying the PC program adding more and more complex motions until I got the snippet which would run the machine unattended. I did it all on the PC. With compiled languages. The MCU only had to decode UART commands and send signals to motors. Some may think this would be a good case for interactive languages, but this is not. Moreover, motors need to receive pulses at exact times. A bloaty interpretative language would mess everything up.

[NorthGuy]

If it accept commands and runs at the same time, it's got to be multitasked.

So, where is your debugger that provides multitasking capabilities on the target?

Debugger itself is a piece of hardware (sometimes part of CPU, sometimes external) which does its job independently of the CPU. It watchs for breakpoints, accept interrupts or commands from the debugging software on PC etc. This activity is parallel to CPU execution and doesn't affect it until CPU halts.

Debugger doesn't provide multitasking capabilities on the target. The firmware can provide multitasking capabilities if needed. The MCUs also have peripheral modules which are independent on CPU. So, while the CPU is halted by the debugger they can continue doing their jobs, such as producing PWM  etc.

You refuse to provide a clear use case. It is quite impossible to discuss abstract things without any clue on how they relate to reality.

[SiliconWizard]

In addition, you can automate the sending of commands from the PC with a programming language, which you cannot do with a debugger.

Yes you can. 

[brucehoult]

In addition, you can automate the sending of commands from the PC with a programming language, which you cannot do with a debugger.

Funny, but that's exactly what OpenOCD, for example, does: scripts gdb to download and run code on the target

As do any number of GUI wrappers for gdb, including elisp script in the emacs editor, to make gdb mode.

[tggzzz]

If it accept commands and runs at the same time, it's got to be multitasked.

So, where is your debugger that provides multitasking capabilities on the target?

Debugger itself is a piece of hardware (sometimes part of CPU, sometimes external) which does its job independently of the CPU. It watchs for breakpoints, accept interrupts or commands from the debugging software on PC etc. This activity is parallel to CPU execution and doesn't affect it until CPU halts.

Debugger doesn't provide multitasking capabilities on the target. The firmware can provide multitasking capabilities if needed. The MCUs also have peripheral modules which are independent on CPU. So, while the CPU is halted by the debugger they can continue doing their jobs, such as producing PWM  etc.

You refuse to provide a clear use case. It is quite impossible to discuss abstract things without any clue on how they relate to reality.

.

Debuggers don't have to be hardware in addition to the CPU, and the early microprocessor ones didn't. They could set breakpoints and single step, but the major omission was that it was not possible to halt when a variable was accessed.

[Nominal Animal]

Debugger doesn't provide multitasking capabilities on the target.

So, your snarky comment about using a debugger instead of AVRShell was just utter shit, thrown at the wall and hoping nobody notices your stupidity.

I'm sure your tier-0 telephone support shift is starting soon, so instead of wasting time trying to show what is actually possible to an idiot, I'll do us both a favour and ignore you, and go help e.g. students learning how unrelated tasks in a low-level 8-bit environment interact.

I recommend everyone interacting with you do the same, because you obviously have zero idea about anything you comment.  Just take a look at your posting history: nothing worth reading there either.

[tggzzz]

Debugger doesn't provide multitasking capabilities on the target.

So, your snarky comment about using a debugger instead of AVRShell was just utter shit, thrown at the wall and hoping nobody notices your stupidity.

I'm sure your tier-0 telephone support shift is starting soon, so instead of wasting time trying to show what is actually possible to an idiot, I'll do us both a favour and ignore you, and go help e.g. students learning how unrelated tasks in a low-level 8-bit environment interact.

I recommend everyone interacting with you do the same, because you obviously have zero idea about anything you comment.  Just take a look at your posting history: nothing worth reading there either.

I'm becoming cranky too. Too many posters appear (to me, naturally) that they would score poorly on a "critical thinking analysis" type test in a job interview.

Tell tale: snipping context too heavily so that their point seems reasonable in isolation. Usually accompanied by a wail that "too much context makes posts too long, and I only removed unimportant stuff", or similar.

I used not to like CTA type tests in job interviews; my result of being in the "top 3%" seemed trite and somewhat surprising. I'm coming to understand what they do trap out

[Nominal Animal]

scripts gdb to download and run code on the target

gdb is a pretty powerful debugger.  I've used its Python (gasp!) interface for pretty-printing and complex data structure tracking and visualization; it all started here.

I'm becoming cranky too. Too many posters appear (to me, naturally) that they would score poorly on a "critical thinking analysis" type test in a job interview.

I don't know if you think I belong to that set, but nevertheless, I do agree.


A quick recap of how I saw the most interesting bits in this thread:

nctnico first described the rough idea of using a query-response interface or a scripting language for the high-level logic only, in #5.  Picuino's post #6 describes their initial intended use cases –– roughly, learning and exploration, not to avoid using a proper debugger.  In #17 rstofer outlined how they used a higher-level language (TinyBasic) for "testing" 8085 projects.

Next, tellurium brought up doing initial embedded environment on a desktop machine in #24, with others (nctnico in #25, tggzzz in #26, etc.) describing positive experiences doing that.  In #30, I roughly sketch how one can use Gtk in Linux for much easier embedded user interface development.

SiliconWizard pointed out in #38 that a better approach would be to look at ones needs, and starting from there instead.

In #52, nctnico suggested a command-line interface for Picuino's use cases.

In #64, I mentioned that my own use cases vary from experimentation to debugging.  I didn't think to mention that I don't use it to debug the code on the microcontroller itself, but other things connected to the microcontroller.  (I once even used a pair of Teensys connected via UART (very short wires), so that I could use one to "pose" as a completely different USB device (a vinyl cutter), "playing back" captured USB data, but under the control of the other Teensy, and that other one controller by my program.  I could have used a kernel driver to skip the entire USB hardware loop, but this was easier.)
I spent most of the message trying to show that one doesn't really need a full programming language for this kind of stuff, as a very simple query-response or command line interpreter will do just fine.

In #86, I show the key snippets I use, and finally describe my own uses, like experimenting with external actuator parameters for optimal responses, plus this:

In a design sense, this is very close to attaching a debugger to your microcontroller, and using it to modify the RAM state or execute specific functions.

For playing with controlling external devices, I like this approach better than a debugger, because this way the microcontroller firmware runs normally and is always in full control, instead of being under the debugger control.  This minimizes the differences between "normal operation" and "exploring settings", and thus ensures the results found via such exploration are consistent even when used with this machinery later on.

Others described similar use cases (nctnico #101, slugrustle #128 and #136): that use case pattern seems to be quite old and well known.

In #161, Picuino brought up AVRShell.  I consider it an excellent educational tool, for someone learning embedded development.  The way you can easily add your own C code "programs" to be multitasked, and with a few commands explore the entire state while the device is running, is definitely useful as a learning tool.

The key here is possibly nctnico's post #170:

IMHO you should see a debugger and command line interface as complementary.

Exactly.  I myself use the query-response/command interfaces in microcontrollers I use as tools.  I can see very interesting educational/teaching possibilities with AVRShell.  Having a simple, robust way to check the internal state of a running system (already in production) is certainly useful.  These are all use cases where you really don't want to have to use a debugger instead.  (And in cases like production systems, it may not be at all feasible to provide a debugger to the end user anyway.)

Getting bogged down with someone not understanding and utterly ignoring all other uses except for debugging code in a product, is .. well, so frustrating that I ended up writing this post. 

[NorthGuy]

So, your snarky comment about using a debugger instead of AVRShell was just utter shit, thrown at the wall and hoping nobody notices your stupidity.

Using for what? You keep leaving out the purpose (which, in my mind, is exploring MCU and hardware connected to the MCU). Our conversation goes approximately like this:

- Use pliers to hammer nails
- Have you ever heard of a hummer?
- But does your hummer have moving part?
- No
- Then you cannot use hummer instead of pliers

Also, if you could skip profanities, I think it would be good for everybody, in the first place for you.

[tggzzz]

I'm becoming cranky too. Too many posters appear (to me, naturally) that they would score poorly on a "critical thinking analysis" type test in a job interview.

I don't know if you think I belong to that set, but nevertheless, I do agree.

It doesn't matter to me either way. I prefer "cranky (or worse) plus correct" over "polite but wrong or time wasting" any day.

Having a simple, robust way to check the internal state of a running system (already in production) is certainly useful.  These are all use cases where you really don't want to have to use a debugger instead.  (And in cases like production systems, it may not be at all feasible to provide a debugger to the end user anyway.)

Debuggers are inherently dangerous, especially when the operator is tired or or under pressure from above or suffering from Dunning-Krueger syndrome.

The halfway camp to a debugger is a decent logging system. If done well it can directly indicate the problem to be fixed, or show the problem is in another company's equipment, and/or prevent law suits.

Getting bogged down with someone not understanding and utterly ignoring all other uses except for debugging code in a product, is .. well, so frustrating that I ended up writing this post. 

Just so.

[tggzzz]

So, your snarky comment about using a debugger instead of AVRShell was just utter shit, thrown at the wall and hoping nobody notices your stupidity.

Using for what? You keep leaving out the purpose (which, in my mind, is exploring MCU and hardware connected to the MCU). Our conversation goes approximately like this:

- Use pliers to hammer nails
- Have you ever heard of a hummer?
- But does your hummer have moving part?
- No
- Then you cannot use hummer instead of pliers

Also, if you could skip profanities, I think it would be good for everybody, in the first place for you.

I have no doubt you believe all that.

I suggest you stop digging.

[NorthGuy]

In #86, I show the key snippets I use, and finally describe my own uses, like experimenting with external actuator parameters for optimal responses, plus this:

In a design sense, this is very close to attaching a debugger to your microcontroller, and using it to modify the RAM state or execute specific functions.

For playing with controlling external devices, I like this approach better than a debugger, because this way the microcontroller firmware runs normally and is always in full control, instead of being under the debugger control.  This minimizes the differences between "normal operation" and "exploring settings", and thus ensures the results found via such exploration are consistent even when used with this machinery later on.

That's not true. Modern debuggers do not affect execution of the program in any way until it halts for whatever reason. If not halted, it runs absolutely normal. Often to the point that the program cannot even determine that it runs under the debugger.

If you want to explore actuator parameters, you don't really need anything, even a debugger. If you actuator is powered by a stepper motor you probably need to determine maximum speed, as well as acceleration and deceleration profiles at various loads. So, you just program a simple motion, program it to the chip and run, which takes about a second or less. The motor moves (correctly or incorrectly), you vary the load, run the program again, observe the differences, measure things. Then you change your problem a bit (say change the acceleration profile), and see how the results have changed. Setting up a debugger, or some system of interactive commands is just a waste in this case. Re-compilng is quick enough and you don't need to go though any hurdles to avoid it.

Sensors are all different. There are some where everything is pure software. For example DS18S20 were very common 15 years ago. To read the sensor you had to bit-bang rather lengthy sequence on a single wire. This is best explored with a scope or LA which will show you what sequence you're actually producing. Other sensors are just ADC, which are best explored with periodic "printf".

As you can see, even the debugger is not that much needed for the exploration.

Unlike the debugger, if you use things as AVRShell or interpreted language, this adds unnecessary bloat. In the links you posted, you can see that AVRShell produces timer interrupts which will disturb timing of whatever else you're doing. For example, this may change timing of your acceleration profile with the actuator, or it may wreck the timing of your bit-banging with DS18S20. And what do you get in return? Nothing.

[PlainName]

[ACRshell / interpreted language] adds unnecessary bloat

In the context of a MCU I would question whether bloat is important. Sure, on something like a PC or general purpose kit it is, but, on a single-purpose MCU, what would take the place of the bloat? Nothing. Unless you're actually running out of resources it is free (apart from the development time to implement).

Also worth considering that if you've got it you can use it or not, but if you haven't then you can't.

[Nominal Animal]

I'm a toolmaker at heart.  I like to make small gadgets –– both software and hardware –– to solve problems, but also to explore their solution space, and the various approaches to attacking a problem.  If you've never used FFT to implement scalar multiplication, you probably find this odd.  In practice, it means no problem is unsolvable to me: it is only a matter of available time and resources.

I also find learning –– supporting others trying to learn –– more important than any current abilities.  Because humans learn in different ways, you cannot teach effectively by having a single lesson that fits everybody.  You need to vary the approach to suit each individual, and their way of thinking.

Among developers, there is an axis of variance, where most people fit cluster at one or the other extreme.  This axis is akin to culture, but in the domain of development tool use.

Some developers demand an integrated environment, because they feel they are more productive in one, and it feels safe and supported.  They prefer a close vendor relationship, because it minimises development effort, cost, and cognitive load.

Other developers want modularity, and the ability to choose their tools.  They are naturally drawn to the Unix philosophy, as instead of using each tool for their designated purpose, they combine multiple tools to achieve any specific task.  They find any 1:1 mapping between task and tool limiting.

Here, we have NorthGuy being a textbook case of someone who has never undestood, and does not understand any approach outside their own.  They have never taken a critical look at their own workflows, and measured their own total productivity when using different approaches.  In #185, I listed various scenarios where using a debugger is really not suitable, as described by myself and others (including end-user operational state verification, running system parameter optimization, and making tools for investigating other systems and components).  Yet, the likes of Northguy still demand use cases, because they do not understand, and cannot even imagine themselves doing any of this; they just skip over these parts as if they weren't even discussed.

The reason I called their post #163, "utter shit",

AVRShell

Have you ever heard of debuggers?

is because AVRShell is not a debugger.  It is an environment for learners and hobbyists to explore their own C code inside a "shell" that provides multitasking (a fixed time slice scheduler) and simple commands and state examination while everything is still running using a serial connection.  It is literally described as so in the first sentence in Picuino's post #161, just after the title and the link to the post.

NorthGuy's post is a typical snarky remark by someone who cannot see anything beyond their own current use patterns, being an indicator of their own limitations and downsides than anything else.  I'm sad to see that a few members here seem to agree with him.  Not because it has any impact on myself, but because they really cannot see how they're limiting themselves for no reason.  NorthGuy's reference in #186 to using "pliers to hammer nails" is just hilarious, with zero self-awareness.
Perfect example of somebody who simply cannot see problems as anything but nails, and wondering why anybody would use any tool except a hammer.

[tggzzz]

A few random comments on your interesting post...

I'm a toolmaker at heart.  I like to make small gadgets –– both software and hardware –– to solve problems, but also to explore their solution space, and the various approaches to attacking a problem.  If you've never used FFT to implement scalar multiplication, you probably find this odd.  In practice, it means no problem is unsolvable to me: it is only a matter of available time and resources.

I also find learning –– supporting others trying to learn –– more important than any current abilities.  Because humans learn in different ways, you cannot teach effectively by having a single lesson that fits everybody.  You need to vary the approach to suit each individual, and their way of thinking.

That pretty much describes me too.

I'll add that two other things give me disproportionate pleasure:

• allowing people to realise and do things they either didn't believe or didn't believe they could do. Watching people radically expand their weltanschauung and capabilities is a true delight. Anybody with children ought to realise that
• allowing (or forcing sometimes) people to see that the world isn't black and white, it is all shades of grey - and that apparently different things are closely related. My canonical example is there is no simple distinction between hardware and software

Here, we have NorthGuy being a textbook case of someone who has never undestood, and does not understand any approach outside their own.  They have never taken a critical look at their own workflows, and measured their own total productivity when using different approaches.  In #185, I listed various scenarios where using a debugger is really not suitable, as described by myself and others (including end-user operational state verification, running system parameter optimization, and making tools for investigating other systems and components).  Yet, the likes of Northguy still demand use cases, because they do not understand, and cannot even imagine themselves doing any of this; they just skip over these parts as if they weren't even discussed.

It feels a little worse than that to me: someone who cannot even perceive there are alternative viewpoints, and is not interested in expanding their horizons.

NorthGuy's post is a typical snarky remark by someone who cannot see anything beyond their own current use patterns, being an indicator of their own limitations and downsides than anything else.  I'm sad to see that a few members here seem to agree with him.  Not because it has any impact on myself, but because they really cannot see how they're limiting themselves for no reason. 

Spot on. You've hit the nail on the head (with the stilson wrench).

[nctnico]

Not because it has any impact on myself, but because they really cannot see how they're limiting themselves for no reason.

You have to keep in mind that everyone has limitations. But that doesn't mean people can't be productive. You just need to make sure not to overload a person with a task / toolset that is beyond the particular person's abilities. I've been part of projects where people got a task that was way over their heads and subsequently failed or just quit. That made me very sad because I had already warned about that.

[MK14]

Not because it has any impact on myself, but because they really cannot see how they're limiting themselves for no reason.

You have to keep in mind that everyone has limitations. But that doesn't mean people can't be productive. You just need to make sure not to overload a person with a task / toolset that is beyond the particular person's abilities. I've been part of projects where people got a task that was way over their heads and subsequently failed or just quit. That made me very sad because I had already warned about that.

It is not just that.  If someone/people are overloaded like that.  I suspect, their efficiency and productivity, will become significantly worse.  Which is an inefficiency waste of time and other often expensive resources.
E.g. Forcing everyone to learn a new programming language, because it is the hottest new one available.  Instead of sticking to the one, the whole department knows and is use to.

[tggzzz]

Not because it has any impact on myself, but because they really cannot see how they're limiting themselves for no reason.

You have to keep in mind that everyone has limitations. But that doesn't mean people can't be productive. You just need to make sure not to overload a person with a task / toolset that is beyond the particular person's abilities. I've been part of projects where people got a task that was way over their heads and subsequently failed or just quit. That made me very sad because I had already warned about that.

It is not just that.  If someone/people are overloaded like that.  I suspect, their efficiency and productivity, will become significantly worse.  Which is an inefficiency waste of time and other often expensive resources.
E.g. Forcing everyone to learn a new programming language, because it is the hottest new one available.  Instead of sticking to the one, the whole department knows and is use to.

I strongly agree with the concept of not jumping on the new hot programming language of the month. Several times I've deliberately avoided learning some new languages because they offered insufficient new capabilities or advantages. Prime examples that spring to mind are C++, Delphi, C#. (But prime non-examples are Algol, one assembler (or microcode!), C, Smalltalk, Objective-C, Java, Mathematica, Matlab, analogue hardware, digital hardware, VHDL  ) 

However, that implies understanding the concepts of different languages and paradigms sufficiently well that you can evaluate what benefits they might offer to the problem in hand. Too few people do that. Too many people choose not to bother to do that.

Right tool for the job. Horses for courses. Etc

[MK14]

However, that implies understanding the concepts of different languages and paradigms sufficiently well that you can evaluate what benefits they might offer to the problem in hand. Too few people do that. Too many people choose not to bother to do that.

Right tool for the job. Horses for courses. Etc

Although, the new methods/tools.  Such as a decent debugger, for the tiny microcontroller.  May, supposedly offer various advantages in theory.  Which themselves, would improve productivity.

They can often involve a significant learning curve to climb, in order to make them as productive, as the previous method(s), used in the same circumstances.

E.g. If a person is currently using AVRshell, and is getting good results.  But coping with its limitations, compared to bigger and more expensive tools (if available and they exist, for the specific tiny MCU used).

It might be quicker and more productive, to stick with the existing tools, warts and all, because it delays or removes a possible time sink, with learning how to use complicated new tools/languages etc.

I suppose the best solution.  Is to make an informed/smart decision at the time.  As to which approach is best, under the circumstances with time/budget and other constraints needing to be taken into account.

Sometimes the true cost of changing to supposedly better tools/languages etc.  Is not fully understood.  E.g. Various homegrown utilities have to be rewritten, hardware changed, courses paid for.  New books and other stuff, may need to be obtained.  Some usage and other documentation guides (written by that person or department), may need to be revised or rewritten.

Also, current project constraint(s), especially as regards deliverables and their timescales.  May make it impractical to change tools/languages/equipment/manpower.

[tggzzz]

However, that implies understanding the concepts of different languages and paradigms sufficiently well that you can evaluate what benefits they might offer to the problem in hand. Too few people do that. Too many people choose not to bother to do that.

Right tool for the job. Horses for courses. Etc

Although, the new methods/tools.  Such as a decent debugger, for the tiny microcontroller.  May, supposedly offer various advantages in theory.  Which themselves, would improve productivity.

They can often involve a significant learning curve to climb, in order to make them as productive, as the previous method(s), used in the same circumstances.

E.g. If a person is currently using AVRshell, and is getting good results.  But coping with its limitations, compared to bigger and more expensive tools (if available and they exist, for the specific tiny MCU used).

It might be quicker and more productive, to stick with the existing tools, warts and all, because it delays or removes a possible time sink, with learning how to use complicated new tools/languages etc.

I suppose the best solution.  Is to make an informed/smart decision at the time.  As to which approach is best, under the circumstances with time/budget and other constraints needing to be taken into account.

Sometimes the true cost of changing to supposedly better tools/languages etc.  Is not fully understood.  E.g. Various homegrown utilities have to be rewritten, hardware changed, courses paid for.  New books and other stuff, may need to be obtained.  Some usage and other documentation guides (written by that person or department), may need to be revised or rewritten.

Also, current project constraint(s), especially as regards deliverables and their timescales.  May make it impractical to change tools/languages/equipment/manpower.

Oh, yes indeed.

A key skill is being able to quickly detemine what it isn't worth spending too much time learning. That leaves (too little ) time to learn what really is worth learning.

As for "right tool for the job", there are many factors in that, some technical, some financial, some policital, some cultural. And I'm sure there are others not covered by that!

[MK14]

Oh, yes indeed.

A key skill is being able to quickly detemine what it isn't worth spending too much time learning. That leaves (too little ) time to learn what really is worth learning.

As for "right tool for the job", there are many factors in that, some technical, some financial, some policital, some cultural. And I'm sure there are others not covered by that!

Also, even if you have the tools available, and are efficient at using them.  Unless it REALLY needs it, because of an extremely tricky bug or bugs.  It can save a lot of time and hassle, even setting up and using such equipment.

E.g. A multimeter, might take seconds, to grab and probe a circuit, to get the voltage across it.  But an oscilloscope, can take considerably longer, to get productive with it.

Edit: Made significantly shorter, but a bit more to the point.

[NorthGuy]

I once even used a pair of Teensys connected via UART (very short wires), so that I could use one to "pose" as a completely different USB device (a vinyl cutter), "playing back" captured USB data, but under the control of the other Teensy, and that other one controller by my program.

I did that too. With PIC32MK which has two USB modules and UART interface as well. So, let's stick to that example. I didn't use any debuggers or interpreted languages. I don't understand what is the relation to AVRShell.

A device which uses command protocol to inspect functioning of the CPU (including memory) is called a debugger. Many MCUs have hardware debugging interface which provides means to access CPU data. The debugger on PC uses command interface (although it's usually in binary form rather than ASCII format) to access MCU's debugging hardware. It then exposes CLI or GUI interface to the user. Debugging commands can also be transferred to remote locations (e.g. across Internet).

It is possible to create your own program which provides debugging functionality (such as AVRShell), even on an MCU where there's no hardware support for the debugger. But such implementations will always be inferior to hardware debugger.

If you simply need a command interface to your device, such as transferring commands which govern USB communications in the above example, you don't need neither debugger, nor AVRShell. In the simplest form, a single C switch statement to perform different actions in response to incoming UART bytes. How in the world AVRShell may help here?