|
A memory pcb piece that comes mounted in a mother board memory slot has only about 100 pins. 4 Kilobyte of memory is a thousand ints on a 32 bit machine. How do you read or write a thousand ints through a bottleneck of 100 pins? Thank you
modified 21-Oct-23 10:20am.
|
|
|
|
|
One by one. Or, I believe, two by two for the current DDR generations (64 bits data bus).
Actually, current DDR memory generations have up to 288 pins. The CPU presents an address on one set of pins (on some memory types in two pieces, first the high order bits, then the low order bits), fires a 'read' signal, and the selected data bits come flowing out on the data pins. Or the CPU both presents the address and the data and fires a 'write' signal that reads what data the CPU presented into the addressed location.
|
|
|
|
|
Why is that so hard to understand? Think of it in terms of reading/writing one word at a time. In your case, 32-bits. That easily fits in a hundred pins, though I don't remember any memory modules with that pin count.
There were 72-pin SIMMs that handled 32-bit transfers, and that jumped to 168-pin DIMMs with a 64-bit transfer.
Besides power, ground, and control pins, you only need 1 pin per data bit and 1 pin per address line, so it's really not hard to understand.
Anandtech RAM Guide[^]
|
|
|
|
|
Thank you I understand. On visual inspection the pcb itself appears pretty simple, my guess is that simplicity is deceiving.
|
|
|
|
|
A cpu has a lot of pins. What are they meant for? Do they have a general purpose usage or does the processor have specialized groups of pins where each group talks to certain type of resource on the motherboard (video adapter, sound board, etc)
|
|
|
|
|
Go to the chip manufacturer's web site and get the datasheet.
|
|
|
|
|
|
A lot of those pins are power and ground. In simple terms, pins go to memory and buses, but not to individual boards, like video and sound. Those peripherals are connected to an expansion bus, like PCI-E, and the chip talks to devices through the bus.
|
|
|
|
|
>but not to individual boards
I know it’s not dive in the cpu socket pop up in the sound or video card slot type of circuit, there is some mediation in between the two.
Thanks for your answer.
modified 7-Oct-23 12:29pm.
|
|
|
|
|
The driver problem. When an program is run it’s machincode doesn have the data required to run the sound card or the Mother Board or another piece of hardware because all computers contain hardware that is different, it comes from different vendors.
Companies provide drivers for their equipment. Is a driver the place from where an Apps program machine code gets at run time the resource addresses required to get the sound board, MB etc working, is it some kind of compile at runtime?
modified 7-Oct-23 14:17pm.
|
|
|
|
|
|
|
Calin Negru wrote: Do they have a general purpose usage or does the processor have specialized groups of pins where each group talks to certain type of resource
It varies a lot from chip to chip, or - for PC type chips - from socket to socket.
Chips meant for embedded use, IoT-style, may have general I/O-pins that can be configured by software to behave according to this or that signal standard, among maybe 2-4 different ones (but not too different from each other). This rarely if ever means that the CPU switches among different I/O-standards dynamically; at boot time, it configures the chip to the protocol it uses for communicating with other chips, and then is stays that way. The reason for having this configurability is that the CPU manufacturer can offer a single chip model to users of several different I/O-standards. Making two, three, four different chips, one per I/O standard is far more expensive. But note: I am not talking about x86 or x64 chips now - more like 8051 or ARM M0-chips.
When an program is run it’s machincode doesn have the data required to run the sound card or the Mother Board or another piece of hardware because all computers contain hardware that is different, it comes from different vendors. As Dave Kreskowiak pointed out: I/O on 'PC class' (general, x86/x64 or similar), is generally done using some standardized hardware at the physical level, e.g. USB, PCIe, ... (or earlier: FireWire, COM-port, VGA, ...). The external device is responsible for adapting to one such standard at the physical signal level.
The PC uses low-level, usually OS provided driver software for transferring bytes, or frames of multiple bytes, from the CPU out on the interface. This is independent of whatever device is in the other end. The device must be able to receive bytes or frames, but this is given by the standard (e.g. by USB) and is not device dependent. Of course this goes both ways, for both input and output.
The driver for the physical interface offers an API that is independent on the actual electronics, and usually standardized (although there may be a couple alternatives) for that class of physical interface. Say, the low-level USB driver offers a standard API for sending a USB frame to a given USB address.
The byte stream, or contents of the frames, contains commands and data that may differ from device to device. This is where you may need a device specific driver. Say, your scanner software uses a standard format for commands and data called TWAIN. You scanner vendor provides a higher-level driver that offers a TWAIN API, with scanner-related commands, and creates a message struct, which it asks the USB low-level driver to pass to the scanner. If you replace your scanner, the application software may still use TWAIN calls, but that scanner vendor provides a different driver, creating different scanner commands, as required by his scanner model. But both the old and the new driver will send their (different) scanner command structs to the same low-level USB driver API. Note that this higher-level driver doesn't relate to the electronics; it leaves that to the low-level USB driver. (Or in the old days: SCSI or FireWire drivers.)
In practice, there will be more levels of drivers. A scanner specific TWAIN driver doesn't go all the way down to USB low level drivers in one sweep. E.g. a command struct, or even more: returned data, may be far too large for a physical USB frame. So the TWAIN driver creates the struct of arbitrary length, and hands it over to a medium level driver which cuts the struct into suitable small pieces, and labels the pieces appropriately, e.g. with a sequence number, for sending one by one to the USB low level driver. For incoming data, this driver level will receive a lot of small frames from the low level USB driver, collect them in the order given by their sequence numbers, and when all pieces have arrived and been glued together to one large struct, it sends it to the higher TWAIN level (or whatever resides above it).
You may see quite a few driver levels, one above the other. Somewhere I read that the Windows driver model defines 32 levels(!). That doesn't mean that you have 32 driver software packages, only that if your protocol needs to do so-and-so, you should do it after this but before that. The so-and-so's are ordered into 32 groups. One driver package may take care of six consecutive groups, another of the next 8. Often, there will be nothing to do in a lot of the groups.
The lowest driver level(s) is common for all devices. Maybe the next few as well; e.g. splitting a large message into USB frames can be done the same way for all kinds of devices. The higher you climb the stack of driver levels, the more likely it is that from that point and up, you have device specific drivers - until you come close to the application, e.g. the TWAIN API that is common to all (or a lot of) scanners. Anything above that is not device dependent.
For some device classes, there are standards going all the way up from physical drivers to application level. E.g. for mass storage devices, there are USB standards covering magnetic disks, memory sticks, external 'passport' flash disks etc. The device will, in its end of the cable, implement all the relevant driver levels, and do the adaptation to its own technology on top of that. The application program on the PC uses the API to the uppermost driver level, and everything below it, with no concern about the technology at the other end. This of course requires the device to have some sort of CPU to decipher incoming messages and to build a reply message, but today even safety pins come with build in CPUs (maybe not this year's model, but I am sure that 2024 safety pins will have CPUs  ).
is it some kind of compile at runtime? A device vendor providing a driver will usually give you a binary, ready to run driver. So he must provide different drivers for CPUs with different instruction sets (e.g. x86, x64, ARM 32 or 64 bits). Usually, a driver is not completely self contained but uses OS services, at least for installation and activation, so there must be different driver versions depending on the OS. They will all be different binary versions, and the installer picks one of them. I.e. no runtime compilation.
Finally: You will rarely if ever see a driver that takes you all the way from the application program down to the physical interface. It will make assumptions that 'someone' provides lower level drivers according to this or that standard. And it will assume that 'If I provide an API according to this or that standard to drivers at higher levels than myself, they will be able to use it'. I have seen quite a few device drivers providing the truly device specific middle/upper layers, but the installer will check if the lower and higher level drivers exist in the system. If they do, they are used. If not, the driver packages has got its own implementation, and they are installed along with the main device driver.
Dave Kreskowiak wrote: Drivers are part of the O/S, not the applications.
At least for the most part, you are certainly right. It can be argued that, say, when I print an MS-Word document to a Postscript printer, the PS generating function is functionally identical to a top level driver for a PS device. A PDF print routine is a top level driver for a PDF device. Generating the PS or PDF protocol elements is usually done at the application level (it may be done by a library routine, yet at application level.)
|
|
|
|
|
Thanks for taking the time to write down all that. In the case of my second question it all boils down to Windows being a very versatile piece of software.
|
|
|
|
|
I have a very pure hardware question that only an electronics engineer would possibly be able to answer. And that is, how do I remove the infinitessimal dimples formed by lowering the "hammer" on a four-conductor zif ribbon using the tiny plastic squeeze wedge in the board-soldered receptor so-as to make the contact surface of each end of the thing flat again? I suspect, due to the nature of the moving fold, as a servo rotates, that these indentations have weathered to such an extent that my electrical signal is being lost. And I can't keep pulling the ends out and sticking them back in to get the motor swinging again ... because it's just not the solution.
I might possibly be able to obtain a new zif four-connector but if I had a solution to reduce the amount of gas required to motor north to the electronics store that would be better. A punch perhaps?
Any informed suggestions = very helpful.
Thanks!
|
|
|
|
|
Hi All,
Using an Arduino to drive a servo motor (well trying).
#include <Servo.h>
Servo myServo;
int servoPin = 2;
uint16_t i = 0;
void setup() {
myServo.attach(servoPin);
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
HERE:
i = 0;
for(i = 1; i <= 180; i++)
{
myServo.write(i);
delay(15);
}
for(i = 180; i >= 1; i--)
{
myServo.write(i);
delay(15);
}
goto HERE;
}
Now what I believe Should happen is digital Pin 2 which is being used as the servo pin goes high and the due to the loop the pulse is 'stretched' from 1 to 180 which is taken by Servo and magiced it into a value and sent via pin 2, once this is done the value get counted down from 180 back to 1 by the second loop.
What happens is by scoping the pin the pulse is one get to 180 counts back and does not loop.
This started as a 'Hmmm' problem and has slowly been upgraded. I have put the loops in separate functions to see if that helps, no. Google has been a no and I can't log on to Arduino board as my Pass word was rejected ands the sent pass word link doesn't. Going fully bananas here.
Glenn
PANIC OVER THE CODE NOW WORKS!
|
|
|
|
|
What did you do to get it working ?
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Copied into two separate functions and swore... Basically rubber ducking it.
|
|
|
|
|
glennPattonWork3 wrote: ands the sent pass word link doesn't
You might want to spend some more time on that. Did you try manually copying and then inspecting (versus just clicking)? Sometimes something (either sender or email client) can end up adding stuff where it shouldn't to the url.
Or create a new account?
|
|
|
|
|
No the saved log in didn't work went back to manual list tried again same problem.
|
|
|
|
|
Why would you put the HERE label and goto statement in there when the Arduino constantly executes the loop function for you automatically?
|
|
|
|
|
That was part of the problem it was hitting the bottom of the second for loop and not looping (or seeming too),
Oh man I hate the fact the Arduino servo library means you have to bit bang to change the frequency.
|
|
|
|
|
It's not Arduino, but there are Arduino compatible, cheaper, more powerful boards made by a company called Espressif out of China.
They make good SoCs and used by many people, including me professionally.
I recommend the ESP32 based devices. You can get like an M5 Stack Core2 which is pretty neat, or like a Lilygo TTGO T-Display T1 (i have several), or my favorite - one of the Makerfabs ESP Display lines like the Parallel, the 4" or the 4.3"
You can also get them as raw devkits, but they don't use the arduino form factor (although a 3rd party makes arduino form factor ESP32 devkits I can't recommend them)
If you do go that route, reddit's /r/esp32 is a really good resource (when they get around to being finished with their reddit protest)
Check out my IoT graphics library here:
https://honeythecodewitch/gfx
|
|
|
|
|
While programming an Arduino device from my Linux desktop, I've found it quite helpful to fill my code with progress output to the serial port e.g.
Serial.println(" CONNECTED");
and then watch the progress from another window with tail -f
tail -f /dev/ttyX
where ttyX is the serial port of the Arduino device. (On USB it can change every time you plug it in.)
You need to run the tail command as root or have added yourself to the "dialout" group.
p.s. you don't need the "goto HERE"
|
|
|
|
|
Hi,
I know I don't need goto HERE that was left over from a previous hack to prove to myself it was looping (in the past I have used HELL as a label there's something oddly satisfying about type goto HELL!)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
