<xiangfu>
no. it's the 1 usb. 2 interfaces device.
<wpwrak>
ah :)
<xiangfu>
full-speed mouse give:
<xiangfu>
HC: Full speed device on port A
<xiangfu>
OK
<xiangfu>
USB: HC: Transfer start: RX timeout error
<xiangfu>
USB: HC: Control transfer failed:
<xiangfu>
USB: HC: SETUP reply:
<xiangfu>
USB: HC: (no data)
<wpwrak>
the 2 itf device works ?
<wpwrak>
(FS mouse) welcome to the club ...
<xiangfu>
yes. the 2 itf device works. as least bios know them.
<wpwrak>
it's flickernoise that counts :)
<xiangfu>
wpwrak, oh. maybe we should make the OSC message configure-able. like some can map to DMX. some of them map to MIDI. some of them map to some keys.(a-z) not hard code. then it can accept any
<xiangfu>
osc message from osc application.
<wpwrak>
i think we should e
<wpwrak>
send the whole control thingies through a common channel. midi, dmx, osc, ...
<wpwrak>
then assign them at will. the current structure is very specific to sebastien's setup
<wpwrak>
e.g., i have plenty of buttons to play with for selecting patches, but they all are MIDI controls, not MIDI notes
<xiangfu>
yes. that will be cool.
<xiangfu>
wpwrak, can you post your flickernoise somewhere. (don't want compile them today) thanks. (for make sure the mouse and 2itf device)
<isa_>
clear
<lekernel>
hi isa_
<wpwrak>
lekernel: i had a look at the SOFs. they all look good. they also seem to be received without significant loss or ignored errors (the ATmegaU2 can receive an invalid SOF, but then indicates this with a flag)
<wpwrak>
lekernel: i reduced the time between SETUP and DATA0, but that didn't do anything either
<wolfspraul>
is it possible that the device needs to receive something before all this to switch to full-speed ?
<lekernel>
no, devices are either full or low speed by design, you can't switch them
<wolfspraul>
lekernel: btw to conclude heise - I think they were not interested in the story
<lekernel>
otherwise i'd set everything to slow speed, which is enough for keyboard, mice and MIDI, and be done with that :)
<wolfspraul>
I wrote another reply (all in German) to rescue the matter, but that was a long shot already...
<wpwrak>
lekernel: a device can change speeds but only with a reset
<wolfspraul>
basically I think the reason is that they don't get the tech specs of the product
<lekernel>
wpwrak: but those are particular extensions, no?
<wpwrak>
"can change" as in "it has the choice to implement doing so, or not" :)
<wolfspraul>
if we position it strictly as an instrument (like an electric guitar), then they would probably also not be interested because they don't cover instruments (my guess)
<wolfspraul>
let me do a quick search for 'korg' on the heise newsticker...
<wpwrak>
it's not an extension. it's just a capability. the host has to deal with whatever the device says it is (that is, unless it's high-speed. then the device has to be prepared to downgrade)
<wolfspraul>
well, nothing, as I thought.
<wolfspraul>
so if we go the instrument route, heise is not interested
<wolfspraul>
and if we go the computer route, heise is also not interested
<lekernel>
wolfspraul: how did you position it so far?
<wpwrak>
wolfspraul: new mail ? where ? :)
<wolfspraul>
ah, this is just a small item I try to get through, no big 'positioning'
<wolfspraul>
they go to the links I give them and make up their own mind
<wolfspraul>
wpwrak: no new mail, just the one I cc'ed you on yesterday, to which there was no reply
<wpwrak>
ah, i see
<wolfspraul>
I think my explanation worked, but they don't carry instruments
<wolfspraul>
just search the ticker...
<wolfspraul>
nothing about korg, in years
<wolfspraul>
(for example)
<wpwrak>
that one didn't request any immediate action. it was more a clarification
<wolfspraul>
"traktor" - also nothing
<wolfspraul>
oh that's always very fast
<wolfspraul>
either he would have taken the story right away (yesterday) or not at all
<wolfspraul>
the story was "Milkymist One available in Europe" (with link to H:D)
<wpwrak>
heise do cover peripheral topics. they could still do M1 because of the FPGA SOC. doesn't change how you position it, though
<wolfspraul>
well
<wolfspraul>
search the ticker :-)
<wolfspraul>
no korg, no traktor, no instruments
<wolfspraul>
bottom line: we get there eventually, but my attempt yesterday failed
<wpwrak>
i'll write it down the next time they cover something about music :)
<wolfspraul>
there is a search box
<wolfspraul>
just try :-)
<wolfspraul>
in many years, basically nothing about korg
<wpwrak>
the search box needs the right keywords :)
<lekernel>
so, what about the architecture?
<wolfspraul>
maybe from a kernel source comment somewhere :-)
<lekernel>
wolfspraul: so let's announce something better?
<lekernel>
and do it if it attracts enough attention?
<wpwrak>
(speak up) i was still busy synchronizing with you when you answered :)
<wolfspraul>
article is from Nico Jurran nij@ct.de
<wolfspraul>
go for it! :-)
<wolfspraul>
oh any news coverage is good, worst case the news outlet burns their reputation, right? :-) I don't care why someone covers milkymist
<wolfspraul>
we know we are not a shady place etc.
<wolfspraul>
we can try the instrument thing again with Nico
<wolfspraul>
but I will cc Mirko Doelle definitely so they don't feel we try to play them
<wpwrak>
let's not rush it :) maybe make a draft, then let me comment ?
<wolfspraul>
one of the big no-nos - do not talk to multiple journalists from the same news outlet at the same time (independently)
<wolfspraul>
but we can try Nico and cc Mirko back in, or even reply to Mirko's mail and cc Nico in
<wpwrak>
yeah, sounds good
<wpwrak>
lekernel: regarding our discussion of adding a pixel processor to the video in or video feedback path, do you think we could say that "we're thinking about adding an extra effects processor to the pixel pipeline" ? ?
<wpwrak>
(as an example of what overwhelming flexibility the FPGA gives us)
<wpwrak>
wolfspraul: also don't underestimate mentioning our needs. heise are extremely FOSS-friendly. if they see a potentially attractive project that needs their help, they may consider this a strong motivator for reporting on it
<wpwrak>
wolfspraul: so you see, there are even two good reasons to mention investors :)
<wolfspraul>
ok fine, I don't disagree, but that's just theory
<wolfspraul>
I am talking about small practical little steps
<wolfspraul>
in the end you need an individual on the other side that gets your thing
<lekernel>
wpwrak: we can try, yes. but I'm not sure if that will make a big difference...
<wolfspraul>
they need to trust you, they need to know you are not talking a lot of bs, etc.
<lekernel>
anything M1 is so rapidly wrong when it comes to attracting attention :(
<wolfspraul>
once we have a Milkymist fan among heise journalists, stories will just flow by themselves
<wolfspraul>
I keep hearing from people that went to conferences that they were surprised how many others already knew about Milkymist
<wolfspraul>
in music I think we have more chances
<wpwrak>
very good :)
<wolfspraul>
whose the journalist there?
<wpwrak>
lekernel: you're way too pessimistic :)
<wolfspraul>
ableton live - roe
<wolfspraul>
pr is just work
<wolfspraul>
lots of work
<wolfspraul>
klinken putzen
<wolfspraul>
ableton live - bsc
<wolfspraul>
phew
<wolfspraul>
all different people
<wolfspraul>
oh well
<wolfspraul>
:-)
<wolfspraul>
bsd = Ben Schwan, bsc@heise.de
<wolfspraul>
bsc sorry
<wpwrak>
you can ask your current contact if there's perhaps someone else you should contact. but include the ready-made article.
<wolfspraul>
he
<wolfspraul>
I have a good intro at de-bug.de, I will try that first
<wolfspraul>
maybe there is a music lover at heise, but I'm not sure who it is right now
<wpwrak>
i'd suggest to keep the headline, 1st paragraph: description what it does and who'd use it. 2nd: the tech. 3rd: status of development (available for early adopters, still cleaning up for some months, need investors)
<wpwrak>
wolfspraul: from our side the main purpose would be to get the word to investors
<wpwrak>
lots of potential customers are not good at the moment
<wpwrak>
you don't have the devices to ship. there will be weeks before you have more. and the thing still needs a lot of work.
<wpwrak>
don't burn the customer's goodwill too early
<wpwrak>
you'd go fishing for customers when you're ready to sell and support 1000 units.
<wpwrak>
and you're not near to being ready for that. therefore, today's catch shall be investors. to make sure M1 will make it to the point where it can sell 1000+ units.
<wpwrak>
lekernel: btw, it's quite normal that you fall back on the specs on a long-running project. you can't afford to upgrade to the latest stuff all the time. particularly not if you're small, like we are
<wpwrak>
lekernel: there are some things that stick out, like low-speed USB and VGA. but we're fixing that :)
<wpwrak>
wolfspraul: on the tech, i would put the focus on 1) free and "complete" soc. not just some free core with proprietary peripherals or vice versa. or something that's barely good enough to blink a led.
<wpwrak>
and 2) on the ability to extend. e.g., the pixel processor.
<wpwrak>
lekernel: btw, regarding extensions, i think we'll also run into problems with turn-around time for ACKs and such. USB is very strict the timing there. you have just a few bit clocks.
<wpwrak>
lekernel: but we're not quite at a point where that would show up
<wpwrak>
yet
<wpwrak>
wolfspraul: and by getting the word out, maybe we'll also catch some developers. that would be very welcome, too. there's enough work for a few more people :)
<wolfspraul>
yes! but you and me talk about different things. you talk about theory, and I agree. and I talk about practical steps.
<wolfspraul>
the only way to get coverage is to get a journalist to help you
<wolfspraul>
and they are all individual people, like you and me
<wolfspraul>
I try to share my experiences with them, limited but still a little at least
<wpwrak>
lekernel: on with full-speed usb. i also looked at the bit timing. looks okay over all packets i checked. so i suppose it's accurate enough to catch all bits even if not recovering the clock in the middle (like my decoder does)
<wpwrak>
wolfspraul: okay, practical steps: write something with the three paragraphs i outlined above. send it with a comment like "after i've explained the background yesterday, this is what we think could be in a newsticker article". maybe also ask if you're barking up the right tree. maybe offer collaboration on a tech article for the print edition. (the latter would depend on sebastien)
<wpwrak>
collaboration or a guest article. whatever the format.
<wolfspraul>
I'll try something different :-) (cc you)
<wpwrak>
let's see :)
<wpwrak>
lekernel: regarding ACK/NAK timing: section 7.1.19.1, you have only 16 bit times to start sending the response to the device
<wpwrak>
i still haven't found a limit for SETUP to DATA0 time. but i'm not entirely sure that's because there is none or because i'm not reading the stuff right ...
<wpwrak>
actually, i shuoldn't read the usb 2.0 spec ... way too much high-speed spam in there
<wpwrak>
lekernel: with the full-speed device you have that gets past the first SETUP, does it later always fail at the same place ? or does this vary ?
<lekernel>
the bug I have is that the devices answers correctly, but the M1 often receives gibberish
<lekernel>
that will be the next one I think ...
<wpwrak>
hmm. that sounds a bit nasty. let's just hope the problem isn't in the analog domain in the end.
<wpwrak>
regarding response delays, also propagation delays counts there. so you even have less than 16 bit times before starting the ACK.
<wpwrak>
i still haven't found any clear statement on inter-packet delay in the same direction, except for a lower bound
<lekernel>
there's no ack so far
<lekernel>
one by one :)
<wpwrak>
yeah. we dodge that bullet ;-))
<lekernel>
right now it sends SOF, SETUP and DATA0 and it already fails
<lekernel>
but yes of course I expect massive problems and time wastage later on
<lekernel>
that's the essence of USB
<wpwrak>
;-)
<wpwrak>
it's designed with hardware in mind. they didn't contemplate your navre ;-)
<lekernel>
no, it's not
<lekernel>
when you design something for hardware, you do not inflict super-complex state machines for nothing
<lekernel>
USB is designed with insulting both hardware and software engineers in mind
<wpwrak>
maybe the rule was: "show no favourism" ;-)
<wpwrak>
hmm. maybe 16 bit times ... how many do we have ...
<wpwrak>
"As shown in Figure 8-20, the device uses its bus turn-around timer between token and data or data and handshake phases."
<wpwrak>
this MAY mean that there is a timeout between SETUP and DATA0
<lekernel>
ah, indeed
<wpwrak>
interesting. when i connect my HHKB (FS) and the Rii (LS), and power up, then the Rii doesn't work.
<wpwrak>
if i do the same with ATUSB and Rii, the Rii is fine
<wpwrak>
alas, the HHKB still doesn't work
<wpwrak>
is there a GPIO somewhere i could bang from navre (besides the transceiver controls) to indicate that i'm about to send a SETUP ?
<lekernel>
no, there isn't
<wpwrak>
let's try to cannibalize the other channel then ...
<lekernel>
if you use the RX speed bits, it should immediately reflect on the transceiver pins
<wpwrak>
great. let's try that then
<wpwrak>
i see something :)
<wpwrak>
SETUP DATA0 IN ACK
<wpwrak>
all a bit garbled because i'm monitoring only D+
<wpwrak>
let's fix this
<wpwrak>
oh, even better: [~SOF191][~SETUP0/0][~DATA0:00.05.01.00.00.00.00.00][~ACK][~IN0/0][~DATA1][~ACK]
<wpwrak>
let'see see what it sends next
<wpwrak>
by the way, this is with the nanoKONTROL2 now. easier to leave that one plugged in, instead of switching the keyboard all the time :)
<wpwrak>
the next message isn't so lucky: [~SOF192][~SETUP1/0][~DATA0:80.06.00.01.00.00.12.00]Â Â (no ACK)
<lekernel>
so you fixed something already, and it makes the devices answer (at least sporadically)?
<wpwrak>
maybe that's the effect of sending SETUP and DATA0 closer to each other. or maybe it always worked and i only saw it now (before trigger-on-SETUP, things were lost in a sea of SOFs)
<wpwrak>
i reverted to 4k navre because the new soc+bios just gave me a completely unresponsive system
<lekernel>
funny... works for me
<wpwrak>
note that the SETUP that got answered is in fact the very first SETUP that's sent. so it's not even sporadic
<wpwrak>
eventually, it will work for me, too ;-)
<lekernel>
so you just changed SETUP to DATA0 timing?
<wpwrak>
yes. plus the SETUP trigger instrumentation
<wpwrak>
the timing change brings them within about 10 bit clocks of each other
<lekernel>
and now, the first SETUP/DATA0 gets answered? great.
<wpwrak>
so if the device has the turn-around timer running there, then it would time out after ~16 bits
<wpwrak>
now the question is why the next SETUP isn't :)
<lekernel>
of course, I couldn't have counted on the totalphase software to tell me that I was sending DATA0 too late
<wpwrak>
why should it ? ;-))))
<wpwrak>
it's so much more fun if you find out on your own :)
<wpwrak>
when we debugged a nasty USB problem at openmoko, we had access to a nice analyzer that would tell you about all the transgressions you had committed. wish i had that one around now. alas, a bit pricy.
<stekern>
we have one of those laying around at work
<wpwrak>
(and in the end, almost useless for our bug hunt, because the problem was an unstable clock resulting in an unstable PLL that produced very weird error patterns when it finally reached USB)
<stekern>
they are pretty handy when having to deal with annoying usb problems
<lekernel>
stekern: which one? the totalcrap analyzer, or a proper one?
<lekernel>
I'm very surprised by the good reviews I read about the totalcrap analyzer
<stekern>
a proper one
<wpwrak>
most people probably have higher-layer problems to solve. they already have a chip that does bit timing and all that for them. they work at the level of ack'ing setups and such
<wpwrak>
stekern: pity .fi isn't closer to .berlin, or you could help sebastien
<stekern>
well, I've got a M1 on the way to me ;)
<wpwrak>
ah, excellent ! :)
<lekernel>
yeah, the closest place for such things seem to be Munich ...
<lekernel>
all the big electronics companies and distributors are there
<wpwrak>
roh: doesn't the CCC have some killer USB analyzer ?
<wpwrak>
ah wait .. the device also has the right to be silent after an address change
<wpwrak>
up to 50 ms
<wpwrak>
but that's done when it ACKs
<wpwrak>
i wonder if the IN phase makes sense in the SET ADDRESS
<wpwrak>
ah no, the IN is still there, no matter what. so this part is okay
<mumptai>
hi
<wpwrak>
whoa. here's a wild one. lots of noise, unfortunately. HHKB: [~SOF47D|001][~SETUP0/0][~E0?|00001100000000101000001000000000000000000000000000000000000000000000001101011110100100][~ACK][~IN0/0][~NAK][~78?|010+SE1[~0E?|001000][~42?|1011010][~][IN0/0][~NAK][~IN0/0][~NAK][~IN0/0][~DATA1][~ACK][~+
<wpwrak>
btw, i have an interesting trace: after a chat with the HHKB, M1 suddenly falls silent. not even a SOF. the trace is very long, so it'll take a few hours to download and analyze
<wpwrak>
lekernel: does milkdrop have video in ? or MIDI controls ?
<lekernel>
no, it does not
<lekernel>
that's a flickernoise addition
<GitHub27>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/TV-14w
<mwalle>
wpwrak: do you use it on a regular basis?
<wpwrak>
of course. it's my main keyboard. (hhkb pro) before i used a hhkb lite. and before, the original (ps/2). so that's well over a decade with these critters :)
<wpwrak>
alas, the hhkb vanished in asia. but the ps/2 one is still around. just don't have so many machines using ps/2 left. that is ... that may actually be a way to debug m1 usb and keep on typing. hmm ...
<lars_>
and does it make you happy?
<wpwrak>
yeah :) and it leaves a lot of room on my desk. room i can clutter with other things :)
<lars_>
i think i wouldn't be happy with shift and ctrl swapped ;)
<wpwrak>
yes ! original hhkb rides again ! ;-)
<wpwrak>
lars_: neither would i. therefore i use a keyboard that has them at the right place ;-)