Adventures with I2C & Minerva Mk2

[t0nyt]

Have decided to start on the first SuperBASIC assembler extension, have chosen the Speech synthesis module as it gives the best feedback on whether it's working as planned

I was wondering if anyone has any comments/suggestions/etc. on my proposed new keywords, or anything else, please?

Have chosen i2c_say as the root of the commands

Code: Select all

When extension loads?
Check &40 responds on i2c bus

i2c_say_init 		Just sends $AA
Also call at load?

i2c_say("text")
Options below can specified in string e.g. "[v9][s2]Hello"

i2c_say_stop		Stop current speech
i2c_say_pause		Pause current speech
i2c_say_resume		Resume paused speech

r=i2c_say_status() 	Check chip status
returns $41 - frame received ok
	$4E - chip busy
	$4F - chip idle

i2c_say_reset		[d] & set defaults below

i2c_say_volume(0 to 9)  [v4]
i2c_say_speed(0 to 10)  [s5]
i2c_say_tone(0 to 10)   [t5]
i2c_say_delay(ms) 	[p0]     
i2c_say_lang(0,1,2)	[g2]
I2c_say_how(0,1,2)	[h2]
i2c_say_mode(0 to 6)	[e0]

Many thanks
Tony

[t0nyt]

I was wondering, as they can all be incorporated into the "text" at any point anyway, whether to just scrap all the option keywords (like volume, tone, etc.) and just have an i2c_say_help command that lists all the options (and valid values)?

[Dave]

As i2c_ and say_ appear in *every* command it seems either one or the other is redundant. Is the i2c aspect important to the functionality? I'd personally drop the i2c_ part for clarity, if only because there are no other BASIC keywords with numbers in them, and I can't think of any off the top of my head that have two underscores in them. It just seems overworked.

[t0nyt]

As i2c_ and say_ appear in *every* command it seems either one or the other is redundant. Is the i2c aspect important to the functionality? I'd personally drop the i2c_ part for clarity, if only because there are no other BASIC keywords with numbers in them, and I can't think of any off the top of my head that have two underscores in them. It just seems overworked.

There's I2C_IO, so I thought "I2C_" was a good way to prefix all my own extensions to make it clear they are i2c only and ensure no clash with anything else that might exist?

The "say" was because this is the Text-to-Speech extension e.g. i2c_say("Hello World")

I could go with I2C_SAYINIT I guess for the others to keep the amount of underscores down to 1

I'm really not sure as I hadn't even considered multiple underscores would be seen as an issue

Thanks
Tony

[Dave]

I think it's more to do with the fixed capitalization of BASIC keywords. Seeing things turned into I2C_Say_Resume or etc..... It does seem like Sinclair put a lot of effort (even if accidentally) into their keyword design. The command says only what it needs to. Capitalization was used carefully to communicate not just the keyword but the abbreviation of it, eg: DEFine PROCedure expanded from DEF PROC.

With how BASIC keywords are parsed, alas, there isn't a universal handler for the I2C command, where SAY could be the first argument. You're adding I2C_Say with arguments. Original SuperBASIC keywords sometimes has _i or _o extensions as part of the keywords (mostly in TT toolkits) but natively sometimes made the IN or OUT selection an argument, not the keyword itself.

I know it's petty. I don't have a cop badge. No "respect my authoritAAAH!" I simply think if you're creating a keyword and others might use it, a certain degree of thoughtfulness should go into the command structure. The simple fact you asked out thoughts tells us it is on your mind.

A bunch of keywords handled separately doesn't feel as nice as having a shorter, more global command with the variations being hung off the keyword in the first argument. It keeps KEYWORD listings crisp. It makes for a more unified and structured approach to creating new functionality. It also keeps the BASIC keywords linked list shorter so BASIC runs more quickly. I'm a little OCD about these things, I guess. It's coming from a good place, I promise!

I supposed that if you asked for opinions about your keywords you'd be open to all feedback. Even the useless, lame, petty or OCD feedback


CRaKeD - The Campaign for Rational Keyword Design!
Founding and only member ever, me

[t0nyt]

I get what you are saying Dave, but it's a bit of a conundrum for me

I'm probably looking at writing about a dozen extensions for the I2C stuff

Putting them all into a single keyword and using an argument to specify if it's Speech Synthesis, LCD, temperature, humidity etc. doesn't work for me because it means the code for all of them having to be loaded to just use 1 device. e.g. the speech synthesis extension will be quite small but the LCD (&OLED) will be much larger so why load all that just to be able to get the QL to speak?

I'm of the opinion that anything I do write will always be aimed squarely at a BBQL and loading all I2C devices in a single bin is a waste of the QL's resources?

Putting all the various options into a single keyword for each bin is doable though, something like

I2C_SPEECH("hello world")
I2C_SPEECH(i2c_reset)
I2C_SPEECH(i2c_pause)

Do you have any specific suggestions of some other way of handling this example please?

Many thanks
Tony

[t0nyt]

or maybe

I2CSPEECH("hello world")
I2CSPEECH(i2c_reset)
I2CSPEECH(i2c_pause)

[Dave]

Ello,

It doesn't help that there are a variety of speech and LCD protocols that would have completely different drivers.

This is one of those times where if you'd thought in this way about the overall structure of the commands you were creating, you might have done it differently from the foundation up. A basic I2C class handler, or lower down having broad "SPEECH", "DISPlay" or "SOUND" handlers which then pass arguments to the specific functions handling volume, erasing, displaying, etc. in the usual pipes/channels manner.

You're here and you have working code. Going back and reformatting it all now is a lot of energy spent for aesthetics of a language that is at the end of the day only used by a few dozen or low hundreds hobbyists. Nobody's going to fuss at you for the command structure. You're better off investing your time extending features and squashing bugs.

I'm just here to show that there is a way that SuperBASIC was designed to approach BASIC command structure and when reasonable we should try to follow it. Like tea or water in the desert, don't be fussy. Just be grateful for the hydration!

I appreciate your work adding utility and support for specific available modules. I am thinking of incorporating official I2C support, encouraged by your efforts. I already have SPI hardware support via a Microwire UART. No bit-banging required and some nice RX and TX FIFOs to make it easier to handle. It would be nice to move I2C from bit-banged to a parallel to serial interface. This could be implemented in a really small CPLD or the tiniest corner of an FPGA.

Kindest regards,

Dave

[XorA]

Write the code, worry about the colour of the bikeshed later!

[t0nyt]

Have had to put all this on hold for now

I'm feeding the Minerva ROM the correct parameters, as far I'm concerned from reading disassemblies/manuals and debugging as far as I can at the moment, but it insists "bad paramater"

The only way I'm going to get to the bottom of this is learning how to debug the SBASIC I2C_IO function to check what it's putting in D2 (am sure it it should be $400001 for what I'm doing). Debugging shows the minerva ROM is using my command buffer, so D2 is what I need to get to the bottom of

But I've never tried to debug a "function" on a QL before!

For I2C_IO("Hello",0,64,1) which is (<text>,<return buffer size>,<device id>,<bytes to send to device>)

The I2C_IO code gets the string parameter and then reads a word which is the buffer size (which it uses "as is" to reserve the needed memory size) then reads as long the 3rd and 4th parameters at once into D2 so for my example I'd expect it to have to be $400001 in D2 that it passes to the minerva ROM as I2C_IO doesn't manipulate it