Jump to content

SCSI to Ethernet Adapter on New Hardware


Recommended Posts

On 3/6/2020 at 12:38 PM, aperezbios said:

The PCBs are finally out for delivery today via DHL. I'll keep y'all updated.

Let me guess... delayed by Chinese New Year and Coronavirus? I did a run of PCB's for a conference badge a few weeks ago, and at the last minute I had to do an emergency order from a Korean PCB manufacturer because my order from JLCPCB so delayed. It sounds like a lot of people have been affected by this.

 

Looking forward to seeing how they turn out!

Link to post
Share on other sites
  • Replies 115
  • Created
  • Last Reply

Top Posters In This Topic

2 hours ago, PotatoFi said:

Let me guess... delayed by Chinese New Year and Coronavirus? I did a run of PCB's for a conference badge a few weeks ago, and at the last minute I had to do an emergency order from a Korean PCB manufacturer because my order from JLCPCB so delayed. It sounds like a lot of people have been affected by this.

 

Looking forward to seeing how they turn out!

That’s surprising, since I recently got an order from JLCPCB and they told me they weren’t experiencing any interruptions due to Coronavirus.

Link to post
Share on other sites
  • 1 month later...

@saybur - I'm curious to know what sort of file transfer speeds you're seeing to and from the SD drive over SCSI if you get a moment to test that

Link to post
Share on other sites

I just pushed an update to Github that gets the speed to ~950kB/s on my modern desktop with an AVA-2906 host (originally it was more like ~550kB/s).  Theoretical maximum with the microcontroller's CPU clock is probably something like 1.8MB/s, so there is still quite a bit of room for improvement.

 

Also, I'm also planning on getting mode information into the firmware to allow formatting and the like: Linux is not happy with this device not providing it, though AFAIK it isn't strictly required by the spec.  There are also plenty of other bugfixes that likely need to be applied as well.

Link to post
Share on other sites

I finally got enough additional commands implemented that a patched copy of HD SC 7.3.5 can format the emulated drive, which is so much nicer than having to pull the SD card and have to format it on a separate computer.  I also did some more speed testing on my IIci and got ~1.25MB/s on reads and ~768kB/s on writes.  The same computer also has an older SCSI2SD clone board, which averaged ~1.15MB/s read and ~1.00Mb/s write performance.  Testing was done with 100-600K transfer sizes using SCSI Evaluator 1.07.  I'd take these results with a grain of salt, and I'd be curious if anyone reading can verify similar SCSI2SD performance in a IIci.

 

Future plans include increasing write performance and seeing if any of these tweaks can be applied to the Ethernet controller as well.  I also want to test this on a Plus and see if the thing works with the quirky SCSI implementation that computer has.  I hope to get my Plus recapped in some free time coming up, and I'll see what that testing shows.

Link to post
Share on other sites
  • 5 months later...

I ordered a few of these boards to check out. Do you have any suggestions for a low cost programmer? It looks to me that the Pocket AVR programmer from sparkfun should work. Am I missing anything major?

https://www.sparkfun.com/products/9825

 

Or, it appears I might be able to just use the GPIO pins from a Raspberry Pi too.... https://learn.adafruit.com/program-an-avr-or-arduino-using-raspberry-pi-gpio-pins/overview

 

Any suggestions?

 

I'm looking forward to getting my parts and checking this out!

Link to post
Share on other sites

I personally use and like the Olimex AVR-ISP-MK2, a clone of the real AVRISP mkII.  Mouser and Digikey have it for ~$24 and it is useful across the main 8-bit AVR line: it does ISP for regular AVRs and PDI for Xmegas like on this board (though not UPDI on the new mega0/tiny1 chips).  Most of the tutorials out there are for the standard AVRs using ISP, but I did see a Raspberry Pi program for PDI here:

 

https://github.com/DiUS/xmega-pdi-pi2

 

It looks like it hasn't been updated in a while though.

 

Link to post
Share on other sites

For future readers of this thread.... I wasn't able to get the xmega-pdi-pi2 programmer to work with my ATxmega128a3. It threw an error while trying to program that there was a mismatch at address 212 :-( 

 

I'm giving up on the pi method, and ordered the Olimex AVR-ISP-MK2 :-) I've got too many projects lined up. Spending a day debugging a MCU programmer to save $25 isn't high on my list

Link to post
Share on other sites
6 hours ago, reukiodo said:

Are there any plans to sell a complete kit? or even a complete model? I'd love to pay extra for the ability to just plug into a Classic.

I'll have an extra fully assembled board and ~3 spare PCBs once this is done. Once I get it working, let's talk!

