ET-STM32 program via TTL (or suggest me a USB to serial converter cable)
Locked
12
12
 
|
Bryan Laur |
Re: ET-STM32 program via TTL (or suggest me a USB to serial converter cable)
|
Sounds great.
Thank you very much =) 2011/3/9 James Snyder <[hidden email]> Some could disagree, but I believe the consensus is that since there's _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
OK, I just did a little bit of testing on this. It appears that in
the default state, without the power management features the ICL3232 on this board actually starts in the high state by default (3.3V) and essentially just tries to hold that constantly. With my FTDI converter, logic high is 4.16V instead of 5V and logic low is 1.28V. I connected a scope to the other side of the resistor and found that the voltage supplied by the ICL3232 does vary in response to the current demands, with it showing 3.68V during logic high from the FTDI, and 2.24V when the FTDI is driving things low, which translates into 5.3 mA of current being sunk during the high state (default) and 9.6 mA being sourced when low. According to the datasheet, this chip is rated for continuous short circuit, outputting around 32 mA under those conditions, so I'm not too worried about it aside from wasting power. Supposedly the FTDI cable I have has some current limiting resistors on the Tx line that are 270 Ohms, but if they are there they must be less than that since it has to be sinking that 9.6 mA at 1.28 V. I'm not sure what the maximum amount of current it can sink safely, but absolute maximum current output for my FTDI cable is rated at 24 mA, so I'm definitely not sourcing to much current. They list sink current conditions up to 8 mA in DC characteristics, but I'm not sure what the maximum is. The only time I've had any trouble with the setup was when I had a variable frequency drive nearby and I realized the FTDI cable isn't shielded, which was causing some data corruption. After I replaced the cable with a shielded one and prior to that I've been using the same FTDI chip and the same MCU, so they haven't burned out in all of that tinkering. That said, since I don't need the RS-232 level serial on the board I was doing this testing on, I'm just desoldering R4, since I've already soldered USART1 as the main UART using this TTL-level adapter. It's simpler than rerouting to another UART, and I can confirm that after removal the line in question now goes all the way to 5V and 0V under the control of the TTL-level serial adapter. One additional thought since the default state is apparently high: it might not be a bad idea to check the datasheet of your TTL usb->serial adapter and check how much current it is supposed to be able to source and sink. It looks like the PL2303 (http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303HX/Documents/Datasheet/ds_pl2303HX_v15F.pdf) is rated to supply less current on the data lines than the FT232R (http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf), even though they both use CMOS drivers, so I suspect that one could have a bit more trouble out-driving the current-limited ICL3232. Also given the lower ratings for the PL2303 I would try to make sure there were at least some resistance on its TX line to limit current. Some cables and boards may already have this. If appropriate current limits are in place the worst I would expect would be unreliable data reception on the MCU side. On Wed, Mar 9, 2011 at 4:38 PM, Bryan Laur <[hidden email]> wrote: > Sounds great. > Thank you very much =) > > 2011/3/9 James Snyder <[hidden email]> >> >> Some could disagree, but I believe the consensus is that since there's >> a 100 Ohm resistor there you're probably not going to short or burn >> out anything by using a TTL adapter on USART1 (in eLua UART 0). >> Judging from the datasheet what the chip tries to do in the state >> where nothing is connected to the input pins is hold that line low, so >> as long as you don't connect something to the original UART connector, >> I believe you don't get undefined behavior, so it generally should >> continue to work. I suspect the worst case scenario is more along the >> lines of stability rather than safety. I've successfully flashed this >> thing using the bootloader in this configuration dozens of times, and >> I don't believe I've had issues related to this in general UART >> operation over the course of months of on and off usage. It's also >> probably been powered on for at least a hundred hours or so in this >> configuration. >> >> I'm pretty comfortable with the following simplification: >> Don't use this configuration for some application that you're going to >> box up and deploy, but for tinkering it's probably fine. >> >> Also, I'm not 100% sure, but in looking up the bootloader protocol it >> sounds like it listens on all of the USARTS so aside from minor >> reconfiguration of the eLua build it may also be not too painful to >> use another serial peripheral. >> >> >> I'm going to take some measurements this afternoon of the RX line to >> see if the ICL3232 is sucking up any current on my setup. I'll share >> my observations. >> >> -jsnyder >> >> 2011/3/9 Bryan Laur <[hidden email]>: >> > Just to be clear, what's the worst thing that could happen? >> > >> > I am trying to tell if by "safer" you mean "more stable". >> > Or are you suggesting that it could be possible to damage something in >> > this >> > manner? >> > >> > Sorry if this is a dumb question, but I'd rather be safe than sorry. >> > >> > Thanks >> > >> > 2011/3/9 Ronan Paixão <[hidden email]> >> >> >> >> It might be safer to use another UART after installing eLua, but the >> >> built-in bootloader only works on UART0. >> >> >> >> 2011/3/9 Bogdan Marinescu <[hidden email]> >> >>> >> >>> On Wed, Mar 9, 2011 at 2:57 AM, James Snyder <[hidden email]> >> >>> wrote: >> >>> > This is actually a good point. I haven't had any major problems >> >>> > with >> >>> > this during usage over the course of a few months, but this may vary >> >>> > with some other USB->Serial devices. Of course, one way to avoid >> >>> > all >> >>> > of this is to just use another UART on the board. One other thing >> >>> > I'll add however is that the ICL3232 on the board does have a >> >>> > current >> >>> > limiting 100 Ohm resistor (R4) between the MCU's RX pin and the >> >>> > receiver output pin on the RS-323 level shifter, so I would expect >> >>> > this would be why I've had things behave as stably as they have. >> >>> >> >>> Ah, indeed, I didn't know that. It should be safe then. It would be >> >>> even safer to use another UART, as you suggested :) >> >>> >> >>> Best, >> >>> Bogdan >> >>> >> >>> > >> >>> > On Tue, Mar 8, 2011 at 3:56 PM, Bogdan Marinescu >> >>> > <[hidden email]> wrote: >> >>> >> On Tue, Mar 8, 2011 at 10:37 PM, James Snyder >> >>> >> <[hidden email]> wrote: >> >>> >>> If you have TTL level serial interfacing with that module, yeah, >> >>> >>> you >> >>> >>> can just connect to the TX/RX pins which are PA9 and PA10. Most >> >>> >>> of >> >>> >> >> >>> >> ... that said, if you're using the ET-STM32 board you might have an >> >>> >> electrical problem since the ET-STM32 already has a RS232 to UART >> >>> >> level converter connected on the UART1 pins and this converter >> >>> >> forces >> >>> >> the RX pin level to 0V (idle) when there isn't anything connected >> >>> >> to >> >>> >> the UART1 using the cable supplied with the ET-STM32. I'd connect >> >>> >> the >> >>> >> other converter with a resistor on the RX pin to avoid potential >> >>> >> problems with two different circuits driving the same pin. This >> >>> >> problem might be more theoretical than practical but I'd still take >> >>> >> it >> >>> >> into account. >> >>> > >> >>> > Just to clarify do you mean the STM >> >>> > >> >>> >> >> >>> >> Best, >> >>> >> Bogdan >> >>> >> >> >>> >>> On Tue, Mar 8, 2011 at 9:58 AM, Bryan Laur <[hidden email]> >> >>> >>> wrote: >> >>> >>>> Sorry, I should've been more explicit. >> >>> >>>> You've probably already answered my question, but I'd like to >> >>> >>>> make >> >>> >>>> sure I >> >>> >>>> got all the ducks in the row. >> >>> >>>> >> >>> >>>> The module I suggested is a TTL module, and therefore would not >> >>> >>>> be >> >>> >>>> plugged >> >>> >>>> into the serial interface on the chip. >> >>> >>>> >> >>> >>>> To use this, I would simply attach the correct pins on the TTL >> >>> >>>> module to the >> >>> >>>> correct pins the STM32 module, correct? >> >>> >>>> >> >>> >>>> There is no circuitry related to the TTL to RS232 chip that is >> >>> >>>> required, >> >>> >>>> correct? >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> On Tue, Mar 8, 2011 at 10:53 AM, Bogdan Marinescu >> >>> >>>> <[hidden email]> wrote: >> >>> >>>>> >> >>> >>>>> Hi, >> >>> >>>>> >> >>> >>>>> On Tue, Mar 8, 2011 at 5:47 PM, Bryan Laur <[hidden email]> >> >>> >>>>> wrote: >> >>> >>>>> > Hey guys, >> >>> >>>>> > >> >>> >>>>> > I am interested in using eLua on the ET-STM32 module. >> >>> >>>>> > >> >>> >>>>> > I, however, am sick of using these profolic usb serial cables. >> >>> >>>>> > I >> >>> >>>>> > can >> >>> >>>>> > never >> >>> >>>>> > get them to work right. >> >>> >>>>> >> >>> >>>>> Interesting, I have one and works very well. >> >>> >>>>> >> >>> >>>>> > I am wondering whether it is possible to interface with it's >> >>> >>>>> > bootloader >> >>> >>>>> > using a module such as this: >> >>> >>>>> > >> >>> >>>>> > >> >>> >>>>> > >> >>> >>>>> > http://cgi.ebay.com/USB-TTL-Converter-Module-buildin-in-CP2102-/160553632013?pt=LH_DefaultDomain_0&hash=item2561be010d >> >>> >>>>> > >> >>> >>>>> > >> >>> >>>>> > My guess is yes, but I would like to confirm this before I >> >>> >>>>> > make >> >>> >>>>> > my >> >>> >>>>> > purchase. >> >>> >>>>> >> >>> >>>>> In theory, yes. Plus the CP2102 is a good chip from what I know. >> >>> >>>>> >> >>> >>>>> Best, >> >>> >>>>> Bogdan >> >>> >>>>> _______________________________________________ >> >>> >>>>> eLua-dev mailing list >> >>> >>>>> [hidden email] >> >>> >>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >> >>> >>>> >> >>> >>>> >> >>> >>>> _______________________________________________ >> >>> >>>> eLua-dev mailing list >> >>> >>>> [hidden email] >> >>> >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >> >>> >>>> >> >>> >>>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> -- >> >>> >>> James Snyder >> >>> >>> Biomedical Engineering >> >>> >>> Northwestern University >> >>> >>> [hidden email] >> >>> >>> PGP: http://fanplastic.org/key.txt >> >>> >>> Phone: (847) 448-0386 >> >>> >>> _______________________________________________ >> >>> >>> eLua-dev mailing list >> >>> >>> [hidden email] >> >>> >>> https://lists.berlios.de/mailman/listinfo/elua-dev >> >>> >>> >> >>> >> _______________________________________________ >> >>> >> eLua-dev mailing list >> >>> >> [hidden email] >> >>> >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >>> >> >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > James Snyder >> >>> > Biomedical Engineering >> >>> > Northwestern University >> >>> > [hidden email] >> >>> > PGP: http://fanplastic.org/key.txt >> >>> > Phone: (847) 448-0386 >> >>> > >> >>> _______________________________________________ >> >>> eLua-dev mailing list >> >>> [hidden email] >> >>> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> >> >> >> >> _______________________________________________ >> >> eLua-dev mailing list >> >> [hidden email] >> >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> >> > >> > >> > _______________________________________________ >> > eLua-dev mailing list >> > [hidden email] >> > https://lists.berlios.de/mailman/listinfo/elua-dev >> > >> > >> >> >> >> -- >> James Snyder >> Biomedical Engineering >> Northwestern University >> [hidden email] >> PGP: http://fanplastic.org/key.txt >> Phone: (847) 448-0386 > > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Mar 10, 2011 at 7:45 AM, James Snyder <[hidden email]> wrote:
> OK, I just did a little bit of testing on this. It appears that in > the default state, without the power management features the ICL3232 > on this board actually starts in the high state by default (3.3V) and > essentially just tries to hold that constantly. Yes, that's how it's supposed to be. I said before that the "idle" state is at 0V, but I was wrong. The "idle" state on the RS232 is actually logic 1 (+Vcc, the same as the stop bit) and changes when a start bit (0V - GND) arrives. > With my FTDI > converter, logic high is 4.16V instead of 5V and logic low is 1.28V. > I connected a scope to the other side of the resistor and found that > the voltage supplied by the ICL3232 does vary in response to the > current demands, with it showing 3.68V during logic high from the > FTDI, and 2.24V when the FTDI is driving things low, which translates > into 5.3 mA of current being sunk during the high state (default) and > 9.6 mA being sourced when low. According to the datasheet, this chip > is rated for continuous short circuit, outputting around 32 mA under > those conditions, so I'm not too worried about it aside from wasting > power. > > Supposedly the FTDI cable I have has some current limiting resistors > on the Tx line that are 270 Ohms, but if they are there they must be > less than that since it has to be sinking that 9.6 mA at 1.28 V. I'm > not sure what the maximum amount of current it can sink safely, but > absolute maximum current output for my FTDI cable is rated at 24 mA, > so I'm definitely not sourcing to much current. They list sink > current conditions up to 8 mA in DC characteristics, but I'm not sure > what the maximum is. Thanks for the very detailed analysis. Best, Bogdan > On Wed, Mar 9, 2011 at 4:38 PM, Bryan Laur <[hidden email]> wrote: >> Sounds great. >> Thank you very much =) >> >> 2011/3/9 James Snyder <[hidden email]> >>> >>> Some could disagree, but I believe the consensus is that since there's >>> a 100 Ohm resistor there you're probably not going to short or burn >>> out anything by using a TTL adapter on USART1 (in eLua UART 0). >>> Judging from the datasheet what the chip tries to do in the state >>> where nothing is connected to the input pins is hold that line low, so >>> as long as you don't connect something to the original UART connector, >>> I believe you don't get undefined behavior, so it generally should >>> continue to work. I suspect the worst case scenario is more along the >>> lines of stability rather than safety. I've successfully flashed this >>> thing using the bootloader in this configuration dozens of times, and >>> I don't believe I've had issues related to this in general UART >>> operation over the course of months of on and off usage. It's also >>> probably been powered on for at least a hundred hours or so in this >>> configuration. >>> >>> I'm pretty comfortable with the following simplification: >>> Don't use this configuration for some application that you're going to >>> box up and deploy, but for tinkering it's probably fine. >>> >>> Also, I'm not 100% sure, but in looking up the bootloader protocol it >>> sounds like it listens on all of the USARTS so aside from minor >>> reconfiguration of the eLua build it may also be not too painful to >>> use another serial peripheral. >>> >>> >>> I'm going to take some measurements this afternoon of the RX line to >>> see if the ICL3232 is sucking up any current on my setup. I'll share >>> my observations. >>> >>> -jsnyder >>> >>> 2011/3/9 Bryan Laur <[hidden email]>: >>> > Just to be clear, what's the worst thing that could happen? >>> > >>> > I am trying to tell if by "safer" you mean "more stable". >>> > Or are you suggesting that it could be possible to damage something in >>> > this >>> > manner? >>> > >>> > Sorry if this is a dumb question, but I'd rather be safe than sorry. >>> > >>> > Thanks >>> > >>> > 2011/3/9 Ronan Paixão <[hidden email]> >>> >> >>> >> It might be safer to use another UART after installing eLua, but the >>> >> built-in bootloader only works on UART0. >>> >> >>> >> 2011/3/9 Bogdan Marinescu <[hidden email]> >>> >>> >>> >>> On Wed, Mar 9, 2011 at 2:57 AM, James Snyder <[hidden email]> >>> >>> wrote: >>> >>> > This is actually a good point. I haven't had any major problems >>> >>> > with >>> >>> > this during usage over the course of a few months, but this may vary >>> >>> > with some other USB->Serial devices. Of course, one way to avoid >>> >>> > all >>> >>> > of this is to just use another UART on the board. One other thing >>> >>> > I'll add however is that the ICL3232 on the board does have a >>> >>> > current >>> >>> > limiting 100 Ohm resistor (R4) between the MCU's RX pin and the >>> >>> > receiver output pin on the RS-323 level shifter, so I would expect >>> >>> > this would be why I've had things behave as stably as they have. >>> >>> >>> >>> Ah, indeed, I didn't know that. It should be safe then. It would be >>> >>> even safer to use another UART, as you suggested :) >>> >>> >>> >>> Best, >>> >>> Bogdan >>> >>> >>> >>> > >>> >>> > On Tue, Mar 8, 2011 at 3:56 PM, Bogdan Marinescu >>> >>> > <[hidden email]> wrote: >>> >>> >> On Tue, Mar 8, 2011 at 10:37 PM, James Snyder >>> >>> >> <[hidden email]> wrote: >>> >>> >>> If you have TTL level serial interfacing with that module, yeah, >>> >>> >>> you >>> >>> >>> can just connect to the TX/RX pins which are PA9 and PA10. Most >>> >>> >>> of >>> >>> >> >>> >>> >> ... that said, if you're using the ET-STM32 board you might have an >>> >>> >> electrical problem since the ET-STM32 already has a RS232 to UART >>> >>> >> level converter connected on the UART1 pins and this converter >>> >>> >> forces >>> >>> >> the RX pin level to 0V (idle) when there isn't anything connected >>> >>> >> to >>> >>> >> the UART1 using the cable supplied with the ET-STM32. I'd connect >>> >>> >> the >>> >>> >> other converter with a resistor on the RX pin to avoid potential >>> >>> >> problems with two different circuits driving the same pin. This >>> >>> >> problem might be more theoretical than practical but I'd still take >>> >>> >> it >>> >>> >> into account. >>> >>> > >>> >>> > Just to clarify do you mean the STM >>> >>> > >>> >>> >> >>> >>> >> Best, >>> >>> >> Bogdan >>> >>> >> >>> >>> >>> On Tue, Mar 8, 2011 at 9:58 AM, Bryan Laur <[hidden email]> >>> >>> >>> wrote: >>> >>> >>>> Sorry, I should've been more explicit. >>> >>> >>>> You've probably already answered my question, but I'd like to >>> >>> >>>> make >>> >>> >>>> sure I >>> >>> >>>> got all the ducks in the row. >>> >>> >>>> >>> >>> >>>> The module I suggested is a TTL module, and therefore would not >>> >>> >>>> be >>> >>> >>>> plugged >>> >>> >>>> into the serial interface on the chip. >>> >>> >>>> >>> >>> >>>> To use this, I would simply attach the correct pins on the TTL >>> >>> >>>> module to the >>> >>> >>>> correct pins the STM32 module, correct? >>> >>> >>>> >>> >>> >>>> There is no circuitry related to the TTL to RS232 chip that is >>> >>> >>>> required, >>> >>> >>>> correct? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On Tue, Mar 8, 2011 at 10:53 AM, Bogdan Marinescu >>> >>> >>>> <[hidden email]> wrote: >>> >>> >>>>> >>> >>> >>>>> Hi, >>> >>> >>>>> >>> >>> >>>>> On Tue, Mar 8, 2011 at 5:47 PM, Bryan Laur <[hidden email]> >>> >>> >>>>> wrote: >>> >>> >>>>> > Hey guys, >>> >>> >>>>> > >>> >>> >>>>> > I am interested in using eLua on the ET-STM32 module. >>> >>> >>>>> > >>> >>> >>>>> > I, however, am sick of using these profolic usb serial cables. >>> >>> >>>>> > I >>> >>> >>>>> > can >>> >>> >>>>> > never >>> >>> >>>>> > get them to work right. >>> >>> >>>>> >>> >>> >>>>> Interesting, I have one and works very well. >>> >>> >>>>> >>> >>> >>>>> > I am wondering whether it is possible to interface with it's >>> >>> >>>>> > bootloader >>> >>> >>>>> > using a module such as this: >>> >>> >>>>> > >>> >>> >>>>> > >>> >>> >>>>> > >>> >>> >>>>> > http://cgi.ebay.com/USB-TTL-Converter-Module-buildin-in-CP2102-/160553632013?pt=LH_DefaultDomain_0&hash=item2561be010d >>> >>> >>>>> > >>> >>> >>>>> > >>> >>> >>>>> > My guess is yes, but I would like to confirm this before I >>> >>> >>>>> > make >>> >>> >>>>> > my >>> >>> >>>>> > purchase. >>> >>> >>>>> >>> >>> >>>>> In theory, yes. Plus the CP2102 is a good chip from what I know. >>> >>> >>>>> >>> >>> >>>>> Best, >>> >>> >>>>> Bogdan >>> >>> >>>>> _______________________________________________ >>> >>> >>>>> eLua-dev mailing list >>> >>> >>>>> [hidden email] >>> >>> >>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> _______________________________________________ >>> >>> >>>> eLua-dev mailing list >>> >>> >>>> [hidden email] >>> >>> >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >>>> >>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> James Snyder >>> >>> >>> Biomedical Engineering >>> >>> >>> Northwestern University >>> >>> >>> [hidden email] >>> >>> >>> PGP: http://fanplastic.org/key.txt >>> >>> >>> Phone: (847) 448-0386 >>> >>> >>> _______________________________________________ >>> >>> >>> eLua-dev mailing list >>> >>> >>> [hidden email] >>> >>> >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >>> >>> >>> >> _______________________________________________ >>> >>> >> eLua-dev mailing list >>> >>> >> [hidden email] >>> >>> >> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > James Snyder >>> >>> > Biomedical Engineering >>> >>> > Northwestern University >>> >>> > [hidden email] >>> >>> > PGP: http://fanplastic.org/key.txt >>> >>> > Phone: (847) 448-0386 >>> >>> > >>> >>> _______________________________________________ >>> >>> eLua-dev mailing list >>> >>> [hidden email] >>> >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >> >>> >> >>> >> _______________________________________________ >>> >> eLua-dev mailing list >>> >> [hidden email] >>> >> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >> >>> > >>> > >>> > _______________________________________________ >>> > eLua-dev mailing list >>> > [hidden email] >>> > https://lists.berlios.de/mailman/listinfo/elua-dev >>> > >>> > >>> >>> >>> >>> -- >>> James Snyder >>> Biomedical Engineering >>> Northwestern University >>> [hidden email] >>> PGP: http://fanplastic.org/key.txt >>> Phone: (847) 448-0386 >> >> > > > > -- > James Snyder > Biomedical Engineering > Northwestern University > [hidden email] > PGP: http://fanplastic.org/key.txt > Phone: (847) 448-0386 > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Ronan Paixão-2 |
Re: ET-STM32 program via TTL (or suggest me a USB to serial converter cable)
|
|
In reply to this post by jbsnyder
Em 9 de março de 2011 19:23, James Snyder <[hidden email]> escreveu:
Actually, for the ET-STM32, which is a high-density device, the bootloader is only in USART1. From the datasheet: Embedded boot loader The embedded boot loader is located in the System memory, programmed by ST during production. It is used to reprogram the Flash memory with one of the available serial interfaces: ● In low-, medium- and high-density devices the bootoader is activated through the USART1 interface. ● In XL-density devices the boot loader is activated through the following interfaces: USART1 or USART2 (remapped). ● In connectivity line devices the boot loader can be activated through one of the following interfaces: USART1, USART2 (remapped), CAN2 (remapped) or USB OTG FS in Device mode (DFU: device firmware upgrade). The USART peripheral operates with the internal 8 MHz oscillator (HSI). The CAN and USB OTG FS, however, can only function _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |