Teletype trigger specification

jlmitch5 · 2018-04-12T04:34:08.854Z

I am curious if anyone happens to know the specifications as to what constitutes a valid trigger signal to one of the teletype inputs. It seems that Teletype can be somewhat picky when it comes to trigger/gate inputs. For example, a trigger may work with something like a sawtooth envelope, but it seems to be spotty (maybe triggering the script ~80% of the time.

I’d be happy to add the info to the docs (checked there, and there didn’t seem to be anything about what kinds of signals it accepts).

Also, just curious, I’ve tried to look in the codebase, and this seems to be the handler for when a trigger happens, but I can’t figure out the code that actually calls the handler (the code that is interfacing with the hardware that’s saying, “that was a trigger”).

ngwese · 2018-04-12T05:06:27.900Z

I don’t personally know… but since you are looking at code…

I’m fairly confident that finding the answer (without doing lots of experimentation) probably requires knowledge of the hardware itself. I believe the trigger inputs are driving GPIO pins on the AVR microcontroller. There is likely circuity to protect the GPIO pins (from modular level signals) and possibly debounce the inputs which could effect what signals are seen as triggers.

The code which runs in response to the hardware interrupt generated by the whatever constitutes the “rising edge” on the GPIO pins associated with the TR inputs is here:

github.com

monome/libavr32/blob/master/src/init_teletype.c#L75-L86


// interrupt handler for PA00-PA07
__attribute__((__interrupt__))
static void irq_port0_line0(void) {
for(int i=0;i<8;i++) {
  if(gpio_get_pin_interrupt_flag(i)) {
    // print_dbg("\r\n # A00");
    event_t e = { .type = kEventTrigger, .data = i };
    event_post(&e);
    gpio_clear_pin_interrupt_flag(i);
  }
}
}

…that code sticks an event value into a queue. The main TT code is a big loop which repeatedly pulls one event off the queue and processes it - eventually calling the function referenced above.

edit: This is a really long winded way of saying that unfortunately in this case the code isn’t going to provide the desired insight

tehn · 2018-04-12T13:28:29.087Z

here’s the digital input schem. cross-referenced with the datasheet for the at32uc3b0256 a spec should be be possible

17%20AM

jlmitch5 · 2018-04-12T14:14:14.407Z

@ngwese Thanks, that was really helpful! For others who are curious, it looks like the connection pieces that attach handler_Trigger and kEventTrigger together are:

(global initialization of the array of various event handlers, pretty useful comments in there that step through things)

github.com

monome/libavr32/blob/7170c9ab03ab4754197fa91b55bde6e2fb21aadd/src/events.c#L19


#include "compiler.h"
#include "print_funcs.h"


#include "interrupts.h"
#include "events.h"


static void handler_Ignore(s32 data) { }


// global array of pointers to handlers
// initialise all it's entries to handler_Ignore
void (*app_event_handlers[kNumEventTypes])(s32 data) = { handler_Ignore };




/// NOTE: if we are ever over-filling the event queue, we have problems.
/// making the event queue bigger not likely to solve the problems.
#define MAX_EVENTS   40


// macro for incrementing an index into a circular buffer.
#define INCR_EVENT_INDEX( x )  { if ( ++x == MAX_EVENTS ) x = 0; }


// et/Put indexes inxto sysEvents[] array

(attaching kEventTrigger to handler_Trigger. handler_Trigger is what actually causes the TT script to run)

github.com

monome/teletype/blob/35ddaf3e6c1dacb74429477dfb752d8df75e9eca/module/main.c#L454


void assign_main_event_handlers() {
empty_event_handlers();


app_event_handlers[kEventFront] = &handler_Front;
app_event_handlers[kEventPollADC] = &handler_PollADC;
app_event_handlers[kEventKeyTimer] = &handler_KeyTimer;
app_event_handlers[kEventHidConnect] = &handler_HidConnect;
app_event_handlers[kEventHidDisconnect] = &handler_HidDisconnect;
app_event_handlers[kEventHidTimer] = &handler_HidTimer;
app_event_handlers[kEventMscConnect] = &handler_MscConnect;
app_event_handlers[kEventTrigger] = &handler_Trigger;
app_event_handlers[kEventScreenRefresh] = &handler_ScreenRefresh;
app_event_handlers[kEventTimer] = &handler_EventTimer;
app_event_handlers[kEventAppCustom] = &handler_AppCustom;
}


static void assign_msc_event_handlers(void) {
empty_event_handlers();


// one day this could be used to map the front button and pot to be used as
// a UI with a memory stick

@tehn Thanks for pointing me in this direction. I will see what I can find (neat opportunity to learn how to get info from a datasheet, which I have not done before) and report back.