Link to post
Share on other sites

@saybur - Is there any additional setup that I need to do to make scuznet work?

 

I've programmed the firmware with my brand new AVR-ISP-MK2. When I connect it up to my SE/30, the Nuvolink driver detects that it is there (it doesn't complain that the device is missing at startup). The Nuvolink utility also detects that its there and reports the MAC address as expected. 

 

However, whenever I try to do something on the network (Ping using AGNetTools, or open a web page with Netscape), the entire machine freezes.

 

Do I need to have an SD card installed for the network functionality to work? (Currently, the slot is empty)

 

SCSI probe doesn't correctly decode the "Nuvolink" information. Did you see this as well? (I ran into this problem while trying to develop this functionality on RaSCSI. SCSI Probe seems very picky about how the INQUIRY response is formatted.)

 

Here's a picture of my board, in case you notice something blatantly obvious (like I have a chip on backwards or something). Note that I patched in a micro-USB power port instead of using the 5v barrel jack. That's what the giant booger of hot glue is.

J4jcqiESQV84nCiTZML_ZvsuWL__czVZn8uQYB5jvm9iNC4_DUdf6oYw5uI6rfVQpP9z0g_h7S5jNy2tshcJ1gRoNlnTPVGUmVjynY3f-n6ku4nVQd9xfJ8fp_l2MK4QFyc5zdLX8kYsBqanpVrGwv4C_phL8MeV8u1vcQCW3bkVTRRNuH3IbdlisUYAEozJTWetrFCelenW3tInILEokrHSSz2P6u_i965kfypxD5HmYCZsIhxk-DXbsCgbtfqt6g4B5DTzyCtEYYygPkw1WT9bUv1NVu6Il1VbHB-uEkA7EMQHKdfbkz6pxcfJyhqL066dUscMuRpp-f2QpOyPwUtfPP4Q7_nWVBA06oMc2iN7g6lU6y1huM40UcqP_-tJuzZlU0WgzZmULpevXjwEf0Xb2DTWJ1m8RsVJBy2Xr-WKykmfdAMt1R1oNdgRKDxtayN1Gp8ehw_Sl1wSMkeYtbLvTLpJ2JwZ79wDTkIOojnqyFlKu5yx0yNzerlxgh-qvJeIvbmYkE6c1Fer2EIzvp2W7nON-mE5Fkvb20TsGgqDCo8VMUhToupTBLG35rNe0fYot2Q1oG6LZqEYdgSTMt2fH_Vod9Q-_bkF_Pi1oY_PqwfzKyoPd8tDLuclffjlfQOgdUpw_DBJvBirujiwzUD5KgQviKQ5xC3y41NS_DoI9eJGEqLnICaKHHM13Yo=w703-h937-no?authuser=0

 

oADTTB_j1y4_snpywfR6P3v_F1UsNZaEw8GCCckVva9oPm8DBu9phjSTc1KCUtzx-hSHxr1n_if3ja3PR3EU5rStXTkz_NgvwHL9uIzwDKynA9IRSBP0fWlgA__m0ZZ2CWD-KCiE2Ej20zUCXDPWfHPbktkqypz7jnQN_GQCmN1pTLTgVgW1jYJu88_-VgySBn5Fb0O5xjtr0ukgLzBifHpeNmR7lcB1U1xClk1vrivdEcrgI1-Py3EUUzUIH7FGPOCAZ-MOqSX3aCUE7pS98zXRsFVPsEmIbQ0EL0oTtjBKYZzUiY8MRxRbV4SvEEItAX-joPC4LT_z4ZrxorzxXXffJaEKIlReZKoMuawzpb9xY15h6nt_nwSbA-hAaOkeOhSoxKI2mn3As4GThB5Yo_fR0PCREkQsS_oK2o0OCl4LFgjOHkaLY0NMZ8aJ6U3brco4hD38H4-02CLdCKEIWljKWgdmL2Nnm5PiTTBYtKrQGeHxHsD215YRFpASKjAKfAp3twBrBF9RSbGflGnM9MoCxDlfMSVW4OVRe5PJabeVRiVbLOH1f-fcPaw5SxPNMjAPXwoYAbVSEqBQ6XMJT-ST8hghpAxC9UOuz-Y0qjL79RLDmihH8Fo44t5QztSdSul5SbRuPvr3daySDOvWCyo3pBdPQkS6b2v74KTjDmAHkDoaWu_q8_qAW-cnb30=w1250-h937-no?authuser=0

Link to post
Share on other sites

