I would like to make an Windows application that receives an .hex file and than it uploads to an AVR microcontroller (in my case ATmega88p) via a programmer (like Pocket AVR Programmer or similar) .
I need to be able to send a new .hex file to the application but the application should not be able to change the .hex. Does something like that already exist?
I searched if visual studio has any library to send data to an microcontroller but I did not find any useful hint.
Thank you for your time.
EDIT:
As suggested my problem using different words:
I want an standalone application that is able to send .hex data via a simple programmer to a microcontroller (ATmega88p).
Where should I start? I have some experience in .NET. Is it possible in Visual studio? Does something like that already exist?
avrdude is a preexisting application that is able to program to a number of AVR micro controllers through a number of different interfaces. This is a console application. While I don't have experience with Visual Studio, I imagine most IDEs are able to call a command line application with the appropriate arguments.
In this case, avrdude needs to know which chip you're using (-p), which programming interface is connected to the chip (-c), and where the hex file is (-U). In your case, you're using the ATMega88p, so you'll pass -p m88p, a pocket programmer (which is essentially a USBTiny): -Pusb -c usbtiny, and the command to write your micro controller's flash, so -U flash:w:path\to/your/file.hex
The whole command looks like this:
avrdude -Pusb -c usbtiny -p m88p -U flash:w:path\to\your\file.hex
You can learn more by reading ladyada's AVRDUDE tutorial
Related
I have an Arduino where I would like to send an command to the command prompt.
My solution to the problem would be to make a batch program that listen to the serial port and then runs the command, but I do not know how to do this.
Any suggestions?
If you need a console application you can write a console application in, e.g., C# with Visual Studio and start the application via CMD.
The application itself, can listen and print out all incoming serial data. I would recommend you to use the bidirectional serial connection library, called CmdMessenger. The usage is quite straightforward and there are several examples and documentation resources on the web. I think you can easily adapt the examples for your application scenario.
I have an application in windows, that opens a com port. It attempts to call a comport, then fails and prompts me with an error.
The issue is this is very legacy software that we no longer have the source code for. I'm wondering if anyone knows of a way that can trace, or follow a program calling a com port to find out what com port its attempting to allocate.
Appearantly you can use Process Explorer (as called out in this post) to search for processes using serial ports. It sounds like you should be able to use the same searching concept called out the other post to find what you need.
I actually gave up on this solution and re-wrote the entire program in a week, it had to be done due to binary compatibility issues with the PCI cards.
I have a Linux application (whose code I have access) which must communicate via serial port with a windows one (third party, no access to code). The windows app runs in Wine, so I want to set Wine's com1 to something and make my software read and write from there. I guess the best way is to use pseudo-terminals, is that so?
Is there a way to simply create a pseudo-terminal pair from command line in Linux? I've already know how to do this using the API, but is there a way to do this from bash?
Maybe with socat or something like it?
You might be able to use something like this (untested):
socat PTY,link=$HOME/.wine/dosdevices/com1,raw,echo=0 PTY,link=$HOME/tmp/dev/myserial,raw,echo=0
This will create two back-to-back PTY's which is a bit of overkill, but socat will copy data between them. The wine program would open one side of the link as COM1, and your program would open $HOME/tmp/dev/myserial to communicate with COM1.
A while back I was following some tutorials an assembly. I was running it all on a windows machine, compiling with NASM and then writing the compiled code to a floppy disk, then reboot and try the code. This process was long and time consuming and sadly was not on a mac. When I found out that Xcode for mac installed NASM I immediately tried to compile some code. The code compiled fine. The issue is testing it. On a mac I have no floppy (not like I want to use one) so Im not sure how to test this. I looked in to Q (kju) and found it would only emulate things on an ISO file. So I guess what Im asking is is it possible to install the compiled code on an ISO file for testing? (Note: the code when compiled forms a .bin file)
Thanks for any help
I don't know exactly what you are trying to test (a boot loader maybe?) but you don't need to reboot or boot from a disk just to run assembled code (unless it is a boot loader or something).
Either way, if you need to "reboot" to test, I suggest running an emulator. Sun VirtualBox is super easy to use and free and emulates a standard x86 architecture (including floppy drives)! So that may work for you in the short term. If you ever want to create an ISO image in the future, you can do that with the command line utility hdiutil. In a terminal window, type man hdiutil or visit the online man page for more information on using that to create all kinds of disk images.
Windows XP Embedded is missing the NULL or "NUL" device. For one thing, Visual Studio seems to require it and trying to build a project aborts with a PRJ0015 error.
Anyone know how to configure an XPe image to include support for the NUL device?
"Null Device Driver" is available in the XPe Target Designer, but it's normally hidden. Apparently each component has a visibility level, and if it's lower than that set in the Target Designer options (Tools->Options), it's hidden. Null Device Driver is at level 200, so I set the level to 100 and could see it and install it.
There's another important situation where you're going to want the NUL device: if you're installing some or all of the Cygwin UNIX solutions for Windows. In particular, if you're doing something like, oh, I don't know, to pick a completely random example, trying to put an SSH server on the damned thing so you can, just on a lark, say, log in and maintain it.
That's right-- Cygwin actually maps its UNIX /dev/null device to the Windows NUL device. You know, for maximum compatibility. Just in case the platform-specific implementation of IMMEDIATELY THROWING DATA INTO THE TOILET AND OBLITERATING IT, NEVER TO BE SEEN AGAIN, UNTIL THE HEAT DEATH OF THE UNIVERSE, happened to be novel and innovative.
While cygwin will INSTALL without NUL available, it will not, in fact, actually enjoy a typical work day. This is most evident the first time you try to launch a bash shell, and notice a slew of error messages about /dev/null resulting in no such file or directory errors. One presumes the device is perhaps actually just an NTFS link, but who knows.
In any case, the fix is to add the "Null Device Driver" component, helpfully located under Software -> System -> Other, a surprisingly small category which also contains such useful components as Internet Checkers, the Schedule Service Command Line Utility, the 1394 Kernel Debugger Support Library, EBCDIC support for Microsoft Bob, some cheat codes for Zork, and the code pages to say "(A)bort, (R)etry, (I)gnore, (F)ail?" in Muppet Swedish ("(B)ork, b(o)rk, bo(r)k, bor(k)?")
Hope this helps,
Matt "Breakpoint" Heck
Running Visual Studio itself on XP Embedded doesn't seem like it'd be supported. You should build on a full OS and then just deploy your application to XP embedded.