Search results

Ooh, that is great news! Hopefully the net.c cleanup is making your life easier, but if you have suggestions for changes there I'm all ears. On the hard drive side, I've pushed fixes for several bugs but I haven't gotten the underlying boot issue Chopsticks experienced figured out completely...

Good news (sort of): I tried a different SD card, starting from scratch with a 'size=2048' file in fast mode, and I think I've been able to replicate this issue. I'll dig into it and figure out what's going on. That's a good hint, and probably points to a SCSI transfer getting stuck. That's...

Thanks for trying it out so fast! I'll dig into the network lockups tonight and see if I can replicate them on my hardware. The issue with 'fast' is weird, I haven't had anything like that here. Is the sluggish performance happening with 'forcefast' too?

All three are still supported, like so: "normal" accesses through the FAT filesystem only. Highest compatibility, but slow with larger cluster sizes (particularly on FAT32). "fast" is low-level access bypassing the FAT filesystem, but only after the continuity check clears: before that it acts...

Well, this is different. Right off the bat, I want to acknowledge how much help I've received with this project over the last few months, particularly from @Chopsticks and @superjer2000. Many of the vanished posts in this thread contained feedback given while graciously testing my red-hot code...

Yeah, I completely agree. This board was the first "big" project I tried with 0605 components, and oh man, they really push the limit for what I can do by hand. This is definitely something that would benefit from factory assembly, at least of the passive components, or reflowing in one of those...

Whoa, unplugging the Ethernet cable unfreezes the mouse? That's really weird. The firmware ignores the link detection information in the PHY and never reports anything other than the link being present on the SCSI media sense command, so unplugging should have no effect on program flow at all...

The network cable is very interesting. Does that happen every time you try it? A crash immediately if the cable is connected, and a crash on restart/shutdown if the cable is disconnected? One other thing: does the on-board LED start blinking a half-second on, half-second off thing at any point...

The crash on AppleTalk startup makes me think there is something weird going on with this particular board, FWIW. The test firmware is not comprehensive, it was written quickly to help diagnose soldering issues where pins were bridged or a whole chip was borked. More subtle issues may be missed...

Based on what you're describing, I'd guess there is a hardware problem on the new board. I added a test dongle design and firmware for helping to diagnose these issues on Github; if you have a chance, try that out, it may give a hint as to what's going on. The documentation is a little out of...

When I had trouble doing this, I had to get into scsi2sd-util and hack in additional debugging to get more than the a terse "things didn't work" message. I don't have the modified versions I made, unfortunately. To roll your own, in scsi2sd-util.cc there's a (myHID->scsiSelfTest() ? "Passed"...

Ah, I get what you guys are aiming for. Just to explore the concept: It looks like a 2.5" HDD is about 100x70mm, which is basically the same size as this board, so the circuit could probably still fit OK. You'd want to keep the base SCSI interface and SD card, but rip out the ENC28J60 and...

On the power side, after doing some more research I don't believe the USB-C approach will work easily. The ADC pins on the Xmega are all blocked in the current layout and I'm not keen on changing that if I can avoid it - it took quite a while to arrive at the current layout, I'm pretty happy...

Thanks! I'm not sure the circuit could fit into that form factor easily. What is the use case you're thinking of?

No, I think you're right, from what I've heard most chargers (especially cheap ones) don't seem to follow the rules and just deliver +5V until they hit their limits (or Bad Things happen, the Big Clive YouTube videos on those things are hair-raising). I'm more concerned about plugging the board...

Definitely. My only concern with USB is the power negotiation step; I figure this board has a peak draw of ~950mA, including the terminator, which would exceed standard USB's 500mA. When you get into the higher power levels, AFAIK you have to actively negotiate with the supply, which is more...

I'm doing a revision of the hardware to add extra features and correct some bugs. @ronan also made good observations about things to fix, which is appreciated. Here's the list of what I'm working on: Move from KiCad 4 to KiCad 5, and change the footprints to match the awesome new library...

That's mostly how I figured it, assuming a 250mA load: (5-3.3) * 0.25 * 235 to get the 100C rise. The 250mA was just a ballpark figure, based on the max 180mA the ENC28J60 uses while transmitting plus a random amount extra; you'll probably want to run through what the max current consumption is...

I'd suggest swapping the MIC5319 for an alternative 3.3V regulator. SOT-23-5 won't be able to reject all that much heat; if you figure a max draw of ~250mA and a 5V input voltage (worst-case after the diodes), that's a ~100C temperature rise for that package. An alternative might be the MCP1825...

I'm not very knowledgeable about the Mac driver side of the equation. There might be a hack to make the driver skip the gesalt check, but if there is I'm not aware of it. Another avenue might be to try the Focus drivers instead. From what I've read the Focus EtherLAN SC is basically just a...