#85

looking at the code both might have a problem when using the full int range. i’ve logged an issue on github: https://github.com/monome/teletype/issues/143

the 2nd issue is just likely not hitting it enough to get values outside of -32500 and 32700, i don’t see anything in the code that would cause this specifically.

will try to fix it in one of the future 2.3 betas.

#86

I’m definitely on it :wink: Sorry for the wait :bowing_man:

By the way, I was trying to understand the problem a little bit more by reading the i2c code on the teletype side also. I’m looking at:

It seems that there is no way for i2c communication to timeout on the teletype side? Is that a good idea in general? If you added some timeout logic to these potentially infinite loops:

	while (twi_is_busy()) {
		cpu_relax();
	}

with a purge of the receive/transmit queues and a reset of the i2c hardware. A lot of the teletype freezes might just go away?

Now back to cleaning up the garbage I’m putting on the i2c bus!

5 Likes
#87

thanks brian - really appreciate you taking the time to look into that!

re: i2c code - it’s not very resilient unfortunately and doesn’t handle any possible interruptions well at all. the previous fix was mostly making it the highest priority interrupt for this very reason (which did help a lot). your suggestions are absolutely correct - a timeout logic needs to be added (it should probably use a counter instead of a timer since it might be locking in an ISR that masks the timer interrupt), and then we’ll need to implement a bus recovery procedure as well.

4 Likes
#88

A post was split to a new topic: W/ Type Firmware Ideas

#89

can anyone corroborate?: LAST reports in 10ms increments for me.

unsure if it’s an issue (limitations haven’t been mentioned, so unsure how it should behave) or enhancement request, but I’d love to get lower if possible. @scanner_darkly, you mentioned this might be somewhere in the code?

#90

unless i’m missing something it should be possible to make it 1ms accurate (same for TIME), will include the fix in next beta.

3 Likes
#91

rad!!! <3333
thank you
do you need me to log anything on GitHub?

#92

if you could that’d be great!

#93

done! https://github.com/monome/teletype/issues/144

3 Likes
#94

Just a little behavior report…I have a pretty slim Scene running using the turtle function. Outputting info to an Ansible in Teletype mode. (Also have Telex and ER301 attached. After running for about 10 minutes, the scene stops accessing the CV info. Trigger’s keep happening and the unit does NOT freeze, but the CV no longer works. I can reload the Scene, but the CV is still inoperable. A restart gets things working again.

#95

you mean it stops updating the CV outputs? does it only affect ansible outputs or teletype as well? also, if you could test it with the official 2.2 version and see if you get the same behaviour that would be hugely helpful.

#96

I will explore your suggestions further this weekend. Thanks!

While I have you here…when addressing Kria from Teletype, are the patterns and positions addressed starting at zero or 1?

#97

looks like it’s 0 based

#98

Hello. FYI, I’ve released a new ER-301 firmware (v0.3.19) that silences all of the UART/I2C chatter that I possibly can. Unfortunately there is still a tiny bit of chatter remaining, right at the beginning of the boot up which I can do nothing about because it is burnt into the ROM factory boot code of the AM3352 CPU in the ER-301.

When powered on, the AM3352 starts executing boot code from ROM that brings up the SD card and searches it for a bootloader. During this process it sends the following message to the shared UART/I2C port:

Detected SD Card version : 2, High Capacity
bus width: 4-bit
bus freq: 25MHz

Other than that there is no activity on the lines. My preliminary tests show that the Teletype does not freeze during the ER-301 startup but I would like some confirmation please.

7 Likes
Teletype, er, emergency!
#99

great, thanks brian! i’m planning to bring a small system with er-301 and teletype to seattle synth meet next week, so this is great timing. i should be able to test it this weekend. worst case scenario i could implement a delay for i2c commands on startup.

3 Likes
#100

updated the firmware and did a quick test, looks like it still freezes if any i2c commands are executed within ~1 sec from turning it on (i tried 1.5 sec delay and that works, so the delay needs to be somewhere in the 1-1.5 sec range).

the proper solution would be to make the i2c code more resilient, but that’s a significant change that will have to happen at some later point. for now i could simply add a delay to the teletype bootup sequence. i think this is an acceptable solution, but curious what others think.

8 Likes
#101

I agree about it being the acceptable solution!
And thank you for tracking this down!

#102

I have a feature request for the Kria commands: would it be possible to create a couple of commands to define the beginning and end of Loop slots while in Meta mode? Asking for a friend…

#103

for kria requests you probably want one of these threads:

#104

Please do, it’s the best thing that can be done for now…