So take care to get your user share access lined up. Users can always access shares they own and the users you create in Rockstor are the regular linux users. But the Admin user has special Web-UI access setup by default.
Motherboard: Needed to be one that would last a few years, supporting component upgrades, support up to 8 SATA drives, support decent CPUs and memory. I read about about a bunch of boards, narrowing down to Asrock Rack and Supermicro. At the time I was buying, COVID was restricting supply in Australia, so I looked at several Supermicro X11 boards before finding the mATX X11SCL-LN4F. It supports the Xeon E-2100 & 2200, 8th/9th gen Core processors, up to 128GB of UDIMM ECC memory, 6 x SATA 3 (more can be added with mini SAS connections), a huge number of LAN ports, VGA, etc.
Drives: for the system, I had a 120GB M.2 with PCIe 3.0 x4 interface, which the X11 requires. For the drive pool, I got 3 x Seagate ironWolf 4TB NAS drives. These accounted for about half the total cost.
For the software, I followed the Rockstor 4 Installer recipe in the forum, which is very clear and straight forward. That produced an installer that I used first to install in VirtualBox, and then unchanged into my NAS. There are absolutely no issues, apart from a minor password glitch I created. There is also an issue to sort out in the NUT-UPS, as mine was filling the CLI every second or or so with technical messages and a statement that UPSlocalhost was unavailable. I now have the NAS running, absolutely silent, with a raid 5 pool and 2 shares as I previously posted.
For the NUT issue you can sensibly search NUT (Network Ups Tools) related web entries for your issue as we make pretty generic use of NUT under-the-hood. We simply pop a Web-UI on it. Though we may well have a bug there so keep that in mind. But whay you are seeing may have a generic fix which can either guide your configuration used via our Web-UI element or guide an improvement we need to make to acommodate. But in the interim, you might also want to post your configuration page.
Hope that helps and let us know how you get on with that NUT issue. And make sure to post your actual config used as that may help others help you with your particular config. And I seem to remember someone suggested you might need a udev rule for that model. See @thedrjones post in response to an earlier build thread of yours:
Might be a good place to start at least. Just keep a note of all you change so you can backtrack if need be, and check that the systemd services referenced there are named as per the openSUSE variants also.
Unzip the archive and copy the usbdrv subfolder to your project folder (the whole folder, not just contents). Go to the subfolder and make a copy of usbconfig-prototype.h with the name usbconfig.h. Locate the #define lines for IO port and port bits and clock rate, and update them as necessary to reflect our configuration where D+ is in PD2 and D- in PD3 and clock rate is 12 MHz:
Another thing you may wonder is why the disconnect/delay/connect -procedure is needed at all. This is because the host PC can remember the identifier assigned to a USB device even if our device resets and forgets that identifier. By enforcing re-enumeration we make sure that both the host PC and our device have the same ID used to communicate over the USB bus.
Now immediately after you have flashed the ATtiny you should hear the standard Windows fanfare di-dum sound that tells a new USB device has been plugged in. Windows will look for a driver and most likely fail. This is where libusb-win32 comes to the rescue:
I could have a separate tutorial covering my trial-and-error methods of getting the USB device driver to install and work. I hope you have better luck. In case of problems, here are some helpful tips:
Congratulations! We are almost there! Now we only need to prepare the host-side software. For compiling it, I recommend the GNU C compiler gcc from MinGW project and the MSYS tools that you should be able to install along with it, but probably Visual C and others work just fine. MinGW installer is really hard to locate (big thumbs down for the wiki authors on usability), but currently trial and error should eventually get you here.
For those who want to understand the control messages better, I warmly recommend the surprisingly user-friendly USB 2.0 specification. The part on control messages starts on page 248 and the first table concerning this should be Table 9-2. You can find the download link for the spec from part 1 of this tutorial. The specification is rather simple and defined constant values closely reflect the #defines in libusb so you should understand everything rather well just by comparing the spec and my example code.
Now that we got past all the sillyness of helper functions to scan all USB devices and return their specially formatted descriptor messages in order to get one simple device handle, the rest of the code is very straightforward. Only thing making the USB communication different from standard structure of accessing a file are the calls to usb_control_msg(), otherwise the general structure of open / do stuff / close applies:
Note that the second parameter for usb_control_msg now uses USB_TYPE_VENDOR to indicate we are sending a vendor-specific control message. You can also see that the request, value and index parameters (here USB_LED_ON/OFF, 0, 0) can be freely used to communicate with our code on device side.
Wow! That is all. I think this is enough for anyone to grasp in a single reading, so I will be splitting additional V-USB tricks into a fourth part of this tutorial that I will write later. Spending 5 hours in one setting to write this one is enough. :)
Hello,
After i managed to get the rest workin, i have a problem with the host software. When i start the programm compiled with your make and usbtest.c the consol dissapeares directly. But with a bit testing i found out that argc < 2 when i start the Programm, and beacause of the exit(1); it dissapeares. Any idea where i go wrong?
ya que quiero realizar tu proyecto para poder transmitir datos de la pc a la USART del micro y recibirlos de la misma, a y no se programar en lenguaje en C solo se programar en lenguaje ensamblador
espero de antemano que me puedas ayudar, por favor.
Suena como USB_CFG_CLOCK_KHZ no se ha definido en usbconfig.h a uno de los valores admitidos. Usted debe definir F_CPU de velocidad de reloj en Hz o establecer USB_CFG_CLOCK_KHZ a 12000, 15000, 16000 o 20000, dependiendo de su velocidad de reloj.
thanks for the great tutorial.
Im using avr studio 5.1 and atmega16. I do your tutorial but dont work. I dont have error messages. But when i run the INF-wizard my device is not visible who is visible is unknown device.
Can you help me?
Thanks
Sorry, I cannot help you much; only suggestions I have are to double-check connections and that USB lines are connected to the correct pins, and maybe make sure that your ATmega is definitely running at the MHz number you have specified in usbconfig.h (e.g. 12 MHz if you have 12000 kHz in V-USB config).
Stupid me. I first tried without my test board connected to the USB slot. When connected my ATtiny-USB device does indeed show up even though other devices seem not to show up (mouse, webcam, and so on). But for what I want everything works fine. Thanks for the quick reply!
I have gone through your tutorial.it is very much helpful.i have one problem that i could not generate hex file with your makefile i have changed the path in the make file but i cant. i am using avrstudio5
I removed the parts of code you got working, as the code pasted was quite long and I _think_ the Visual Studio details are already in the comments of this part or other parts of the tutorial. Sorry for that! However, I left your modification to fix the 20 MHz clock frequency setting, thanks for that!
Sir..after a lot of struggle i was able to compile the code in AVRstudio 4.
now i get the project.hex to be 16 KB
(source files that i added were-main.c usbdrv.c,odddebug.c and usbdrvasm.c)
Please tell me how to run make so as to get the main.hex file within 2 kB size.please sir.
Have you considered using interrupts for the 100 us delays instead? As you said, interrupts get priority over normal code, and using a timer to generate an interrupt every 100 us would be rather easy.
Figured it out, here is the answers for those that want to know. USB_ENDPOINT_IN and USB_ENDPOINT_OUT refers the data block associated with the control message. IE is the host sending a data block to the device after the control message or is the device sending a data block after the control message.
Excellent detective work! I was just going to answer yesterday that the scheme is quite confusing, but then realized I forgot the actual details from year ago. Your answer sounds like the correct one.
RS-232 has similar hard-to-figure-out terms RX/TX which are dependent on how you look at the communication. Especially for connectors, is the RX the one where device is receiving, or the computer? Confuses me every time. :D
One thing that I find strange though: I can get a device descriptor by just getting a pointer to the usb_device then accessing its property dev->descriptor. But if I want a string descriptor, I have to go through all this palava with usb_control_msg(). Why do they not just implement dev->stringDescriptor or something?
I am only an electronic engineering, which only cover the hardware software, but not computer software at all. Usually computer software is given to those developer. Different gcc compiler require different syntax, it is impossible to remember all the protocol!
* Then the device installed smoothly and got detected as USBAsp (as my programmer is USBAsp). Once you update the driver with your inf file then it will update the device name with the name you have provided in the usbconfig.h
Yeah I had been laughing my day off because of the funstupidinnocent mistakes and the USB not working and realizing it. So you are from Finland? Great! I was living in Wales, Bangor until 20 days ago for more than a year and came back to India after completing my Masters. Too sad this conversation did not happen then, else I would have gladly sent you Strongbow!!(Guess you like it). Otherwise no issues soon I will get my bank accounts settled here and will happily make a donation. You can invest it on an Atmega MCU and make a USB connection based device that will blend Ciders using Atmega and the air surrounding the device! will be a great hit in the market! :-)
7fc3f7cf58