26

(32 replies, posted in Hardware)

The Mega 2560 has enough I/O pins, but uses a separate ATmega16U2 as the USB interface. You could run the keyboard matrix scan code on the larger ATmega2560 chip, and just run a basic USB HID interface on the ATmega16U2 that provides the USB port?

The two have their UARTs connected together already on a mega2560, so I guess the effort just now is in making sure the ATmega16U2 is going to be happy with the HID code on it. Otherwise, this should work fine - just a shame it needs two uC's.

You could also just use a small atmega for USB and a decent pin-count CPLD to do the scan, of course. I think that'll actually work out more expensive, but it might be more novena-y, since people will be working in Verilog/VHDL for the FPGA anyway, so the CPLD will be familiar territory.

27

(208 replies, posted in Hardware)

If there's one more left, I'd like one too please! I've dropped you a forum email already.

28

(1 replies, posted in Hardware)

Replying to myself in case someone else has this too:

I rebuilt the bit file myself in WebPACK with some trivial unrelated changes (inverted some of the LED outputs, so I could see if the new version was indeed loaded or not), and the newly-built version works fine. The original bit file from github still causes the same problems for me. I'm guessing there's a timing constraint that isn't quite tight enough, and it's hit or miss whether or not the build happens to make the timing thresholds required.

Rebuilding from source unchanged gives the original fault again, so it's completely reproducible for me.

EDIT: Found that I can fix this now by changing
OFFSET = IN 4125 ps VALID 4750 ps BEFORE "bclk";
to
OFFSET = IN 4100 ps VALID 4750 ps BEFORE "bclk";
in the constraints file. Might be useful if anyone else has the same problem.

29

(1 replies, posted in Hardware)

I've been looking at the example for the GPBB, and I thought I'd just run through the out-of-the-box test behaviours and so on. I find that the -testcs1 option to novea-gpbb seems to fail the loopback test:
root@novena:/home/jamie/gpbb/novena-gpbb-example-master# ./novena-gpbb -testcs1
0: deadbeeffeedface
0: deadfeeffeeffeef
1: 5555aaaa33339999
1: 5555ffffbbbbbbbb

I get this result about half the time if I run it in a tight

while true; do ./novena-gpbb -testcs1; done

loop it's somewhat inconsistent and does sometimes yield the right results. It almost never does so on first run, by the way. It doesn't seem to be affected by mechanical wobbling or anything, so I'm somewhat assuming it's a timing thing and just down to the exact performance of my board, but I'm not certain.

Has anyone else tried this, and what results did you get if you did?