I have to find some solution to flash my Program Memory into my PIC32 without MPLab.
I think the first step is to generate the .hex file from the source code.
And the second one, flashing the memory into the PIC.
How can I do it using a standard IDE or command line please ?
(Currently using MPLab, I use the MPLab Snap to flash the program memory)
Related
I am new to Common Lisp. This is how I develop programs in other languages, and also how I now develop programs in Common Lisp:
Open a text editor (e.g. vim or emacs) to create/edit a text file.
Write source code into the text file. (If unsure about the behavior of a snippet of code, and an REPL is available, then evaluate the snippet in the REPL, verify that the snippet evaluates as expected, and then go back to writing more code.)
Save the text file.
Ask the compiler/interpreter to load and run the source code in the text file. (e.g. sbcl --script myprog.lisp)
Go to step 1 if needed.
This is the conventional write-compile-run development cycle for most programming languages. However, in the lisp world, I hear things like "interactive development" and "image-based development", and I feel that I am missing out on an important feature of Common Lisp. How do I do "image-based development" instead of "write-compile-run development"?
Can someone provide a step-by-step example of "image-based development" similar to how I described "write-compile-run development" above?
(Note: I am using SBCL)
In typical Common Lisp implementations the runtime, the compiler, parts of the development environment and the program you are developing reside in the same program and share the same object space. The compiler is always available while you develop the program and the program can be incrementally developed. The development tools have access to all objects and can inspect their state. One can also undefine/remove, replace, enhance functionality from the running program.
Thus:
don't restart the program you are developing. Stay connected and update it. Even days, weeks, or months - if possible.
write code in such a way that the program can be replicated and built from scratch if necessary. Build it from time to time and fix any build problems.
once you use our program and there is an error -> fix the error within the program, while being able to inspect the full error state
creating a running program is either loading all code into a plain Lisp all the time or saving an executable image with the loaded code/data
Fixes to program bugs can also shipped to the user as compiled Lisp files, which gets loaded into the delivered program and update the code then.
Let's say that you are using SBCL with Emacs and SLIME (e. g. through Portacle).
Open Emacs
Start SLIME (M-x slime) — this starts a “plain” Lisp process in the background and connects the editor functions provided by slime to it; then gives you a REPL that is also connected into this process (image)
Open a text file (e. g. foo.lisp)
Type some code
Press C-c C-k to compile the file and load it into the running Lisp process
Switch to the REPL, try it out
Switch to the Lisp file (step 4).
This is just very basic usage. Further things to do/learn
You can also compile and load just a single toplevel form (C-c C-c)
Learn about packages
Learn about systems (ASDF)
Learn how to use Quicklisp to get the libraries you want
Learn how to access inline documentation from the REPL
Note that you never need to unload your program, you just modify it, even when downloading and loading new libraries. This makes the feedback cycle instantaneous in most cases. You also never need to switch away from the IDE (Emacs).
Similar to an .exe file, is there a way to make a 'distributable' of an Arduino program? Some sort of ready-to-upload file... I'd like to share the program but the code should be kept the most secret as possible, or at least make it hard to know.
You can distribute the .hex binary file, and then let the users upload the binary on the Arduino themselves.
The ordinary Arduino IDE already does that for you when you click on the button verify & upload, so you simply have to take the generated .hex file and give it away.
Or you can use Arduino Makefile to get your .hex binaries using any other development environment.
Note: even though the source code is not included nor displayed, it is possible to reverse engineer an .hex binary as much as it is possible to do it with an .exe binary.
I guess I'm having a basic understanding issue regarding the nodemcu/ESP8266 when it is used with the Arduino IDE and/or visual micro (for MS Visual Studio).
Everytime I upload a program/sketch which is obviously written in C in this case, it is compiling and uploading a binary of about 280kb, even if it is only a simple "blink" example.
Is it some kind of firmware being uploaded everytime or is it just monsterious libraries needed for the ESP to work with the Arduino IDE?
If it is firmware, do you normally "update" the firmware to a more recent build when working with the Arduino IDE? When using the nodemcu LUA firmware, there are periodic updates.
Thanks!
Basically, you build the firmware, which is a combination of your own code, and lots of other code/libraries.
All the other parts are part of the Arduino ESP8266 core, which does indeed get updates (it lives here: https://github.com/esp8266/Arduino). And it itself contains the Espressif SDK, which also gets updates (https://github.com/esp8266/Arduino/tree/master/tools/sdk).
Like NodeMCU you can get periodic updates, but they are of the core, and the only way to get them into your firmware is to recompile your sketch.
This is completely normal - When writing code for an interpreted language like Lua for the ESP/NodeMCU, you're just uploading what is a relatively small text file(s), as the code needed to run it is already on the chip, and doesn't change.
However, when you start working with compiled languages like C (With the Espressif SDK only, for example), or C++ with the Arduino IDE, you are replacing the entire firmware each time your code changes. This includes the TCP/IP stack, WiFi management, the logic controlling the PHY/MAC interface, the mini OS, and a host of other bits to make your ESP8266 work. Even if your code appears to be just a simple "blink" sequence, there's a lot of code running behind the scenes to make it possible, leading to the large sketch size.
Generally, every change to your sketch code will produce a complete copy of everything needed to create a bootable, runnable binary for the ESP8266. This is what is causing the 280KiB file. Since each copy of your code includes the newest (Or at least whatever is in your IDE at the time) copy of the system level code, there is no separate update process - Each time you upload your sketch, the system code is updated too.
Additionally, there is some extra overhead from the Arduino abstraction on the Espressif SDK, leading to a larger resulting binary size.
I'm currently reading a Japanese book on embedded OS/RTOS es except that I am not using the recommended hardware as I already had a seeeduino microcontroller.(atmega328p) The book is about KOZOS "12 steps to making your own embedded OS" by Sakai Hiroaki(It's hiro-something)
I'm stuck at the part where I need to write into the flash ROM of the atmega328p because the author is using a different chip called H8. He uses a software called h8write and uses that in his OS, but I honestly have no idea what is going on at this point, and what the avr replacement for h8write would be. I've looked around to no avail as there is minimal documentation on what h8write does aside from the "it helps you write to flash ROM" that shows up in the book.
This is the first time I'm doing lower layer stuff and it's frankly terrifying...
I'm using ubuntu 14.04 if that helps.
If I understand correctly, the h8write program is supposed to run on your computer and transfer the compiled to the microcontroller. You are using a seeeduino, which is an Arduino compatible board, with Ubuntu. The standard way of programming on this environment is with the arduino software:
install the arduino package (sudo apt-get install aruino)
type the command arduino from a terminal emulator: this brings an IDE where you can type your code
connect the seeeduino to an USB port
click on the button with a right-pointing arrow: this will take care of everything (compiling, linking and uploading to the seeeduino)
Once you are comfortable with this workflow, you can try to get your hands dirty with low-level stuff. The Arduino IDE is built on top of smaller utilities like avr-gcc, avr-libc, avr-as and avrdude. Avrdude is the program used to transfer the compiled program to the Arduino/seeeduino, i.e. write to the flash. You can use these utilities directly, from the command line. This is however complicated by the fact that you will need to pass many command-line arguments, so I recommend you automate the process using a Makefile. Thankfully there is a generic Arduino Makefile available that makes this quite easy:
install the generic Arduino Makefile: sudo apt-get install arduino-mk
read the instructions in the comments at the top (the Makefile is at /usr/share/arduino/Arduino.mk)
write your own project-specific Makefile as per these instructions
type make to compile your program
type make upload to upload to the seeeduino (i.e. write the flash).
This application note tells you how to write the flash memory during program run.
A very good tutorial on how to use the PROGMEM attribute in AVR microcontrollers can be found here
I have purchased the CC2540 EK I am trying to program the SampleBLE peripeheral onto the CC2540EM. I am using the IAR tool chain and the USB cable is connected directly to the SMARTRF05EB (not using the CC debugger) In IAR I can download the code but the SimpleBLEperipheral does not seem to run.
Looks like the App that came with the CC250EM from the factory has been erased and I am unable to reload that application again.
What is the exact project workspace that I shoud open?
Are there any changes that need to be made to the IAR project so that it can be run on the CC2540EM?
The IAR project name is SimpleBLEPeripheral - CC2540DK- MiniKeyfob - this seems to suggest that it is meant for the keyfob and not the CC2540EM.
It's due to the build option.
You got to set the build option to "cc2540", instead of "cc2540df-mini keyfob"...
In IAR, you can set the build option in the drop-down menu in the Workspace area. (it's right under the word "Workspace")
After doing this, compile and reload the hex file to the module.
It should be able to solve the problem.