EEVblog Electronics Community Forum
Electronics => Beginners => Topic started by: paulca on December 07, 2017, 10:05:58 pm
-
Got my first Arduino this evening. A £3 Nano "compatible". Soldering the headers was easy, took all of 5 minutes. Stuck it in a breadboard, powered it and it blinked at me. Out of the box it worked. £3. Where's the fun in that?
Linux ... software installed and ran fine. /dev/ttyACM* ... nothing. Messed about recompiled my kernel a few times and after half an hour I rebooted to windows.
Windows 7... software took ages to download, I eventually caught Steam using all the Internet for whatever it wanted to do, large object over the head of Steam and... The software installed and ran. COM errors. Apparently the software chooses COM1 first even though it's a dummy. COM3 worked.
Uploaded a modification of the blink program to morse code "SOS" and it worked.
Played about with reseting it, running it off breadboard or USB. Resilient little thing. Went to reprogramme it and "device error". Windows would longer recognize it was plugged in, no matter how many times I plugged or unplugged it.
Rebooted. Thing works fine on COM3 again. (I hate windows)
The worry for me right now is... given it's ADC and DAC capabilities.... I can do so much more in software without having to deal with the complicated analogue electronics stuff, so I will run away from the later scared and do everything with an Arduino or a PI and not bother learning analogue electronics.
I gather that would be the appeal of the arduino. Considerably lower level than the PI but as easy to get up and running. PI and Python, high level, big OS, big power, LOTs of processing and LOTs of memory £30. Arduinno, very little memory (Java (or pythong) programmers need not apply), very little power, no OS, but even more capable when it comes to things like ADC, DAC and almost as capable when it comes to interfacing with external sensors and gizmos £3 (or £15 for a branded 'original').
Arduino + Gizmo + Google = instant gratification.
But hey ,it gets people more interested in STEM, electronics, science, technology and engineering, it works for me.
As a software guy I love it. Now I can get values out of circuits and back into circuits from software. The horizon has widened.
Still have to get it working in Linux, but... My linux is a custom job, based on Gentoo, the fact it didn't have ACM drivers didn't help, so I'm maybe missing support for something else, like external/usb TTYs or something that I've never needed before, that normally are there in Ubuntu et. al. and I have never enabled.
-
By the way..
Newbie to newbie
BLUTAK!
Thanks to Julian Ilett on youtube [1], but a lump of blutak makes things so much easier to solder. For Americans it's like sticky clay used to put up posters on walls, but as a clay like thing you can poke headers into a lump of it, position the board on top, squeeze and mold the lump to get the shape you want and... only need to hold the solder and soldering iron.
[1] https://www.youtube.com/channel/UCmHvGf00GDuPYG9DZqQKd9A (https://www.youtube.com/channel/UCmHvGf00GDuPYG9DZqQKd9A)
-
Just a tip, if you have trouble getting a nano compatible board to connect, look on the underside of the PCB and have a look at the USB chip. Many of them use a Win Chip Head IC, and I found it much more reliable to download the drivers directly from their website (in chinese if I remember, but I still found the drivers). The logo on the IC is WCH, but also looks like HDM upside down. In a few cases, windows couldn't automatically find a driver.
-
.... have a look at the USB chip.
My first experience with Arduino:
Got two real UNOs and carefully followed directions and they would not work. Got on a forum and tried everything that I was told to do for 3 days. There was another guy who just got one and it also did not work. After 3 days the mystery was solved. He and I got new developed boards from arduino.cc vs arduino.org and the new board had a different USB chip than the original and it required new drivers that were not available. After 3 days new software was uploaded. It took me year(s) to try Arduino again because I was so pissed that a real product had the wrong software. Last week I got a clone (will not buy from Arduino anymore) Mega 2560 and it worked out of the box so I am starting to try C++ again. It comes up on Com 6 (I do not know what 1-5 are).
Now .cc and .org have decided to work together.
-
Most nano v3 clones use the CH340 for USB. Older versions of Linux didn't have the driver. Recent Ubunus have it it though. Win 10 and Win 7 on my machines connect to it no problem.
-
Hi paulca, glad to hear that everything went well.
As a software guy I love it. Now I can get values out of circuits and back into circuits from software. The horizon has widened.
It's good, no bloatware and the hardware is really inexpensive.
My first Arduino experience was more frustration than anything else, I found that the code generated by the IDE was really slow, I think I was expecting far too much from it. To speed things up a bit I went for Pinguino and bare metal programming with MPLAB. But that's not the same as Arduino.
-
Hi paulca, glad to hear that everything went well. As a software guy I love it. Now I can get values out of circuits and back into circuits from software. The horizon has widened.
It's good, no bloatware and the hardware is really inexpensive.
My first Arduino experience was more frustration than anything else, I found that the code generated by the IDE was really slow, I think I was expecting far too much from it. To speed things up a bit I went for Pinguino and bare metal programming with MPLAB. But that's not the same as Arduino.
The arduino library routines (digitalRead/digitalWrite) for port i/o are SLOW because of idiot checks and pin lookups, but they work for most projects because real performance is not required, especially during the learning phase. Those that really need speed can get large improvements by reading/writing the ports themselves. Of course, you need to have a few programming skills AND have an understanding of how the port registers work.
-
Hi paulca, glad to hear that everything went well. As a software guy I love it. Now I can get values out of circuits and back into circuits from software. The horizon has widened.
It's good, no bloatware and the hardware is really inexpensive.
My first Arduino experience was more frustration than anything else, I found that the code generated by the IDE was really slow, I think I was expecting far too much from it. To speed things up a bit I went for Pinguino and bare metal programming with MPLAB. But that's not the same as Arduino.
The arduino library routines (digitalRead/digitalWrite) for port i/o are SLOW because of idiot checks and pin lookups, but they work for most projects because real performance is not required, especially during the learning phase. Those that really need speed can get large improvements by reading/writing the ports themselves. Of course, you need to have a few programming skills AND have an understanding of how the port registers work.
And, you can still use the Arduino IDE/bootloader/libraries (like for displays, etc).
-
I think the original poster with have more luck using /dev/ttyUSB0.
/dev/ACM* is an Linux-on-ARM thing.
Just do 'dmesg' after plugging in to see what device it has detected.
-
I think the original poster with have more luck using /dev/ttyUSB0.
/dev/ACM* is an Linux-on-ARM thing.
Just do 'dmesg' after plugging in to see what device it has detected.
Yea. All I get is:
[ 763.597289] usb 3-2: new full-speed USB device number 2 using xhci_hcd
Nothing more. No device recognition, no driver loading, nothing. The only ttys I have are /dev/ttyNN or /dev/ttyAA 325 of them. 0-99, aa-zf
Although, I do get this in "lsusb":
Bus 003 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
So lsusb can enumerate it. This gives me a lead at least. I'll have a play later to see if I can find a driver for HL-340 or whatever that is.
The Linux tutorials are interesting because they jump straight past the Arduino software into building cross-compile tool chains (GCC et. al) and (I assume) writing to the device yourself without the Arduino software. I'll maybe pick that up later.
EDIT:
Ran
cd /usr/src/linux
make menuconfig
Searched with "/" for ch341 and found it straight away.
USB Winchiphead CH341 Single Port Serial Driver
Enabled it as a module.
make modules modules_install
modprobe ch341
Bingo:
[ 1552.197357] usb 3-2: new full-speed USB device number 8 using xhci_hcd
[ 1552.363153] ch341 3-2:1.0: ch341-uart converter detected
[ 1552.391232] usb 3-2: ch341-uart converter now attached to ttyUSB0
-
I hate the headers. I don't know what they plate some of them with, but some of them don't flow solder very well even with flux. Most of the dupont wires are crap. I just solder directly to the board for reliability and use the nano as a breadboard. For 40 years I twideled pots and subbed resistors. It's nice just to enter a number.
-
Rant warning!!!
http://www.ladyada.net/learn/arduino/lesson4.html (http://www.ladyada.net/learn/arduino/lesson4.html)
I haven't even got to the good bit, but this tutorial has already made so many school boy errors it's irritating.
1. It complains that hard disks use SI multiples for Kilo, Mega bytes. It's ironic that the tutorial is about serial communications and it fails multiple times to realise that "hard disks don't care what your data is" because the data is treated as serial bits. They only use "octets" to make things convenient. "Bytes" are ONLY used in computers/micros because of bus width and data word lengths. They can be 4 bits, 8, 16, 24, 32, 64, 128 bits wide. Hard disks don't care. It's not a marketing tactic it's a well established standard. ALL data storage and data transfer specs are in SI units of bits or SI units of octets. if they aren't and are written in powers of 2, "x 1024" they are wrong.
2. println("Hello World!") ... without looking at the source code for this library function I can tell you it is NOT going to send 12 bytes. It will be 13 or more likely 14 bytes.
Hello World!\n\0
They forgot the new line and the null terminator. This is important because if you were to allocate a bit of memory for that string and assume it's 12 characters when you insert your Hello World\n\0 into it, it will over run by 2 bytes. Your program will probably run fine, but might well blow up at some later time when something is using those 2 bytes for something else.
This is fundamental for C or assembly that you understand this or your code will randomly crash.
/rant.
-
Bingo:
[ 1552.197357] usb 3-2: new full-speed USB device number 8 using xhci_hcd
[ 1552.363153] ch341 3-2:1.0: ch341-uart converter detected
[ 1552.391232] usb 3-2: ch341-uart converter now attached to ttyUSB0
By the way. Which version of linux kernel is installed? Because in pre 4.10 versions CH341 was only partially supported (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/ch341.c?h=v4.9.67#n369) (unless distro maintainers backported driver or added their own patches). As a result (I got it with Chinese RS232 dongle) adapter was simply non-working: system see CH341 but it was impossible to get any sane data from device due to data/parity/stop bits configuration mismatch.
-
Bingo:
[ 1552.197357] usb 3-2: new full-speed USB device number 8 using xhci_hcd
[ 1552.363153] ch341 3-2:1.0: ch341-uart converter detected
[ 1552.391232] usb 3-2: ch341-uart converter now attached to ttyUSB0
By the way. Which version of linux kernel is installed? Because in pre 4.10 versions CH341 was only partially supported (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/ch341.c?h=v4.9.67#n369) (unless distro maintainers backported driver or added their own patches). As a result (I got it with Chinese RS232 dongle) adapter was simply non-working: system see CH341 but it was impossible to get any sane data from device due to data/parity/stop bits configuration mismatch.
I believe it's 4.4.2-gentoo but I can easily upgrade it in a few minutes. The advantages of running a source based distro is that kernel upgrades are (usually) very easy.
zcat /proc/config.gz > .config
make menuconfig
EXIT and save
make -j 9 all modules modules_install install
(Check boot loader and symlinks)
reboot.
Pray.
-
It seem it fully supports the rs232 serial, but not the i2c.
The arduino uses the rs232 serial doesn't it? So I would only run into problems if I try and use I2C over USB?
-
The AVR in the Arduino does indeed use the UART (not really RS232 as its TTL levels) using one of the handshake lines on the CH341 to reset it. I'm unsure how one would go about using the two-wire interface on the CH341.
Its a surprisingly quick and convenient way to prototype which is why after years of avoiding it (in favour of my own atmega328 board..) I know use it for prototyping for almost all small projects.
-
It seem it fully supports the rs232 serial, but not the i2c.
The arduino uses the rs232 serial doesn't it? So I would only run into problems if I try and use I2C over USB?
If you're talking software, then basically yes, adequate support.
If you're talking hardware, then no. RS-232 is NOT the same thing as TTL UART at all, although some people incorrectly call it that. The most critical difference is voltage levels. TTL signals are between 0 and VCC. RS-232 signals may range from -15 and +15V, and the specs say up to +/- 25V must be tolerated.
I2C is a different animal. Arduino has hardware support for it on specific pins, but it's not enabled out of the box with any default bootloader I know of. You have to implement i2c yourself (there are libraries) if you want to use it.
-
I2C is a different animal. Arduino has hardware support for it on specific pins, but it's not enabled out of the box with any default bootloader I know of. You have to implement i2c yourself (there are libraries) if you want to use it.
What about SPI?
One of my go-to reasons for the ardie was I2C and SPI "maker modules" to play with.
But as you say, I can do I2C in software with libraries.
-
I2C is a different animal. Arduino has hardware support for it on specific pins, but it's not enabled out of the box with any default bootloader I know of. You have to implement i2c yourself (there are libraries) if you want to use it.
What about SPI?
One of my go-to reasons for the ardie was I2C and SPI "maker modules" to play with.
But as you say, I can do I2C in software with libraries.
I'm not entirely sure what you're after. Generally the Arduino nano and uno both use the atmega328, either at 3.3V or 5V, with clock options of 8MHz or 16MHz. The atmega328 has a two-wire port, as well as an SPI port, the former fully supports I2C, so rather than try to modify a board and use the CH340 for I2C... why not just use the micro as a serial-I2C bridge? I believe that's what most people do, and I'm guessing that's what you're doing.
You can also do 'I2C in software' but I don't see why when the AVR has hardware support for it (still requires a library, or some software fiddling to get it working).
-
I'm not sure I understand the "I2C not enabled" comment. You need to have code to use I2C but it only requires the usual initialization needed for the AVR 328. Same for SPI. The arduino "system" doesn't require anything different from the underlying AVR micro. The arduino is just basically just an AVR breakout board. That's why I like the nano - minimal 'duino to get in the way. Plus, it's breadboard friendly. I buy them 5 at a time from China, $2 a piece or less, and use them for all sorts of simple projects.
By the way, UART isn't the protocol, it's the hardware implementation - https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter. Asynchronous Serial, or more commonly Async, is the name for the protocol.
-
What they said about I2C. I responded to your "i2c over usb" comment, which made it sound like you wanted bootloader support for I2C. The bootloader is the (often pre-installed) program that allows you to load your program via serial pins (or attached usb connector).
Yes, there is full hardware support for both SPI and I2C on specific pins. You can also do it via software on other pins. Either way, you have to write code or use libraries to make use of it.
-
Well ... this didn't take long.
https://www.youtube.com/watch?v=5_tC7tWy1JQ (https://www.youtube.com/watch?v=5_tC7tWy1JQ)
Unfortunately I forgot to unplug the USB power, with that out it reads circa 20mA.
Mickey mouse, but it's my first ever I2C read, my first graphical OLED.
Of course, most of the credit goes to Adafruit and whoever wrote the SSD1306 library.
Still cool for a Friday evening tinker.
-
Got my first Arduino this evening. A £3 Nano "compatible".
[...]
The worry for me right now is... given it's ADC and DAC capabilities....
FYI, there is no DAC in a Nano, or any other '328 based board. What it calls "analogOut" is really PWM.
-
By the way..
BLUTAK!
Or if you want them perfectly straight, plug the headers into the breadboard, set Arduino on top, solder. ;)
Chris
-
Umm... Your complaints about the tutorial are ... seriously tiny nits, for that level of tutorial.
Quoteprintln("Hello World!") ... without looking at the source code for this library function I can tell you it is NOT going to send 12 bytes. It will be 13 or more likely 14 bytes.
>Hello World!\n\0
They forgot the new line and the null terminator.
The string stored in memory has a null terminator. The string transmitted will have the newline (and perhaps \r\n) because println adds that, but does NOT include the null terminator. Because it's the terminator... Do you want to try to guess how much space the line takes as it sits somewhere in the serial monitor code on the host? Me neither! (also, it never says the string is 12 bytes, it just uses 12 bytes in the "problems."
Quote This is important because if you were to allocate a bit of memory for that string and assume it's 12 characters when you insert your Hello World\n\0 into it, it will over run by 2 bytes.
But "allocating a bit of memory" for the string would be essentially a different exercise than printing it.
QuoteIt's not a marketing tactic it's a well established standard. ALL data storage and data transfer specs are in SI units of bits or SI units of octets. if they aren't and are written in powers of 2, "x 1024" they are wrong.
Yeah, memory chips, and the amount of flash and RAM inside the Arduino (all specified in KB, as multipliers of 1024) are technically wrong. And hard disks might be interesting because 1 bit on the platter may not equal 1 bit of storage, and one byte on the serial port is actually 10 bits transmitted, and ... all sorts of stuff that really isn't appropriate for a beginner's tutorial.
See also https://www.cnet.com/news/gigabytes-vs-gibibytes-class-action-suit-nears-end/ (https://www.cnet.com/news/gigabytes-vs-gibibytes-class-action-suit-nears-end/)
Well ... this didn't take long.
... t's my first ever I2C read, my first graphical OLED
And that's the beauty of it all, isn't it? Perhaps you feel a bit guilty about not having to have written your own functions to manipulate the I2C interface, because those Arduino libraries are bloated an inefficient? Or perhaps not!
-
By the way. Which version of linux kernel is installed? Because in pre 4.10 versions CH341 was only partially supported (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/ch341.c?h=v4.9.67#n369)
It seem it fully supports the rs232 serial, but not the i2c.
Whether the Linux driver for the CH341 supports I2C or SPI is irrelevant, because the com link between it and the AVR chip on the arduino only supports Async Serial anyway. The AVR chip supporys I2C and SPI (on other pins, not involving the CH341)
-
Umm... Your complaints about the tutorial are ... seriously tiny nits, for that level of tutorial.
And that's the beauty of it all, isn't it? Perhaps you feel a bit guilty about not having to have written your own functions to manipulate the I2C interface, because those Arduino libraries are bloated an inefficient? Or perhaps not!
Yes, they were nit picks. I was in a bad mood.
The null terminator may or may not be sent. I suppose in this case it might not be. \n is usual for Unix and most other things, \r\n is a DOS thing, there are many debates on why they decided to do that. It is the command sequence a lot of printers back then used. Similar to why they decided that filenames where in 8.3 format... or why they went to the trouble of making it case insensitive.
I should have been specific about the storage; memory in a computer, RAM or ROM, would usually be specified in powers of 2, 1024 multiplies as it matters to computers. Flash memory cards that emulate disks are usually/should be multiplies of 1000. Network, such as 100 megabit Ethernet is 100,000,0000 bits.
The hard disk storage example was of course grossly wrong, as you hint to. Anyone who has formatted a 1Tb drive and looked at home much they get in Megabytes is often disappointed but not only do you lose the 1000 to 1024, but you loose a load in formatting over head, then you have the minimum data allocation of a sector. A 1 byte file might consume 512 bytes (or 1024) (+inodes and/or allocation table space). You run into this when trying to make a Linux boot floppy with 1.4Mb, but the /dev/ folder inodes make some space inaccessible. You have to tune the filesystem to increase the number of inodes. (It's actually better to have the minimum /dev nodes on the disk, create a ram disk and populate /dev there.)
Memory allocation is similar in that regard but even more complex in the case of an OS like Linux. You can write a C program on a 64 bit Linux machine to allocate 64Gb of RAM when you only have 1Gb and it will return successfully. It would only be when you try and write to all the the memory allocation blocks that you would run into problems. All to do with the MMU relationship between virtual and physical addresses. Also side stepping compiler optimisations allocating 10 locations for 1 byte each can result in 5,120 bytes of ram being allocated. Then there is of course memory address alignments, packing, unpacking etc.
Fair enough, way beyond a tutorial of that level.
I do feel guilty using the Ada Fruit libraries, though I'm not sure "guilty" is the right word, disappointed maybe. My day job is currently a Java programmer and one of my pet hates of Java is just how insanely inefficient most of the code written for it is. HUGE elaborate multi megabyte frameworks doing simple things in complicated abstract and generic ways and then the author only uses a tiny part of it they could have written themselves 100 times more performant and 1000 times smaller. They import dozens and dozens for jars. We have applications (not saying where I work) which pre-allocate 16Gb of heap on start up, 4Gb is becoming fairly standard these days in enterprise software.
So I find looking into embedded C/C++ again refreshing.
-
The null terminator may or may not be sent. I suppose in this case it might not be. \n is usual for Unix and most other things, \r\n is a DOS thing, there are many debates on why they decided to do that. It is the command sequence a lot of printers back then used. Similar to why they decided that filenames where in 8.3 format... or why they went to the trouble of making it case insensitive.
The null terminator certainly should not be sent! That's string metadata, not part of the string data. Other storage formats for strings might have, for example, a length count prepended to the string data instead. You would never think of sending that from a "print" (as opposed to storing it on disk, or sending to another program)
MSDOS followed CP/M in many things, which in turned followed DEC operating systems. DEC used 8.3 file names in RSTS/E (and others) on the PDP11 and in VMS. DEC used CRLF to terminate lines in a text file (when they didn't use a prepended record length, which they did often as well).
CRLF is a mistake, really. Two bytes where one will do. Sometimes you might want to return to the start of the same line to overprint. You would probably never want to drop down one line and print the next character below and to the right of the previous character (or if you wanted that, you'd want a lot of other things as well, using arbitrary XY positioning). So CR for simple start of line for overprinting and LF for start of next line is the most sensible. Even in the 70s you could perfectly easily tell the printer driver to expand an LF to CRLF.
I should have been specific about the storage; memory in a computer, RAM or ROM, would usually be specified in powers of 2, 1024 multiplies as it matters to computers. Flash memory cards that emulate disks are usually/should be multiplies of 1000.
Flash memory might be used in place of disks, but it's built using a semiconductor grid with binary address lines. So its size is naturally a power of two -- or at least each block is.
It's interesting to note that Samsung, for example, offers SSDs in both power of ten and power of two sizes!
Samsung 960 Evo 500GB M.2 (2280),NVMe SSD R/W(Max) 3,200MB/s/1800MB/s ,330K/330K IOPS
SSD Capacity: 480 GB
Samsung 960 Pro 512GB M.2 (2280),NVMe SSD R/W(Max) 3,500MB/s/2100MB/s ,330K/330K IOPS
SSD Capacity: 512 GB
The Pro has the same binary capacity as it's binary power model number, while the Evo has less binary capacity than its model number.
But ... 500,000,000,000 bytes is only 465.66 GB, not 480. So something else is going on there.
-
But ... 500,000,000,000 bytes is only 465.66 GB, not 480. So something else is going on there.
The units are probably miss leading.
Wikipedia suggests that the ^2 should take the name gibibyte instead, but I don't think I've every heard that being used.
Although I have seen their acronyms "GiB", "KiB" and "MiB" used in textbooks etc. a few times, but I think the units are so polluted in popular marketing and press it's probably only going to be correct in textbooks and datasheets.
The other ones that get people are megabit and megabyte per second, I've seen 1.5Mbps, 1.5MBps and 1.5MiB/s and all manor of variations. Often Mb is used for bits and MB is used for bytes, but not always.
I "believe" it might be correct to say a broadband connection with 10Mbps link speed should be capable of approximately 1MiB/s. (using an old IP networking rule of thumb that on average 8bits will on average consume 2bits for the headers). Of course it's approximate as a lot of small packets wastes more header bandwidth compared to a few large packets.
It's as clear as mud. Best not assume if it's really important to what you are doing.
-
So today I managed to get my DC load working again. I also managed to get the arduino to send the control voltage from a linux terminal.
For reference, I used:
tty -F /dev/ttyUSB0 cs8 9600 ignbrk -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke noflsh -ixon -crtscts
To configure the TTY.
echo -en '\xff' > /dev/ttyUSB0
echo -en '\0f' > /dev/ttyUSB0
To send the binary values (written in hex).
Note: "Echo"ing to the port seems to open the serial coms, send the byte and close it again. This rapid open/close apparently resets the arduino.
Trying to set -hupcl on the terminal with tty to not close the serial connection did not work and did not prevent the Arduino reseting. So I pulled the reset pin high on the breadboard to prevent it from resetting.
Obviously this might be better done in code than a bash terminal. Anyway, baby steps.
Next I have to figure out how to read the difference between 3 voltage ranges.
3V - 4.2V
6V - 8.4V
9V - 12.6V
So if I had:
Input: 3.6V, 7.2V, 10V
I want...
Output: 3.6V, 3.6V, 2.8V
I can put a meter across different points in the series circuit (A LiPo) and read these voltages, but I need to alter them to have a common ground for use with Arduino analogue in ports.
Unfortunately this will mean a hard day working out differential subtracting op amps. So I'm not going to have able to avoid analogue electronics for long.
I could, potentially put all three through "by 3" dividers and do the subtraction in software. Then I lose resolution in the lower voltage.
Or though 1:1, 1:2, 1:3 dividers to normalize them to 0-4.2V but have less resolution in the upper voltage then.
Not to mention the error factor in voltage dividers which would need calibration pots. I don't know how accurate I can get differential amps though.
-
I should have been specific about the storage; memory in a computer, RAM or ROM, would usually be specified in powers of 2, 1024 multiplies as it matters to computers. Flash memory cards that emulate disks are usually/should be multiplies of 1000.
Flash memory might be used in place of disks, but it's built using a semiconductor grid with binary address lines. So its size is naturally a power of two -- or at least each block is.
It's interesting to note that Samsung, for example, offers SSDs in both power of ten and power of two sizes!
Samsung 960 Evo 500GB M.2 (2280),NVMe SSD R/W(Max) 3,200MB/s/1800MB/s ,330K/330K IOPS
SSD Capacity: 480 GB
Samsung 960 Pro 512GB M.2 (2280),NVMe SSD R/W(Max) 3,500MB/s/2100MB/s ,330K/330K IOPS
SSD Capacity: 512 GB
The Pro has the same binary capacity as it's binary power model number, while the Evo has less binary capacity than its model number.
But ... 500,000,000,000 bytes is only 465.66 GB, not 480. So something else is going on there.
Some space is hidden from user to extend the life of the SSD.
Flash memory is arranged in chunks (sectors) of 512 bytes or some small value like that, and then multiple sectors are grouped into pages, let's say 128 - 512 KB in size.
With Flash memory, you can write sectors , but you can't overwrite them. In order to write over a sector, you have to erase it but you can't... you can only erase a whole page of 128-512 KB and the flash memory can only be erased a limited number of times.
For SLC NAND, each page can be erased maybe 10k times, for MLC you're down to 2k-4k depending on manufacturing (lower the nm process, the lower the erase cycles) and for TLC you can be down to 500-1000 erase cycles.
So the SSD controller tries to delay erasing pages as much as possible, whenever a 512b - 1kb sector needs to be overwritten it just writes the data into some other sector in another page and marks that sector as "can be erased". At some later time, when the SSD controller has no very few empty sectors to write data to, or during idle time, it scans the pages and finds pages with a huge number of "can be erased" sectors, it copies the other sectors with data to other pages and then erases the whole page wasting one of those erase cycles, and making the sectors in that page available to be written to.
So in order to reduce the erase cycles, the SSD controller uses some of those GB of flash hidden to shuffle sectors in those pages instead of being forced to erase pages to make sectors writable. It makes it possible to delay erasing pages as much as possible. For example, you are sold a 240 GB SSD (with powers of 1000) which has 256 GiB of actual memory (powers of 1024) so there's 256 x 1024x1024x1024 / 240 x 1000 x 1000 x 1000 = 34,877,906,944 = ~ 33 GB used to extend the life of the SSD.
Also some ssd controllers and some nand chips can configure a part of their memory in a pseudo-slc mode for example Sandisk has some SSD drives where a 240-256 GB SSD with MLC memory has around 10 GB of "SLC memory" ... basically from each of the 8-16 x 32-64 GB MLC chips, a portion of around 2-4 GB MLC where each cell stores 2 bits, is configured to store only 1 bit per cell, making around 0.75-1GB of pseudo-SLC memory. These portions will have higher endurance, let's say from 2-4000 erase cycles to around 6-8000 erase cycles
So if the SSD applies this technique, a 240 GB SSD will have 256 GB of MLC inside but not necessarily 30ish of GB as spare, maybe only 16-20 the rest being reconfigured as SLC memory and used usually as write buffers to achieve higher throughput when writing to it (the controller prefers writing to the slc portion and then when idle moves sectors from that portion to other regular areas)