No, it should be working at the point you're at. I don't have the firmware in front of me, but as far as I can recall the weird INQUIRY response is normal. Basic bus transactions must still be fine to get the info from the Nuvolink utility, so I'm guessing it's not anything with your soldering.

 

Are you using the most recent commit in the git repo, and did you compile with debugging enabled? I'll get my board out tonight and see if I can get some additional stuff added that might be helpful in figuring this out.

Link to post
Share on other sites

I built with the default options (just "make all"). It appears debugging is on by default, so I do have debugging on.

 

I did built with the latest version. I forked your repo so that I could make updates to the README with some instruction updates. But my fork is up to date with your repo.

 

Is the "TX" debug port just a RS-232 type signal? What baud rate did you use? I can hook up a TTL receiver and try to capture some info, if that helps.

Link to post
Share on other sites

It should be 500kbaud, but it's mostly just symbols at certain code points. I should really get a proper debugger some time...

 

Thinking about this more, I wonder if it might be a power problem: the Ethernet controller draws extra juice to transmit, and it might be enough to cause the MCU to do a brown-out reset if the USB power source isn't up to the task. I was thinking of adding an LED pattern on reset so you could see it, but if you tie into the debug line you should be able to observe a reset that way too.

Link to post
Share on other sites

I pushed an update to Github to help narrow down if this is a power problem. The Xmegas have a nice register that shows what the cause of the last reset was; I added a handler so if a reset was triggered by a brown-out the device will halt and go into a LED blink loop (1/2 sec on, 1/2 sec off). I figure a brown-out is a Bad Thing no matter what causes it, since it probably indicates the PSU is bad.

 

If you could, try the most up to date firmware and let me know what you see. If you don't get the looping blink, could you let me know what state the LED is in when the system freezes?

Link to post
Share on other sites

Thanks for the update @saybur, I just tried a 300w, 5v power supply with the same result. I'm questioning whether its really a brown out. But, I'll still give the new firmware a try in the morning.

 

What do you use to monitor the console output? I'm using TeraTerm, but it looks like some of the characters that the software is sending are not printable ASCII characters. If you could double-check and share your serial port settings, I'd also appreciate it. The only time I see any output is on 9600baud. They're garbage characters, but I think that's expected.

 

image.png.d4c05ab6fb9dc20a78c4b1433049f3e4.png

 

What is the non-power LED normally supposed to be showing? Its off most of the time, but I'll see if flicker ever now and then. Activity maybe?

 

Thank you for your help! I really appreciate it!

 

 

Link to post
Share on other sites

Yeah, I agree that makes power issues seem way less likely. For the UART, 500kbaud is correct, but the device uses binary, not ASCII.  Try that and see if data appears; debug.h has the symbol meanings.

 

The LED will light during startup very briefly and again during bus transactions. Non-data transfers are fast enough it usually will just flicker briefly.

Link to post
Share on other sites

I've added a "testing" subdirectory to the Github repo that can be used to build a special firmware for doing post-assembly verification of a PCB. It's not comprehensive at all right now, but my goal is to expand it to cover as many of the connections into the microcontroller as possible. Boards like this have so many small parts that they are really annoying to debug if the hand-soldering is not perfect; I remember assembling some SCSI2SD clones a few years ago, and how much I appreciated having the scsi2sd-util helping me out when I had dry joints on some pads.

 

@landoGriffin, I have a feeling this won't cover what you're experiencing yet, but I hope to get the control lines added to the board test firmware here over the next couple days.

Link to post
Share on other sites
4 minutes ago, saybur said:

 

@landoGriffin, I have a feeling this won't cover what you're experiencing yet, but I hope to get the control lines added to the board test firmware here over the next couple days.

Thank you for your help, @saybur! I did notice I had some of the resistors installed sideways, but fixing those didn't seem to help. More troubleshooting tomorrow night!

Link to post
Share on other sites

All right, the most recent commits on Github have a much more comprehensive test suite ready to go. It requires building a simple loopback adapter for the DB25 connection, with instructions in the repo. At the moment, this will check all of the SCSI lines and the connection to the Ethernet controller, but not the memory card. Hopefully this will highlight whats going on if its a problem with the hardware.

Link to post
Share on other sites
39 minutes ago, saybur said:

All right, the most recent commits on Github have a much more comprehensive test suite ready to go. It requires building a simple loopback adapter for the DB25 connection, with instructions in the repo. At the moment, this will check all of the SCSI lines and the connection to the Ethernet controller, but not the memory card. Hopefully this will highlight whats going on if its a problem with the hardware.

Very cool!! Thank you so much!

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...