MH ET Tiny88 & V-USB & MIDI #520
Replies: 31 comments 12 replies
-
|
It's a great place to post about it as far as I am concerned! I would love to gain a general understanding of what can and cannot be made to work with VUSB - I have to say, I hate how there are so few options for USB if we wamt to write for AVR. It's VUSB (which per my issue, I've never made work right), or the 32u4, which I dislike on multiple levels, or.... Nope, there's no "or", those are your choices! And I prefer to keep writing AVR - the AVR instructions are much easier to hold in one persons' brain vs 32-bit instructionsets, so you can reach a really deep level of understanding and feel the silicon under your fingertips... |
Beta Was this translation helpful? Give feedback.
-
|
Thinking aloud ... If I re-write the loop() to eliminate the delay() calls and instead call millis() and count the time since last state change, it doesn't make any real difference, and still dies after what I imagine are the a similar number number of USB data transfers. Calling underlying USBMIDI poll and flush operations as often as possible makes no difference. So I don't think in this case it's caused by delay() blocking. DrAzzy's comment about knowing the assembly inside out made me think of one thing. Because the USB timing is critical there are different ASM includes for each clock speed, in the VUSB driver. In this case it's usbdrvasm16.inc, and I did check that was the one being included. However, am I correct in thinking that the timings are based on Mega parts? The good news is that we seem to be sticking to the instruction set subset supported by tiny parts, e.g. no multiplication, but is it possible that the timings are "off" when compiled with a tiny core? I lack the detailed knowledge to drop in and read out the clock cycles in the ASM but might be worth a look. the only other convenient part I have to hand to test this is a digispark tiny85 running at 16.5 Mhz, so it's not quite a like-for-like comparison. |
Beta Was this translation helpful? Give feedback.
-
|
And also the comments for the usbdrvasm165.inc specifically mention TINY parts like tiny45 running with t16.5MHz PLL, but the usbdrvasm16.inc doesn't mention the processor type; it may be that the 16 MHz version was implicitly for an atmega328 ... |
Beta Was this translation helpful? Give feedback.
-
|
As long as it is running on ext crystal or clock, 16 should be fine. That's
what th 167 does!
…____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore: Arduino support for almost every ATTiny microcontroller
Contact: spencekonde@gmail.com
On Sun, Feb 21, 2021, 13:36 prandeamus ***@***.***> wrote:
And also the comments for the usbdrvasm165.inc specifically mention TINY
parts like tiny45 running with t16.5MHz PLL, but the usbdrvasm16.inc
doesn't mention the processor type; it may be that the 16 MHz version was
implicitly for an atmega328 ...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#520 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW2VFT6NE3DJNZBPYLDTAFHBFANCNFSM4X7CYFAQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
And - the instruction timing on tinyAVR classic vs megaAVR classic is the same. The tiny's are missing a few instructions, but since the code works, it's nothing important for this purpose. It's very important if you're trying to multiply two numbers, though ;-). See https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-Instruction-Set-Manual-DS40002198A.pdf Does it work on a Digispark Pro (the 167 ones, which also use 16 MHz clock? If that works, well, what's different? |
Beta Was this translation helpful? Give feedback.
-
|
... and the upload of the code over USB still works fine - so what is the difference between (V-USB-)bootloader and (V-USB/Digispark)-sketch? Even when it's only sample-code!? |
Beta Was this translation helpful? Give feedback.
-
|
Further googling: Last released version I can see from obdev.at is back in 2012, and certainly that's the version that ships with my example USBMIDI library The code certainly seems pretty stable, but there is a forum where people post a few comments from time to time. Found this report from 2017 "Jitter in usbdrvasm16.inc" Which suggests a tweak needed for the 16MHz timing. I am not competent to judge if it's correct or not. |
Beta Was this translation helpful? Give feedback.
-
|
Well like, they could well be built from a different copy of the asm... one
that's been fixed? Have you compared with the version used by micronucleus
itself?....
…On Sun, Feb 21, 2021 at 4:34 PM pcfreak1201 ***@***.***> wrote:
... and the upload of the code over USB still works fine - so what is the
difference between (V-USB-)bootloader and (V-USB/Digispark)-sketch? Even
when it's only sample-code!?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#520 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW7OSNTEJXE6CWGRYTDTAF36LANCNFSM4X7CYFAQ>
.
--
____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for
all pre-2016 tinyAVR with >2k flash!
megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support
for all post-2016 tinyAVR parts!
DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR
Dx-series parts, the latest and greatest from Microchip!
Contact: spencekonde@gmail.com
|
Beta Was this translation helpful? Give feedback.
-
|
... but |
Beta Was this translation helpful? Give feedback.
-
|
The comment about USB timing being different for 0 vs. 255 makes no sense.
As for MN, it is quite different since it is not interrupt based. Tim
explained it well years ago:
https://cpldcpu.wordpress.com/2014/03/02/interrupt-free-v-usb/
If you want to make a custom USB device I would not recommend V-USB unless
you are looking for a difficult challenge. For a cheap 8-bit MCU with USB
I like the CH551.
http://nerdralph.blogspot.com/2020/07/getting-started-with-wch-ch551-and-ch552.html
…On Mon, Feb 22, 2021, 02:29 pcfreak1201 ***@***.***> wrote:
... but timing will depends of sending data. zero data (0x00) will have
~10% less duration than (0xff) would mean it walks bad when you count up
(as in my serial example), but should start OK?! I think that would be
something for @nerdralph <https://github.com/nerdralph> ;-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#520 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKNZ6TG3WJTWPZTCKQG37TTAH2V7ANCNFSM4X7CYFAQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
So the "TL;DR" is that Micronucleus doesn't even use V-USB? |
Beta Was this translation helpful? Give feedback.
-
|
WTH - using the Pin-Change-Interrupt-Register, but no interrupts?! Genius! And I ever learned: polling is bad, interrupts are good ... ;-) |
Beta Was this translation helpful? Give feedback.
-
|
You could say that. You'll still find most of the original V-USB asm
and even some of the C code. Last year I started a fork to replace
most of the C code with hand-optimized asm, though I didn't change the
core asm tx/rx loops.
https://github.com/nerdralph/micronucleus-firmware/tree/asm
…On Mon, Feb 22, 2021 at 10:33 AM prandeamus ***@***.***> wrote:
So the "TL;DR" is that Micronucleus doesn't even use V-USB?
Or at least, to put on my Spock Ears, it's V-USB, Jim, but not as we know it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
|
In summary it seems, therefore
A useful next step would be have a regular (non-bootloader) app that builds on #2 and see it's possible to re-incarnate a standalone VUSB-style library from the micronucleus work. It would be interesting to factor micronucleus into two projects, one for the VUSB alone, but I confess I'm way out of my comfort zone and current skill set here. I guess it's a question of whether this is an itch that someone out there wants to scratch. |
Beta Was this translation helpful? Give feedback.
-
|
It's hard to summarize accurately because it's rather complicated. With
some careful work on ATTinyCore, it could be made to work reasonably well
with V-USB. The 12MHz interrupt-driven V-USB works reasonably well with an
external xtal oscillator, and when the tight interrupt latency requirements
(around 25-30 cycles) are met. For ATTinyCore, that would mean a rewrite
of things like millis. I've written a size-optimized asm version for
ArduinoShrink, and with a couple tweaks it could be modified for latency
and speed.
https://github.com/nerdralph/ArduinoShrink/blob/master/src/t0_ovfl_isr.S
Anything that disables interrupts for more than a few cycles cannot be used
or would have to be rewritten. So if ATTinyCore uses the original Arduino
core's shitty digitalWrite implementation, you couldn't use it safely with
V-USB. Also most software serial implementations could not be used.
Something like the Tx portion of my WGM UART could work since it impacts
interrupt latency by <10 cycles.
http://nerdralph.blogspot.com/2020/06/a-full-duplex-tiny-avr-software-uart.html
Then if you want V-USB to work with the internal RC oscillator, there's a
few more things you need to do right.
So it's not an impossible goal, but it does require someone very skilled in
both low-level AVR programming and the USB protocol.
…On Tue, Feb 23, 2021 at 5:27 AM prandeamus ***@***.***> wrote:
In summary it seems, therefore
1. Interrupt driven V-USB isn't really fit for purpose as a generic
library in the way that DrAzzy would like. This is not to disrespect the
many hours that have gone into development of it; I know enough to respect
the insight that allowed it to be created in the first place and also know
that I don't have the skills or diagnostic kit to improve it myself.
2. The polling version is more reliable across a wide variety of
platforms but doesn't exist as a standalone library, is only part of
micronucleus. At least, I couldn't find one, your mileage may vary
3. Polling version inside micronucleus has potential for further
hand-optimisation as per nerdralph's from last year.
A useful next step would be have a regular (non-bootloader) app that
builds on #2 <#2> and see
it's possible to re-incarnate a standalone VUSB-style library from the
micronucleus work. It would be interesting to factor micronucleus into two
projects, one for the VUSB alone, but I confess I'm way out of my comfort
zone and current skill set here. I guess it's a question of whether this is
an itch that someone out there wants to scratch.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#520 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKNZ6VHJDMS6ZSU4IWJSNDTANYGLANCNFSM4X7CYFAQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
Let's not forget about the cop-out! "Okay then,If you want VUSB, okaaaay -
but it's gonna cost you" and put a list of all the things you can't do if
using VUSB.
Can the USB functionality be turned on and off? ie, could one be in USB
mode for a few seconds, do the USBish thing you needed to do, and then be
like "Okay, I'm done with this USB shit, gonna disconnect from that, kick
millis back on and go back to disabling interrupts for milliseconds at a
time" and then 10 minutes later, when someone pushes the big red button,
gun the timekeeping and everything else that slows down interrupts too much
for that, do my USB-thing (say, manifest as a keyboard and type some
profanities). If yes, that makes restriction-laden USB seem "not bad at
all"
If all one needs in order to do to get VUSB declaring yes, if you don't
happen to care busie, then who cares if it;s got a laundrylist of
restrictions, just toss an "enable USB" and "disable USB" function,
document what is broken while it's enabled, and go crack open a cold one
and relax...
On the official Digispark core, were these things busted/gimped? Was the
core tweaked to hell so that it did work (which would mean that this was
the secret sauce if the digispark boards - as it would appear to be at
least an order if magnitude more difficult than anything else that making a
core for this purpose would be...)?
One thing I can give a complete guarantee of is that I will not have the
time to dig all that much into USB functionality itself - modified
libraries that check that the user has enabled/disabled the requisite
settings, menu options, straightforward changes to the core? sure. But hot
like, deep stuff. Remember that I have two more cores to maintain and that
damned day job. Not to mention a life (what're ya'll looking at? If zero is
a number, I have a life!)
Tagging @ArminJo - you seem to have a lot of experience with these things,
do you have any comment on this? Do you agree with @nerdralph's assessment
here, I got the impression from your other posts that you had a better time
with it?
On Tue, Feb 23, 2021 at 9:06 AM Ralph Doncaster <notifications@github.com>
wrote:
… It's hard to summarize accurately because it's rather complicated. With
some careful work on ATTinyCore, it could be made to work reasonably well
with V-USB. The 12MHz interrupt-driven V-USB works reasonably well with an
external xtal oscillator, and when the tight interrupt latency requirements
(around 25-30 cycles) are met. For ATTinyCore, that would mean a rewrite
of things like millis. I've written a size-optimized asm version for
ArduinoShrink, and with a couple tweaks it could be modified for latency
and speed.
https://github.com/nerdralph/ArduinoShrink/blob/master/src/t0_ovfl_isr.S
Anything that disables interrupts for more than a few cycles cannot be used
or would have to be rewritten. So if ATTinyCore uses the original Arduino
core's shitty digitalWrite implementation, you couldn't use it safely with
V-USB. Also most software serial implementations could not be used.
Something like the Tx portion of my WGM UART could work since it impacts
interrupt latency by <10 cycles.
http://nerdralph.blogspot.com/2020/06/a-full-duplex-tiny-avr-software-uart.html
Then if you want V-USB to work with the internal RC oscillator, there's a
few more things you need to do right.
So it's not an impossible goal, but it does require someone very skilled in
both low-level AVR programming and the USB protocol.
On Tue, Feb 23, 2021 at 5:27 AM prandeamus ***@***.***>
wrote:
> In summary it seems, therefore
>
> 1. Interrupt driven V-USB isn't really fit for purpose as a generic
> library in the way that DrAzzy would like. This is not to disrespect the
> many hours that have gone into development of it; I know enough to
respect
> the insight that allowed it to be created in the first place and also
know
> that I don't have the skills or diagnostic kit to improve it myself.
> 2. The polling version is more reliable across a wide variety of
> platforms but doesn't exist as a standalone library, is only part of
> micronucleus. At least, I couldn't find one, your mileage may vary
> 3. Polling version inside micronucleus has potential for further
> hand-optimisation as per nerdralph's from last year.
>
> A useful next step would be have a regular (non-bootloader) app that
> builds on #2 <#2> and
see
> it's possible to re-incarnate a standalone VUSB-style library from the
> micronucleus work. It would be interesting to factor micronucleus into
two
> projects, one for the VUSB alone, but I confess I'm way out of my comfort
> zone and current skill set here. I guess it's a question of whether this
is
> an itch that someone out there wants to scratch.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <
#520 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ABKNZ6VHJDMS6ZSU4IWJSNDTANYGLANCNFSM4X7CYFAQ
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#520 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW5NITTKPYQ4Y5AVL4LTAOY5RANCNFSM4X7CYFAQ>
.
--
____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for
all pre-2016 tinyAVR with >2k flash!
megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support
for all post-2016 tinyAVR parts!
DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR
Dx-series parts, the latest and greatest from Microchip!
Contact: spencekonde@gmail.com
|
Beta Was this translation helpful? Give feedback.
-
|
You could turn the V-USB interrupt on and off, which would be OK depending on the protocol used. For things like emmulating a USB keyboard or mouse, this would not be an option since they are polled by the OS up to every n millisec, where n is the bInterval field of the endpoint IN descriptor. I got a few digisparks shortly after they were released (digispark v2 Kickstarter Special Edition), and it was not any technical marvel. Even though the early versions of the MN bootloader used an unmodified V-USB snapshot, if you used V-USB in your sketch, a second copy of the V-USB code was used. The arduino core didn't have any special optimizations. Older versions of Windows were less strict with USB compliance than Win10, so some digisparks running V-USB stopped working when people upgraded to Win10. There's also subtle bugs that only appear in certain situations. For example I have a few USBasp programmers, which use what I believe is the most stable V-USB implemenation (12MHz, external xtal). The only interrupt used in the firmware is for V-USB. Plugged directly into one of the USB ports on my PC, I've never had any problems with the USBasps. I have an external hub that works with all of my other USB devices, except the USBasp. If the USBasp is the last device plugged into the hub, it usually works. If I plug another device into the hub after the USBasp, it usually doesn't work. For anyone who wants to try experimenting with V-USB (or other bit-banged USB implementations like usbtiny), I strongly recommend getting your project working first with an external xtal. When I was re-writing the C portions of MN in asm, I switched from developing on the t85 to a m88 with a 12MHz xtal. With the t85, if it failed to enumerate, I never knew if it was a bug I introduced, an intermittent bug that was already in MN, or RC oscillator timing issue. For those that are brave enough to forge ahead with a project to effectively integrate V-USB into ATTinyCore, I suggest you read this first: |
Beta Was this translation helpful? Give feedback.
-
|
Okaayy.... well then, moving right along.
|
Beta Was this translation helpful? Give feedback.
-
Just to clarify. My repo consists of the most upToDate micronucleus executables and a bunch of tested bootloaders. The original libraries including the VUSB ones are left as they were found except for a few bug fixes, some deletions, warnings for CDC examples and some improvements for the Keyboard example. |
Beta Was this translation helpful? Give feedback.
-
Not that I expect Microchip to officially recognize it, but I'd say it's perfectly safe. The t88 I baked twice at 150C and flashed over 200,000 times still works fine. |
Beta Was this translation helpful? Give feedback.
-
|
@ArminJo "bug fixes, some deletions, warnings for certain examples and improvements for others" you say? But totally nothing like a new version? Okay, whatever you want to call it ;-) When I download libraries when I was first looking at adding the libraries right after 1.4 came out... I found a set... try to use them,, and they give the error when const isn't used in progmem, it leaves me with ZERO faith in the library, because it means nobody has compiled it in eons. Hey, at least Microchip consistently refuses to acknowledge that their product is inconsistent with the datasheet. It could be worse they could only acknowledge accidental features and vehemently deny the existence of any bugs. ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Well, the last version I'd grabbed wound up being so ancient that they let
progmem be declared without const!
…On Wed, Feb 24, 2021 at 4:14 PM Armin ***@***.***> wrote:
* track down a version of the libraries that has been most recently updated (probably the ArminJo ones),
Yust to clarify. My repo consists of the most upToDate micronucleus
executables and a bunch of tested bootloaders. The original libraries
including the VUSB ones are left as they were found except for a few bug
fixes, some deletions, warnings for CDC examples and some improvements for
the Keyboard example.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#520 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW2BO72PF7EDQ6PVDY3TAVT27ANCNFSM4X7CYFAQ>
.
--
____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for
all pre-2016 tinyAVR with >2k flash!
megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support
for all post-2016 tinyAVR parts!
DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR
Dx-series parts, the latest and greatest from Microchip!
Contact: spencekonde@gmail.com
|
Beta Was this translation helpful? Give feedback.
-
|
Here's the official repo:
https://github.com/obdev/v-usb
On Wed, Feb 24, 2021, 21:36 Spence Konde (aka Dr. Azzy) <
notifications@github.com> wrote:
… Well, the last version I'd grabbed wound up being so ancient that they let
progmem be declared without const!
On Wed, Feb 24, 2021 at 4:14 PM Armin ***@***.***> wrote:
> * track down a version of the libraries that has been most recently
updated (probably the ArminJo ones),
>
> Yust to clarify. My repo consists of the most upToDate micronucleus
> executables and a bunch of tested bootloaders. The original libraries
> including the VUSB ones are left as they were found except for a few bug
> fixes, some deletions, warnings for CDC examples and some improvements
for
> the Keyboard example.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#520 (reply in thread)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ABTXEW2BO72PF7EDQ6PVDY3TAVT27ANCNFSM4X7CYFAQ
>
> .
>
--
____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support
for
all pre-2016 tinyAVR with >2k flash!
megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino
support
for all post-2016 tinyAVR parts!
DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the
AVR
Dx-series parts, the latest and greatest from Microchip!
Contact: ***@***.***
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#520 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKNZ6XYH332Q7ZHL7GUYSTTAWSSTANCNFSM4X7CYFAQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
To reset the discussion a little, I took a different approach and have some limited success to share. I ditched the USBMIDI wrapper, which perhaps tries to do too much. (It tries to use real USB if Leonardo-style hardware is available but switch back to VUSB otherwise.) Found a simpler wrapper for MIDI over VUSB-only at https://github.com/heartscrytech/DigisparkMIDI and installed that in libraries. Wrote the following test code that sends 12 notes in sequence on a repeat, with an LED diagnostic. // https://github.com/heartscrytech/DigisparkMIDI #include <DigiMIDI.h> #define LED 0 void setup() { void loop() { } This works with the ATTinyCore on both a Digispark Tiny85 and an MH-ET Tiny88 board. HOWEVER usbconfig.h needs to be edited because there's no tiny88 support in this version and the defaults are wrong The #else block labeled "ATtiny2313, ATmega8/48/88/168" around line 48 is the catch-all when the processor isn't recognised. I hacked USB_CFG_DMINUS_BIT from 3 to 1 and it seems to work fine for Attiny88 #define USB_CFG_IOPORTNAME D The "proper" solution no doubt is to add a new conditional section for the tiny88 processor, but this is an adequate patch to get up and running. Installed this, I get the lsusb Bus 002 Device 072: ID 16c0:05e4 Van Ooijen Technische Informatica Free shared USB VID/PID pair for MIDI devices and aconnect -l shows client 20: 'MidiStomp' [type=kernel,card=1] I can connect input from 20 to my timidity syhtn on port 128 aconnect 20 128 And hey presto, a very dull sequence of piano notes. This simple test DOES work even though millis() is enabled- it's called in the DigiMidi.delay() method while polling USB. There are not other interrupt functions so apart from mills() processing I suppose everything else works in the foreground. Hope this helps other people! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the report. |
Beta Was this translation helpful? Give feedback.
-
|
Oh siiiiick! That's fuckin baller dude!
I, uh, dont suppose ya could give us a PR with that there workin version?
Since the next release will bring in digispark USB libraries that work, if
you've adapted one so it works? >.>
I wonder if we could have like, a core supplied config file, to have a
single source of truth regarding what pins the usb is on and the like? Now
*that* would really add some value here....
…____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore: Arduino support for almost every ATTiny microcontroller
Contact: spencekonde@gmail.com
On Fri, Feb 26, 2021, 12:54 prandeamus ***@***.***> wrote:
To reset the discussion a little, I took a different approach and have
some limited success to share.
I ditched the USBMIDI wrapper, which perhaps tries to do too much. (It
tries to use real USB if Leonardo-style hardware is available but switch
back to VUSB otherwise.) Found a simpler wrapper for MIDI over VUSB-only at
https://github.com/heartscrytech/DigisparkMIDI and installed that in
libraries.
Wrote the following test code that sends 12 notes in sequence on a repeat,
with an LED diagnostic.
// https://github.com/heartscrytech/DigisparkMIDI
// MIDI wrapper around V-USB
#include <DigiMIDI.h>
#define LED 0
// 1 for Digispark (ATTiny85)
// 0 for MH ET Tiny 88 (ATTiny88)
void setup() {
pinMode(LED, OUTPUT);
}
void loop() {
for (byte k=0;k<12;++k) {
DigiMIDI.update();
digitalWrite(LED, 1);
DigiMIDI.sendNoteOn(62+k, 32);
DigiMIDI.delay(200);
DigiMIDI.update();
digitalWrite(LED, 0);
DigiMIDI.sendNoteOff(62+k);
DigiMIDI.delay(200);
}
}
This works with the ATTinyCore on both a Digispark Tiny85 and an MH-ET
Tiny88 board.
Digispark - works out of the box. Diagnostic LED on pin 1
MHETTiny888 - Diagnostic LED on pin 0,
HOWEVER usbconfig.h needs to be edited because there's no tiny support in
this version and the defaults are wrong
The #else block labeled "ATtiny2313, ATmega8/48/88/168" around line 48 is
the catch-all when the processor isn't recognised. I hacked
USB_CFG_DMINUS_BIT from 3 to 1 and it seems to work fine for Attiny88
#define USB_CFG_IOPORTNAME D
#define USB_CFG_DMINUS_BIT 1
#define USB_CFG_DPLUS_BIT 2
The "proper" solution no doubt is to add a new conditional section for the
tiny88 processor, but this is an adequate patch to get up and running.
Installed this, I get the *lsusb*
Bus 002 Device 072: ID 16c0:05e4 Van Ooijen Technische Informatica Free
shared USB VID/PID pair for MIDI devices
and *aconnect -l* shows
client 20: 'MidiStomp' [type=kernel,card=1]
0 'MidiStomp MIDI 1'
I can connect input from 20 to my timidity syhtn on port 128
*aconnect 20 128*
And hey presto, a very dull sequence of piano notes.
This simple test DOES work even though millis() is enabled- it's called in
the DigiMidi.delay() method while polling USB. There are not other
interrupt functions so apart from mills() processing I suppose everything
else works in the foreground.
Hope this helps other people!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#520 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW35NJJYX45KKGX6MV3TA7N45ANCNFSM4X7CYFAQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
I'd be honoured, but not quite sure about best way to package it. It would probably be better to add a new define for attiny88 to the usbconfig (because the hack I used is just that, a hack). Also because the way that vusb has to be packaged I'm not 100% sure I will disentangle it from the midi library neatly. But I can have a go. If anyone else can do it quicker/better than me I have no objections. |
Beta Was this translation helpful? Give feedback.
-
|
TBH the thing that really matters here is a common usbconfig.h for all (reasonable) processors supported by the tiny core. The rest of the files can listed with whatever version of V-USB is most current, yes? |
Beta Was this translation helpful? Give feedback.
-
|
OK so my version of usbconfig,h (the one that ships with DigisparkMIDI anyway) has two sets of configurations, and may be incomplete for our purposes. At the top of the file there's a section that sets the port, bit number for USB+ and bit number for USB-. The configuration options here are for
Clearly, I need to add a section for Tiny48 and Tiny88, and I know what those lines would be. Not a problem. Question #1 - what other #defines are needed and what ports and bits to specify? The guidance seems to be that USB D+ must be wired to INT0 "or any other interrupt so long as it is the highest level interrupt" The D- can be any other pin on the same port. At the bottom of the file there are some other over-ride settings for various interrupt flags etc. the "Optional MCU Description" area
Note this list is much shorter, all the other chips use the "default" settings. This is much less comprehensive. There are lots of overrides for the 87/167, and a few for the 45/85. I'm sure there's a reason to pick PCINT1_vect for the 87/167 or SIG_PIN_CHANGE for the 45/85 vector, but I have no idea why it was done this way, or how to extend it to other chips in the core. I'm guessing that DrAzzy would have better guesses here having had more experience with the different parts. Question #2 - any idea why these particular overrides were chosen? I certainly don't have the hardware (or to be honest, the inclination or the patience) to test all of these. And given that even on the same MCU it could be implemented with different combinations of ports, pins and interrupts, it might be better to build some documentation/recommendations based on existing practice, rather than trying to set everything in stone in a single header file which has enough options already. TL;DR maybe the solution is to have a "Common practice" guide for how to set up usbconfig.h for a given MCU? We can then work on it and incrementally fill in the blanks over time. |
Beta Was this translation helpful? Give feedback.
-
|
Oh - and a more straightforward part of what I was asking for is like, just the library itself, like the stuff that does the midi... |
Beta Was this translation helpful? Give feedback.
-
|
References to the ATmega parts can be excised. Does this core support any ATmega processors? No? Kill em with fire! It looks like the requirements are: SIG_PIN_CHANGE? I suspect they used that because dinosaurs walked the earth back when they wrote that! Note also that the ATtiny861 is not available as a commercial board as far as I can tell. It's pin choices are not sacred until I list the hardware in my Tindie store ;-) (though to be clear, this is not expected to be a money maker so much as a way to let people play with one; I'll probably also make a version that uses bulky through-hole parts to sell for cheap as the bare board I'd picked a different pair for the boards I showed. That said, I don't like the pins I chose; I think I would prefer to use their pins! (assuming my comments in wiring_analog.c are correct regarding how PWM could be handled on the 861, if we can't get sane PWM out of PB4, then USB would be PB4 and 6, instead of 5 and 6. I'm gonna do a respin of all of these before I start assembling more than the 3 of each that I already have; one key error I want to avoid is sticking with a crappy design decision instead of respinning before there are a bnch of the bad ones floating around. Sooooo I think I'm gonna do PC4, PC5 for the 1634 (that's what my current prototypes have wired - and as long as the internal oscillator can be tweaked hard enough to work, it's spectacularly convenient, because it bunches all the least-reusable-pins close to each other and at the end of the numerical order - PC3, is reset, then 4 and 5 are USB pins, and in the upcoming rationalized pinout for the 1634, the pins will start at PA0, through to PA7 as pin7, pins 8 I think we're using the Wattuino design as our implied reference design for 841. I don't think anyone else is making them right now? |
Beta Was this translation helpful? Give feedback.
-
|
In any event, - sorry, I started rambling, and sometimes having an imagined conversation explaining upcoming plans and decisions to someone is helpful.... it doesn't make any sense to me that this stuff is in a usbconfig.h file in the library folders. Shouldn't these values be in a header in the variants folder - either part of pins_arduino, or some extra header file located in variants directory? |
Beta Was this translation helpful? Give feedback.
-
|
(also, interesting - it sounds like 15 works better than 16 - does that mean, when we have a super-clock like on t841, we should tweak the internal oscillator towards 15 rather than 12 or 16?) (vast majority of them can hit 16 MHz - I have one that needs to be up in at like 252 or 253 on OSCCAL0, but they all get there :-P |
Beta Was this translation helpful? Give feedback.
-
|
Another thing that does not make sense to me in that config is why, when the USB D+ pin is on INT0 on the 167/87, would they use a PCINT for that instead of INT0? Surely INT0 is preferable if you're using that pin for VUSB? |
Beta Was this translation helpful? Give feedback.
-
|
Nice looking boards, especially the narrow-pitch ones which leave lots of free room on a breadboard. I can't figure out what you'd need 8 resistors for though. Maybe you're not using all of them? |
Beta Was this translation helpful? Give feedback.
-
|
2 blocks of 4. Didn't need 4 of the 68 ohm ones, but I've had poor yield with 2-resistor networks, the 4's seem more cooperative. And the the The other one is the pullup for the usb line and ballast for the LED - I did two designs, one where usb pullup went back and forth through resistor twice, and the other where I paralleled two resistors for the LED ballast. I like the first way (used on the wider board) better. That LED is bicolor - an independent red and blue, in a 1206 size package; the pads are split down the middle, I default to one as power LED one as userled, but but cuttable trace on underside and solder bridge jumper to make it into another one controlled by i/o pin. |
Beta Was this translation helpful? Give feedback.
-
|
Argh! Nope, can't do what I was hoping with PWM on the 861, read more carefully.... what a stupid timer :-( I don't like that part, though it's ADC is pretty spectacular... Why'd they have to give the epic ADC to the red haired stepchild of the ATtiny product line?I 861 will be either PB5, PB6 or PB4, PB6 - I suspect the 4 and 6 because if I can get three PWM channels out unencumbered, I'd like to do that rather than wasting one of those pins on USB.... It's not like the 861 is exactly rolling in PWM channels, |
Beta Was this translation helpful? Give feedback.
-
|
Well, here's a try at a silly music sketch, which plays about half a minute of the Liberty Bell March if you plug it into a MIDI-aware PC or whatever. Requires the DigiMIDI library. Since I'm compiling for an ATTINY88 I've modified the usbconfig.h as mentioned above, otherwise it's stock. Using a no-bootloader option to maximise progmem space. The timing is slightly screwed here and there and I suspect that's a fault in the conversion tool I am using to convert the midi data to hex. The more I look at the DigiMIDI library though the less I like it. It gets the job done but it's a hack of hack and needs some rework. Anyway it does work well as proof of concept. |
Beta Was this translation helpful? Give feedback.
-
|
I extracted the board/CPU specific parts to a usbboardconfig.h file in all 5 examples using V-USB like here https://github.com/ArminJo/DigistumpArduino/tree/master/digistump-avr/libraries/DigisparkMouse. |
Beta Was this translation helpful? Give feedback.
-
I'm not sure if this is the best place for this discussion, but what better place to ask? There has been some talk elsewhere about the V-USB config for MH ET-Tiny88 boards. I am trying to create a MIDI controller using the USB port and here's what I've found so far
hardware - I can measure resistance of 68R between USBD+ and D2, and also between USBD- and D1
That seems reasonable, also consistent with using INT0 (D2) for D+ interrupts
Install the USBMIDI library 1.1.6. This contains own copy of v-usb with its own usbboards.h
ATTINY88 board not covered in conditional compile options here, so I trashed it and replaced with
#define USB_CFG_IOPORTNAME D
#define USB_CFG_DMINUS_BIT 1
#define USB_CFG_DPLUS_BIT 2
Compile for ATTINY88, 16Mhz external clock, program as follows
/* START LISTING */
// https://github.com/BlokasLabs/usbmidi
#include <midi_serialization.h>
#include <usbmidi.h>
//Example given here:https://github.com/BlokasLabs/USBMIDI/blob/master/examples/midictrl/midictrl.ino
#define LED (0)
// Digispark 1, MH-ET Live Tiny88 0
void sendCC(uint8_t channel, uint8_t control, uint8_t value) {
USBMIDI.write(0xB0 | (channel & 0xf));
USBMIDI.write(control & 0x7f);
USBMIDI.write(value & 0x7f);
}
void sendNote(uint8_t channel, uint8_t note, uint8_t velocity) {
USBMIDI.write((velocity != 0 ? 0x90 : 0x80) | (channel & 0xf));
USBMIDI.write(note & 0x7f);
USBMIDI.write(velocity &0x7f);
}
void setup() {
pinMode(LED, OUTPUT);
}
void loop() {
USBMIDI.poll();
// Read any incoming data to avoid lockup, but we don't care about it
while (USBMIDI.available()) {
(void) USBMIDI.read();
}
digitalWrite(LED, 1);
sendNote(0, 64, 127);
USBMIDI.flush();
delay(500);
USBMIDI.poll();
while (USBMIDI.available()) {
(void) USBMIDI.read();
}
digitalWrite(LED, 0);
sendNote(0, 64, 0);
USBMIDI.flush();
delay(500);
}
/* END LISTING */
The idea is that it connects on the USB port, then sends the same note on/off message in a loop.
Good news - it is recognised in lsusb
Bus 002 Device 014: ID 16c0:05e4 Van Ooijen Technische Informatica Free shared USB VID/PID pair for MIDI devices
Following aconnect -l, ALSA shows it has been recognised as a MIDI device
client 20: 'USBMIDI' [type=kernel,card=1]
0 'USBMIDI MIDI 1 '
The LED flashes for a few cycles and then sticks to the ON state, so it seems to be ok at setup but maybe some sort of timing issue? If I change the values in the delay() calls I get the same behavior, so it seems to be the number of passes through the loop rather than the absolute timing.
I am using stock ATTinyCore 1.4.1 and have not used the bleeding-edge github branch.
If anyone has insight into this, I'd be grateful. Posting here in case it helps others in future. (Though, to be honest, given that it's hard to find positive examples of anyone getting this to work, I am I thinking about finding a board with USB hardware support).
Beta Was this translation helpful? Give feedback.
All reactions