|
Apologies for the shouting but this is important.
When answering a question please:
- Read the question carefully
- Understand that English isn't everyone's first language so be lenient of bad spelling and grammar
- If a question is poorly phrased then either ask for clarification, ignore it, or mark it down. Insults are not welcome
- If the question is inappropriate then click the 'vote to remove message' button
Insults, slap-downs and sarcasm aren't welcome. Let's work to help developers, not make them feel stupid.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
For those new to message boards please try to follow a few simple rules when posting your question.- Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
- Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
- Keep the subject line brief, but descriptive. eg "File Serialization problem"
- Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
- Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
- Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
- If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode "<" (and other HTML) characters when pasting" checkbox before pasting anything inside the PRE block, and make sure "Use HTML in this post" check box is checked.
- Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
- Please do not post links to your question into an unrelated forum such as the lounge. It will be deleted. Likewise, do not post the same question in more than one forum.
- Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
- If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
- No advertising or soliciting.
- We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
I've been grappling with a frustrating issue lately and thought I'd seek some advice from this knowledgeable community. The problem at hand is that I'm unable to write to my NTFS-formatted external hard drive when it's connected to my Mac.
Here's a bit of background: I've been using this NTFS-formatted external hard drive primarily on a Windows PC. However, now that I'm a recent Windows-to-macOS switcher and working on my Mac, I find myself unable to add or edit files on this drive. I need to collaborate on some documents, and it becomes a bit of a headache.
After some research, I'm aware that macOS doesn't offer native write support for NTFS drives. Formatting to exFAT is an option, but it means moving all my data somewhere else temporarily, which led me to consider third-party solutions. One NTFS for Mac solution that's come up is iBoysoft NTFS for Mac. It claims to enable full read-write access to NTFS drives on Mac, but I wanted to gather some insights and experiences from the community here.
Has anyone been through this before? If so, how did you resolve it? If you've tried iBoysoft NTFS for Mac or have alternative suggestions, please do share your thoughts and experiences. I'm eager to learn and resolve this problem.
Thanks a bunch!
|
|
|
|
|
No idea.
But I will note that I had to read your entire post to figure out your real question. And read it twice just be be sure. Certainly not what I expected from the subject line.
What you actually are asking is ...
'Have you tried iBoysoft NTFS? If so did you like it? Would you suggest any alternative?'
|
|
|
|
|
Googling ntfs for mac produces lots of hits, including this one 6 Best NTFS for Mac Software in 2023 [Free and Paid]
All I can recommend is that you take a look at some of the reviews and choose what you think will be best for your use case.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
