Search

Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Please let me know what you guys think. I'm experimenting with removing the C runtime alltogether.
There's a line that are commented out. The 'goto __reset' might be a spillover from the C compiler. If I remove the semicolon,
it seems to change the order of the segments.

Active Member

Now I've played around with an ATMEL ATMEGA 16A running at 20MHz.
I know, You wanna using a Microchip Controller, but I have no experience with that.
In simulation a complete keyboard scan need's about 250µs.
A scanning restart will be done every 300µs.
( The Timing I've taken from the DD-E512 Datasheet there was used 250µs ).
So one velocity step is 300µs. The longest possible velocity cycle wanna be 37,5ms
I don't think a microchip controller works much faster.

What are the results:
There is not much processing time for other tasks.
I guess it's better to use a dedicated controller for keybed scanning process, when using velocity.
Using of assembler will be a must, when want scanning speed up.

Active Member

There is not much processing time for other tasks.
I guess it's better to use a dedicated controller for keybed scanning process, when using velocity.
Using of assembler will be a must, when want scanning speed up.

Active Member

I been time travelling ..year 2005 I last looked at my MiDi interface.. as previous post it had no velocity count (single contact manuals ) , but as I remember mcu had 5ms to scan the 132 note keys .. bear in mind I was restricted to the organs 8085 mpu scan time .. (only some of the time code was actually used scanning the keys) . far as i can read from my code.. scan was interrupt based .. the key buffer returns were sequentially read into a key NEW_MAP after the last scan , code return from ISR .. now NEW_MAP is bit compared with OLD_MAP .. down keys =0 . up keys are 1 , some maths needed to decide if down key is a new down key likewise a up key is a new up key .. changed keys positions are then coded to a note value and placed in the correct channel MiDi byte frame ... and dropped into USART ...then NEW_MAP becomes OLD_MAP .. NEW_MAP is cleared ready for the next scan.. the PIC mcu was running at 20Mhz (5 MIPS) as it will do 125k baud exactly ! .. for the scan reader PIC there was no time for any thing else..

Active Member

The ATMEGA runs nearly with 20 MIPS at 20 MHz ( XMEGA is faster too ).
With velocity the complete keybed ist to read 127 times faster than with a simple switch.
Ok You can make some optimations e.g. Read Line 2 only when Line 1 is active, but would this be really faster?
So 70 MIPS is not oversized.

Active Member

MIDI Keyboard actions have come a long way. Look at the 104 key computer keyboard.
There's not 104 scan lines, but they're arranged in rows/columns.

So, you write out a 3 (or 4) bit scan code (to energize one row) and you read the column data in as a set of bytes or words in a faster CPU.

Nobody uses switch contacts in MIDI keyboards anymore. They all use the rubber cup / conductive foam contact, which is designed to minimize key bounce.
It's even used in computer keyboards, because it simplifies the CPU code necessary for reading the row/column.

Originally, I chose the PIC18F452 to do this project. Then, I was ordering parts for something else I was building and I saw the PIC24F series CPU.
So I pulled the data sheet and went with a chip that was through-hole.

So I bought 2 of them, along with 8mhz crystals for the 24F and 10MHZ crystals for the 18452.
If I hadn't found the TQFN to DIP adapter, I wouldn't have been able to use the 304 at all.

Worse case, I'll go with a faster CPU. or a KA304 as the key scanner and a KA302 to handle MIDI communication. They would communicate using SPI.
That would complicate things,.

Also, I have to scan 3 of the A/D ports for pitch bend, modulation, and MID volume.

Anyhow, we'll know next week when the parts come in.

On a side note: There are -no- good examples of how to program the 24FxxKA30x using Assembler with MPLAB-X.
As I progress with this project, the software will become more robust and the source code will be available here.

Active Member

For info, the pic24 and dspic33 use the same assembly language - there may be more examples available for them.

It does not look like Microchip really expect people to use assembly for these devices; it uses the x16 C compiler as an assembler, which makes things a bit odd possibly.

Re. other posts - I'd advise doing the key scan in a high speed timer "clock" interrupt, read the inputs then update the scan outputs each interrupt.
The time between interrupts allows for any changes to settle at the input side, ready for the next cycle.

That does away with any hold up due to looping through things. The CPU is easily fast enough to do everything you need!

Active Member

For info, the pic24 and dspic33 use the same assembly language - there may be more examples available for them.

It does not look like Microchip really expect people to use assembly for these devices; it uses the x16 C compiler as an assembler, which makes things a bit odd possibly.

Re. other posts - I'd advise doing the key scan in a high speed timer "clock" interrupt, read the inputs then update the scan outputs each interrupt.
The time between interrupts allows for any changes to settle at the input side, ready for the next cycle.

That does away with any hold up due to looping through things. The CPU is easily fast enough to do everything you need!

Active Member

Active Member

mj
I think You should make some thoughts about the used Display.
When the 2.3" OLED is too big, You can also use a 0.93" one.
Like this:https://www.ebay.de/itm/0-96-inch-I...71820294:m:myVYDcG4a519hJqIZoBrHxw:rk:12:pf:0
When I would make such a thing like a keytar i would implement splitting points and a free routing of controllers to the pots.
And free set of a MiDi channel to the splitted keys and additional a transpose function.
Additional some presets to space different settings.
A normal 3*7 segment can only display numbers but no alphanumeric characters.
For normal use You can take a big font and let it look like a 7 Segment Display.
For make Settings it is possible to use up to 8 lines with 20 characters.

The disadvantage is that to transfer much more bytes to the display, but with hardware SPI this should be no problem.

Active Member

mj
I think You should make some thoughts about the used Display.
When the 2.3" OLED is too big, You can also use a 0.93" one.
Like this:https://www.ebay.de/itm/0-96-inch-I...71820294:m:myVYDcG4a519hJqIZoBrHxw:rk:12:pf:0
When I would make such a thing like a keytar i would implement splitting points and a free routing of controllers to the pots.
And free set of a MiDi channel to the splitted keys and additional a transpose function.
Additional some presets to space different settings.
A normal 3*7 segment can only display numbers but no alphanumeric characters.
For normal use You can take a big font and let it look like a 7 Segment Display.
For make Settings it is possible to use up to 8 lines with 20 characters.

The disadvantage is that to transfer much more bytes to the display, but with hardware SPI this should be no problem.

I will need 3 potentiometers. One for pitch bend, one for modulation, and one for volume.
I will need a button for sustain as well as buttons for transpose and for choosing zones.

If I wanted to save on hardware, I can allow the user to switch the keytar into a programming mode
and use the keyboard to choose a MIDI channel and the split from the keybed.

Just about all of the keyboard makers do the same thing to save on hardware costs.
Also, I could add a smaller PIC just for handling the display. I would have to map the settings to a stream of SPI data
and send it to the second PIC. That would offload the display stuff, freeing up the main CPU for handling the keybed / hardware scan.