<lekernel>
and I think turning the M1 into a regular computer will make our publicity problems worse if anything
<lekernel>
let's have high resolution digital video inputs (DVI/HDMI) instead. that's where we can have an advantage, both technically- and marketing-wise.
<lekernel>
also we need a totally new UI. most people do not dare clicking into the FN GUI, let alone write patches and talk about it
<lekernel>
something in the style of reactable would look a lot more attractive
<lekernel>
having to choose, I largely prefer spending time on developing a portable, RF-based reactable surface rather than USB shit no one will care about because the proprietary semiconductor industry is already doing it a thousand times better than us
voidcoder has joined #milkymist
voidcoder has joined #milkymist
<lekernel>
after we're out of the closet, then we can think about resource-intensive and low-reward things like USB
<lekernel>
mwalle: what Xst warnings are you suppressing exactly here? some of them are useful at (rare) times...
<lekernel>
This issue has been fixed in 13.3. 13.3 XST produces an INFO message instead of the WARNING message without any change to the actual information or message.
<mwalle>
lekernel: mh, ok then i should update my xst ;)
<mwalle>
lekernel: do you know some other warning messages which can be filtered?
<mwalle>
the patch should be a first step to bring the sheer amount of messages a bit down
<GitHub69>
[milkymist/master] softusb: remap timer to 0x20..0x23 - Michael Walle
<GitHub69>
[milkymist/master] softusb: convert to non blocking assignments - Michael Walle
<lekernel>
mwalle: hmm, no, haven't really looked. and the warnings are only one component of the xilinx toolchain's logorrhea...
<mwalle>
bbl lunch
<lekernel>
mwalle: what would you think of not checking the validity of the CRC in hardware and simply forwarding the crc5 and crc16 values to the navre?
<lekernel>
then you don't have to detect and store the PID in hardware
<lekernel>
mwalle: I suppose the overflow bit is only meant to be read at the end of the reception of a whole packet?
<lekernel>
(as well as the other error bits)
<wpwrak>
hmm, isn't -Werror a bit extreme ? when debugging, you quite often generate code that produces warnings. if you have to edit and then un-edit the Makefile each time, that's messy
voidcoder has joined #milkymist
xiangfu has joined #milkymist
lekernel has joined #milkymist
mumptai has joined #milkymist
voidcoder has joined #milkymist
<mwalle>
wpwrak: maybe introduce a debug flag? or override the flags?
<wpwrak>
mwalle: well, you could add a switch that enables -Werror (and maybe other things). CFLAGS_EXTRA or such.
voidcoder has joined #milkymist
<mwalle>
lekernel: and forwarding the crc5_error and crc16_error (not the values imho) should work too, i havent looked at the cycles we have left to generate an ack/nack after packet reception
<wpwrak>
mwalle: in normal development, -Werror shouldn't be necessary. the build should be silent enough that you can spot the warning. it's not like xst ;-)
<wpwrak>
(cycles0 very few :)
<mwalle>
wpwrak: (flags) so it boils down to opt-in or opt-out the -Werror
<mwalle>
imho it should be enabled by default, and if someone doesnt like it (because hes debugging and too lazy ;)) he/she should be able to turn it off
<lekernel>
wpwrak: so you think there's no time to check the PID, fetch the appropriate CRC5 or CRC16 value, and validate it?
<wpwrak>
lekernel: that's probably fine. would need testing, though. if i remember correctly, it's about 6.5 bit times
<wpwrak>
lekernel: that is, from EOP to the start of the response
<wpwrak>
mwalle: i'd rather enable -Werror only in the rare case of completely unattended builds. that would be mainly xiangfu's builds.
<wpwrak>
mwalle: also, we may sometimes have warnings we can't get rid of easily. e.g., if there's an upstream issue.
<wpwrak>
mwalle: flickernoise has one such warning
<mwalle>
6.5 bit times would be 26 avr cycles, right?
<mwalle>
(at full speed)
<mwalle>
wpwrak: (not our warnings) ok good point ;)
<mwalle>
lekernel: if you read a whole value, you would have to make sure its still valid when you're reading it
<mwalle>
eg there was no transition on rx_active
<mwalle>
putting two error flags (crc5 and crc16), into the error register and let the processor decide which flag to use should work if it fits into 26 cycles but makes the error register somewhat unintuitive, because there will always be at least one bit set)
<wpwrak>
mwalle: (avr cycles) hmm, not sure. i usually check the timing on the scope. but it should be in that range, yes. i.e., enough to do something, but not enough to do a lot
<wpwrak>
mwalle: in fact, in our case the timing is a bit more relaxed because we don't have support hubs. but if you use that "buffer", you'll have one additional problem to solve once hub support is added. so ...
<lekernel>
mwalle: what about two error registers then? if(PID=xxx) err = REG_CRC5_ERROR; else err = REG_CRC16_ERROR;
<lekernel>
and reading any of these two registers clears both
<mwalle>
lekernel: is your navre cycle acurate with the avr one?
<lekernel>
I haven't tried to make it so, but both navre and avr execute most instructions in 1 cycle
<mwalle>
lekernel: branches, too?
<lekernel>
no, branches stall the pipeline
<wolfspra1l>
lekernel: which RF did you have in mind when you mentioned "RF-based reactable surface" earlier?
<lekernel>
probably custom in the MHz range; I mean RF as in replacement for a bulky videoprojector + infrared + webcam setup
<wolfspra1l>
don't understand
<wolfspra1l>
the new devices has a custom RF that communicates with what?
<wolfspra1l>
if it's custom, then on the other side there needs to be a 2nd device?
<lekernel>
the reactable senses the objects from under the table by lighting them with infrared and filming with a webcam
<lekernel>
this requires the webcam to be placed at a certain distance so it can capture the whole table
<lekernel>
and also requires a videoprojector for the picture
<lekernel>
the idea is to turn that into a slim tablet by using RF and a communicating microcontroller in the objects
<wolfspra1l>
hmm, ok
<wolfspra1l>
I have never used a reactable myself, but I could imagine the look and feel of the table to be a big part of why people like that experience
<wolfspra1l>
you would need a huge tablet too, no?
<wolfspra1l>
and the table is round
<lekernel>
use a TV flat screen
<wolfspra1l>
and the fact that the projector comes from underneath may give a nice impression, don't know
<wolfspra1l>
but yeah ok, I got it now
<wolfspra1l>
make physical objects that communicate with a milkymist base station over some custom rf
<lekernel>
how would the projector be better than a TV screen? seems to me the picture quality is worse with a projector
<wolfspra1l>
I don't know, just thinking
<wolfspra1l>
have you used a reactable yourself?
<lekernel>
the objects can be pretty small too
<wolfspra1l>
whether someone likes something or not can depend on very small details
<lekernel>
actually, they can be smaller than with the original reactable :)
<lekernel>
we'd just have to stick a 5x5mm AVR in them, plus a few passives
<wolfspra1l>
and a round table with bottom side illuminiation etc. already is quite something special to start with
<lekernel>
not a pattern big enough for the webcam to catch
<wolfspra1l>
it seems their physical objects need no electronics at all either, no battiers
<wolfspra1l>
tteries
<lekernel>
we can have wireless power
<lekernel>
no batteries either
<wolfspra1l>
how?
<wolfspra1l>
you can get the energy across over RF?
<lekernel>
for example, with a large coil around the screen
<lekernel>
yes, sure
<lekernel>
I'd actually like to pump a lot of it, so we can even have flashy LEDs and stuff on the objects
<wolfspra1l>
I mean I understand the physics that theoretically you can, but I'm wondering what we can power on the other side :-)
<lekernel>
1W sounds feasible
<lekernel>
as long as the magnetic field doesn't mess up with e.g. the screen or its control electronics
<wolfspra1l>
we need to re-read the ISM band duty cycle limitations again :-)
<lekernel>
it won't be ISM band
<lekernel>
we're talking about low frequency near field communications
<lekernel>
so we can even use the AVR to modulate - no special transceiver needed
<wpwrak>
you probably want to get rid of the webcam
<lekernel>
frequency for power and milkymist->object communication would be 100kHz or so
<wolfspra1l>
sounds interesting
<lekernel>
then we can sense the object's position with its low power transmission received with an array of PCB printed coils
<lekernel>
the object, of course, can incorporate a host of gadgetry (LEDs, accelerometers, buttons, what not)
<lekernel>
we can make them arduino compatible, even :)