I keep having to make my own proto-boards, every time I do an ESP8266 project, NRF24L project, or anything that uses UART serial ports and Arduino. This is because I usually have to re-flash firmware on these other devices, which means I have to manually swap jumper wires back and fourth, or wire a switch - and have another FTDI board. It's not difficult, but this is really time consuming, each time I make a new project.
Let's take for example my Nextion display. All I need is TX & RX, connected to FTDI to flash the firmware on that. When I'm writing code and testing, this pretty much happens all night long - back and fourth between Arduino and the device, I code - test, flash firmware. I do not really need the FTDI, just to have tx/rx pins hooked up to a serial port so I can flash the firmware on this device.
I was just wondering, if anyone knew if there was a short-cut / trick, where I can just go through the same USB port on my Nano, TEMPORARILY bypass the nano, and route the tx/rx traffic (pins 0 and 1 through usb port) THROUGH to my Nextion (or ANY device) to update it's firmware, - THEN disable bypass to return Arduino back to whatever it usually does.
This might be an easy answer for someone else, but I feel like I am confused and appreciate advice, please.
When the Nano is held in reset it essentially disappears from the circuit. You stated that you want to "temporarily bypass the nano". Holding it in reset would do that.
I was just wondering, if anyone knew if there was a short-cut / trick, where I can just go through the same USB port on my Nano, TEMPORARILY bypass the nano, and route the tx/rx traffic (pins 0 and 1 through usb port) THROUGH to my Nextion (or ANY device) to update it's firmware, - THEN disable bypass to return Arduino back to whatever it usually does.
Can you post a block diagram of what you are describing , that shows the Tx/Rx pin wiring ?
I am assuming you understand that the reason you need the FTDI is because it is a USB to TTL-serial converter. If the code you are flashing comes from the PC USB , you need the FTDI to convert it to serial TTL for the device you are flashing. I believe what Coding Badly is saying is that if you have one PC and ONE FTDI and 'n' devices, you can hold ALL but ONE of those devices in RESET , and the one not in reset can be flashed from the FTDI. If you then need to flash a different device, flip the SPST RESET switch on ALL but THAT device to before flashing it. After each flashing , flip the RESET switch the other way, such that NONE of the devices are held in reset. A wiring diagram would clarify whether your components are connected in a manner compatible with that strategy. In theory , it sounds simple. If you are going to do this , I would strongly suggest you wire a red led with a series resistor to the RESET pins of EACH of the devices with the ANODE connected to +5V and the CATHODE to the RESET pin so that when you flip the switch to hold that device in RESET, the RED LED for THAT device turns on because the switch is connecting the cathode to GND. At any given moment, if you are flashing firmware, you would have 'n'-1
leds lit and when not flashing, NO leds lit. This will make it easier to track the device status in the event you get destracted and have to leave and then come back later and don't remember where you left off.
I've used a 3-5K resistor between the arduino Rx and whatever serial plugin I have connected to be ale to upload new/revised code to the arduino without removing the serial plugin.
I've used a 3-5K resistor between the arduino Rx and whatever serial plugin I have connected to be ale to upload new/revised code to the arduino without removing the serial plugin.
I always that the convention was the SLAVE UPLOADS to the MASTER or the MASTER downloads to the SLAVE,
or , alternately,
the HOST DOWNLOADS to the SLAVE and the SLAVE UPLOADS to the HOST.
Since the USB port on the arduino is not a HOST port, (you have to buy one if you need the arduino to be a HOST), the HOST for the firmware flash operation would be the PC (or laptop).
Unfortunately, this convention lost popularity long ago when technology opened the gates of hell to people who don't have time to observe any such conventions. On the same topic, most posters refer to the process as simply "loading sketches" (although I hate that term 'sketch' since this isn't an art class) instead of "flashing firmware" (which is the more technically correct term).
raschemmel:
Unfortunately, this convention lost popularity long ago when technology opened the gates of hell to people who don't have time to observe any such conventions.
Or maybe they're just trained on a different convention than your are. Like the Internet.
On the Internet, UPLOADING is when data is sent from my computer to another.
DOWNLOADING is when my computer receives data from another.
Trained on that, it's natural to think that programming a microcontroller is uploading code to it. They're pretty incompatible, and which one is "backwards" depends on which one you learned first. I'm quite a lot younger than you, so I encountered the Internet long before embedded programming. To me, the embedded convention is "backwards".
It's not that I'm not observing a convention, but that I'm observing a different one.
I've used a 3-5K resistor between the arduino Rx and whatever serial plugin I have connected to be ale to upload new/revised code to re-program the arduino without removing the serial plugin.
I understand history of technology and how it has changed, but not every function of everything. I first learned how to UPLOAD something on a 300 baud dial & connect modem, use a terminal to send a stream of dats over telephone line, to swap files with the people I met from the magazines I read that tought me programming on a computer with 32k of memory.
I do care to know how to make the devices work, but not down to an atmomic level, where people on youTube force me to understand the chemistry and metallergy composition of a transister and diodes. I not sure there is enough time in the rest of my whole life to capture every expliicit detail on eveything I may only need to use s few times.
Probably "Loading code" is the simplest way to avoid the whole uploading/downloading controversy.
I agree that Uploading is sending data from your computer to the web, but I don't see how that is relevant to loading code on a laptop or PC into an embedded microcontroller, where it doesn't even matter if you have an internet connection. The PC or Laptop is clearly the HOST and the arduino is clearly the SLAVE, both virtually and technically, so since the direction of the code is from the PC to the arduino, it must be downloading. This is why the IDE function to transfer code from the arduino to the IDE is called "UPLOAD"
I guess that answers all the service calls I got when AOL came out and the people in my office wanted me to come to their private home and help them download the internet on their AOL e-mail computer (for free - naturally, after I work for 14 hours - always in the mood for favors to strangers).
Oh, I apologize for not replying right away - I'm sorry. There reset-hold does work. Thank you for the suggestions. After I read that, I went on studying about the reset pin to find more about it - the information is useful.
