A shield for stm32f4disco - sram
Locked
|
Bogdan, I'm thinking on a devel of a small shield for stm32f4disco
board, as the first step with a sram on it. I've found a 2Mx16 55ns sram in my junk box, but it seems "slow" to me for that mcu. What is your experience as you run 1Mb sram in your stm32f103 eLuaBrain system? P. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
On Thu, Dec 15, 2011 at 9:39 PM, pito <[hidden email]> wrote: Bogdan, I'm thinking on a devel of a small shield for stm32f4disco First of all: excellent idea. Second: 55ns might be indeed a tad too slow. In general, the experience with external SRAM is that it slows Lua quite a bit. This is unfortunate, but both very logical (as every single value in Lua (be it number, string, table or anything else) is allocated on the heap) and necessary. So, as as rule of thumb, the faster the SRAM, the better (but you already knew that :) ). The SRAM on the STM3210E-EVAL has a 10ns access time and it works quite well. I never looked at the SRAM initialization code, thus I don't know how the external memory controller is set; in particular, I don't know what timings are set for the external SRAM access. On the other hand, at 55ns the maximum theoretical speed is about 18MHz, which seems quite low. If I'd to this (and did I say this is an excellent idea already?) I'd try to at least design the whole thing for a faster memory. If you can find a 10ns memory in the same package as your 55ns memory, chances are you won't even need to change your PCB, so everybody wins :)
If you do this and you have some space left on your shield, please let me know, maybe we can fit the video generator there ... Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
..this is about the availability and the price of the SRAMS. BGA
packages are nogo for DIY, SDRAMS are nogo for stm32f4, and PSRAMS are slow (~70ns) and BGA. The only 10ns TSOP candidates I see are: IS61WV102416BLL-10TLI (10ns 1Mx16) IS61WV20488BLL-10TLI (10ns, 2Mx8) The big Q is where to get them cheap?? P. ----- PŮVODNÍ ZPRÁVA ----- Od: "Bogdan Marinescu" <[hidden email]> Komu: "eLua Users and Development List (www.eluaproject.net)" <[hidden email]> Předmět: Re: [eLua-dev] A shield for stm32f4disco - sram Datum: 16.12.2011 - 12:46:19 > Hi, > > On Thu, Dec 15, 2011 at 9:39 PM, pito > <[hidden email]> wrote: > > > Bogdan, I'm thinking on a devel of a small > > shield for stm32f4disco > > > board, as the first step with a sram on it. I've > > found a 2Mx16 55ns > > > sram in my junk box, but it seems "slow" to me > > for that mcu. What is > > > your experience as you run 1Mb sram in your > > stm32f103 eLuaBrain > > > system? P. > > > > First of all: excellent idea. Second: 55ns might > be indeed a tad too slow. > In general, the experience with external SRAM is > that it slows Lua quite a > bit. This is unfortunate, but both very logical > (as every single value in > Lua (be it number, string, table or anything else) > is allocated on the > heap) and necessary. So, as as rule of thumb, the > faster the SRAM, the > better (but you already knew that :) ). The SRAM > on the STM3210E-EVAL has a > 10ns access time and it works quite well. I never > looked at the SRAM > initialization code, thus I don't know how the > external memory controller > is set; in particular, I don't know what timings > are set for the external > SRAM access. On the other hand, at 55ns the > maximum theoretical speed is > about 18MHz, which seems quite low. If I'd to this > (and did I say this is > an excellent idea already?) I'd try to at least > design the whole thing for > a faster memory. If you can find a 10ns memory in > the same package as your > 55ns memory, chances are you won't even need to > change your PCB, so > everybody wins :) > If you do this and you have some space left on > your shield, please let me > know, maybe we can fit the video generator there > ... > > Best, > Bogdan > > > > _______________________________________________ > > eLua-dev mailing list > > [hidden email] > > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > -- Nakupujte vánoční dárky levněji. Více o vánoční akci Economia najdete na http://web.volny.cz/data/click.php?id=1313 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
2011/12/16 pito <[hidden email]>
..this is about the availability and the price of the SRAMS. BGA Nowhere....they're ~24USD on Digikey, and smaller sizes cost about the same per bit (4Mb is ~$6, 8Mb is ~$18). I did a Digikey search, and nobody else (IDT, Cypress, etc) looks significantly cheaper. If you need speed but want to spend less, look at using a smaller size, although ISSI's smaller SRAMs are in different packages (e.g. 44-TSOP instead of 48-TSOP). (Side note: huge internal SRAM is coming at a hopefully affordable price: Freescale's next generation Kinetis ARM MCU's will have 512K SRAM). --Tony
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
..Do we even need such fast srams? Not sure the interfaces allow a
10ns "access/rd/wr time". Did not analyse yet in detail, but there is no such "zero wait state" mode. So the speedup between 10ns and 55ns might not be 5.5 but 1.6. I've got a CY62177EV30 (2Mx16, tsop-I 48pin 55ns) but I am not too hurry into a pcb design until it is clear whether it make sense to invest time or we rather wait for a 2MByte internal sram :). p. ----- PŮVODNÍ ZPRÁVA ----- Od: "Tony" <[hidden email]> Komu: "eLua Users and Development List (www.eluaproject.net)" <[hidden email]> Předmět: Re: [eLua-dev] A shield for stm32f4disco - sram Datum: 16.12.2011 - 22:06:29 > 2011/12/16 pito <[hidden email]> > > > ..this is about the availability and the price > > of the SRAMS. BGA > > > packages are nogo for DIY, SDRAMS are nogo for > > stm32f4, and PSRAMS > > > are slow (~70ns) and BGA. > > The only 10ns TSOP candidates I see are: > > IS61WV102416BLL-10TLI (10ns 1Mx16) > > IS61WV20488BLL-10TLI (10ns, 2Mx8) > > The big Q is where to get them cheap?? P. > > > > Nowhere....they're ~24USD on Digikey, and > > smaller sizes cost about the > > same per bit (4Mb is ~$6, 8Mb is ~$18). I did a > Digikey search, and nobody > else (IDT, Cypress, etc) looks significantly > cheaper. If you need speed > but want to spend less, look at using a smaller > size, although ISSI's > smaller SRAMs are in different packages (e.g. > 44-TSOP instead of 48-TSOP). > (Side note: huge internal SRAM is coming at a > hopefully affordable price: > Freescale's next generation Kinetis ARM MCU's will > have 512K SRAM). > > --Tony > > > > ----- PŮVODNÍ ZPRÁVA ----- > > Od: "Bogdan Marinescu" > > <[hidden email]> > > > Komu: "eLua Users and Development List > > (www.eluaproject.net)" > > > <[hidden email]> > > Předmět: Re: [eLua-dev] A shield for > > stm32f4disco - sram > > > Datum: 16.12.2011 - 12:46:19 > > > > > Hi, > > > > > > On Thu, Dec 15, 2011 at 9:39 PM, pito > > > <[hidden email]> wrote: > > > > > > > Bogdan, I'm thinking on a devel of a small > > > > shield for stm32f4disco > > > > > board, as the first step with a sram on > > > > > it. I've > > > > > > > > found a 2Mx16 55ns > > > > > sram in my junk box, but it seems "slow" > > > > > to me > > > > > > > > for that mcu. What is > > > > > your experience as you run 1Mb sram in > > > > > your > > > > > > > > stm32f103 eLuaBrain > > > > > system? P. > > > > > > > > > > First of all: excellent idea. Second: 55ns > > > might > > > > > be indeed a tad too slow. > > > In general, the experience with external SRAM > > > is > > > > > that it slows Lua quite a > > > bit. This is unfortunate, but both very > > > logical > > > > > (as every single value in > > > Lua (be it number, string, table or anything > > > else) > > > > > is allocated on the > > > heap) and necessary. So, as as rule of thumb, > > > the > > > > > faster the SRAM, the > > > better (but you already knew that :) ). The > > > SRAM > > > > > on the STM3210E-EVAL has a > > > 10ns access time and it works quite well. I > > > never > > > > > looked at the SRAM > > > initialization code, thus I don't know how the > > > external memory controller > > > is set; in particular, I don't know what > > > timings > > > > > are set for the external > > > SRAM access. On the other hand, at 55ns the > > > maximum theoretical speed is > > > about 18MHz, which seems quite low. If I'd to > > > this > > > > > (and did I say this is > > > an excellent idea already?) I'd try to at > > > least > > > > > design the whole thing for > > > a faster memory. If you can find a 10ns memory > > > in > > > > > the same package as your > > > 55ns memory, chances are you won't even need > > > to > > > > > change your PCB, so > > > everybody wins :) > > > If you do this and you have some space left on > > > your shield, please let me > > > know, maybe we can fit the video generator > > > there > > > > > ... > > > > > > Best, > > > Bogdan > > > > > > > > > > _______________________________________________ > > > > > > > eLua-dev mailing list > > > > [hidden email] > > > > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > > > > > > > > > > > > > > -- > > Nakupujte vánoční dárky levněji. Více o vánoční > > akci Economia > > > najdete na > > http://web.volny.cz/data/click.php?id=1313 > > > > > _______________________________________________ > > eLua-dev mailing list > > [hidden email] > > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > -- Nakupujte vánoční dárky levněji. Více o vánoční akci Economia najdete na http://web.volny.cz/data/click.php?id=1313 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
 
|
Nuccio Raciti |
who is interested in increasing the flexibility of the serial module?
|
|
Hi All,
potentially any eLua boards can have two or more UART, for example Mizar will have two physical UART plus one coming from the USB (CDC UART), so I think could be useful choice dynamically which UART will be used by the Console, by the TERM and so on.... So my proposal is to change dynamically (via eLua commands) the assignment. What do you think? Cheers, Nuccio _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Tony-12
2011/12/16 Tony <[hidden email]> 2011/12/16 pito <[hidden email]> This is true, but I'd be a bit cautious. Sure, the internal memory is getting larger and larger, but there are still some constraints that must be respected when designing the chip. For example, the latest M4 cores from NXP can have up to 264k of RAM on-chip; however, the parts that have 264k of RAM don't have any Flash at all. It's likely that something similar will happen with Freescale's Kinetis and with similar parts from other manufacturers. Then again, I know very little about how chips are actually fabricated, so these restrictions might disappear in the near future.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Nuccio Raciti
Hi Nuccio,
On Sat, Dec 17, 2011 at 3:28 PM, Nuccio Raciti <[hidden email]> wrote:
Hi All, It can be done, but I don't think I understand the use scenario. For example, let's assume that you want to change the console UART using an eLua command. But, in order to give an eLua command, you probably need to have eLua already up and running on an UART (the one configured at compile time). So what advantage would you have by changing the console UART at runtime when you already have a functional one? On the other hand, if you DON'T have a functional one, you probably won't be able to issue the eLua command(s) to change it. Right? Or I'm missing something?
Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
> For example,
> the latest M4 cores from > NXP can have up to 264k of RAM on-chip; however, > the parts that have 264k > of RAM don't have any Flash at all. Few weeks back during a NXP workshop I discussed with the NXP guy that topic - sram on the chip. He said srams on chip are expensive as the srams (and we know that) are large structures so they occupy most of the chip. The chipmakers are not happy with that. I recommended him to go for 32nm fab instead of 90nm (9x bigger yield from a single wafer) but the flash is limiting then (it seems the flash cells cannot be made such small) and, of course, again the Q was who will buy all that stuff to pay the dev costs. It seems they do not sell too many devices these days..p. -- Nakupujte vánoční dárky levněji. Více o vánoční akci Economia najdete na http://web.volny.cz/data/click.php?id=1313 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Nuccio Raciti |
Re: who is interested in increasing the flexibility of the serial module?
|
|
In reply to this post by BogdanM
Il 17/12/2011 17:00, Bogdan Marinescu ha scritto:
> Hi Nuccio, > > On Sat, Dec 17, 2011 at 3:28 PM, Nuccio Raciti > <[hidden email] <mailto:[hidden email]>> wrote: > > Hi All, > > potentially any eLua boards can have two or more UART, > for example Mizar will have two physical UART plus one coming from > the USB (CDC UART), > so I think could be useful choice dynamically which UART will be > used by the Console, by the TERM and so on.... > > So my proposal is to change dynamically (via eLua commands) the > assignment. > > What do you think? > > > It can be done, but I don't think I understand the use scenario. For > example, let's assume that you want to change the console UART using > an eLua command. But, in order to give an eLua command, you probably > need to have eLua already up and running on an UART (the one > configured at compile time). So what advantage would you have by > changing the console UART at runtime when you already have a > functional one? On the other hand, if you DON'T have a functional one, > you probably won't be able to issue the eLua command(s) to change it. > Right? Or I'm missing something? > > Best, > Bogdan > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev suppose you have the console on Uart0 and a VGA module (like eluabrain or Mizar VGA module) on Uart1, now you could want to send commands via the console but you could get terminal output on VGA using TERM functionalities (using the VGA as a sort of "synoptic screen"). Also, I'm near to finish the IDE, inside it I have a console terminal with ANSI/VT100 capability (a minimal set for now), so the user can run some eLua programs as Hungman without Hardware. It will be wonderful, if without build and reprogram the board, he will able to see/run the same program on the VGA module. So is more important to be able to change the "TERM" assignment, but as we can have more UART also for the console, maybe we can start to think also for it. For example if the USB is not connected the Console is on Uart0 (via first HW serial port), but if the USB-CDC Uart is connected, the "platform/xxx/platform.c" should have the possibility to change (just during the boot) the default Console. I hope I have good exposed my point of view :-/ Ciao, Nuccio _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Sat, Dec 17, 2011 at 6:35 PM, Nuccio Raciti <[hidden email]> wrote: Il 17/12/2011 17:00, Bogdan Marinescu ha scritto: Perfectly, thank you. I understand where you're heading now. Implementing this kind of thing shouldn't be much of an effort. The terminal subsystem already has generic functions for input/output which are assigned at runtime using pointers, so changing them is as easy as reinitializing the terminal code by calling 'term_init' (never tried that, but it should work). The console has an equivalent mechanism (src/newlib/getstd.c); if you change the pointers to read/write functions you get yourself a new console (you probably also need to empty the stdio buffers before changing the console). I can help with specific implementation details if you need this.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Nuccio Raciti |
Re: who is interested in increasing the flexibility of the serial module?
|
|
Il 17/12/2011 17:51, Bogdan Marinescu ha scritto:
> > > On Sat, Dec 17, 2011 at 6:35 PM, Nuccio Raciti > <[hidden email] <mailto:[hidden email]>> wrote: > > Il 17/12/2011 17:00, Bogdan Marinescu ha scritto: > > Hi Nuccio, > > > On Sat, Dec 17, 2011 at 3:28 PM, Nuccio Raciti > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> wrote: > > Hi All, > > potentially any eLua boards can have two or more UART, > for example Mizar will have two physical UART plus one > coming from > the USB (CDC UART), > so I think could be useful choice dynamically which UART > will be > used by the Console, by the TERM and so on.... > > So my proposal is to change dynamically (via eLua commands) the > assignment. > > What do you think? > > > It can be done, but I don't think I understand the use > scenario. For example, let's assume that you want to change > the console UART using an eLua command. But, in order to give > an eLua command, you probably need to have eLua already up and > running on an UART (the one configured at compile time). So > what advantage would you have by changing the console UART at > runtime when you already have a functional one? On the other > hand, if you DON'T have a functional one, you probably won't > be able to issue the eLua command(s) to change it. Right? Or > I'm missing something? > > Best, > Bogdan > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] <mailto:[hidden email]> > https://lists.berlios.de/mailman/listinfo/elua-dev > > Hi Bogdan, > > suppose you have the console on Uart0 and a VGA module (like > eluabrain or Mizar VGA module) on Uart1, now you could want to > send commands via the console but you could get terminal output on > VGA using TERM functionalities (using the VGA as a sort of > "synoptic screen"). > > Also, I'm near to finish the IDE, inside it I have a console > terminal with ANSI/VT100 capability (a minimal set for now), so > the user can run some eLua programs as Hungman without Hardware. > > It will be wonderful, if without build and reprogram the board, he > will able to see/run the same program on the VGA module. > > So is more important to be able to change the "TERM" assignment, > but as we can have more UART also for the console, maybe we can > start to think also for it. > > For example if the USB is not connected the Console is on Uart0 > (via first HW serial port), but if the USB-CDC Uart is connected, > the "platform/xxx/platform.c" should have the possibility to > change (just during the boot) the default Console. > > I hope I have good exposed my point of view :-/ > > > Perfectly, thank you. I understand where you're heading now. > Implementing this kind of thing shouldn't be much of an effort. The > terminal subsystem already has generic functions for input/output > which are assigned at runtime using pointers, so changing them is as > easy as reinitializing the terminal code by calling 'term_init' (never > tried that, but it should work). The console has an equivalent > mechanism (src/newlib/getstd.c); if you change the pointers to > read/write functions you get yourself a new console (you probably also > need to empty the stdio buffers before changing the console). I can > help with specific implementation details if you need this. > > Best, > Bogdan > "CON_UART_ID" with a more dynamic thing....but I have seen that some changes are in common code, so we needs a common agreement... Best, Nuccio > > Ciao, > > Nuccio > > > > > > > > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] <mailto:[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 |
|
|
Tim Michals |
Re: A shield for stm32f4disco - sram
|
|
In reply to this post by Pito
The maple native has external sram http://leaflabs.com/devices/ there was some discussions about SRAM speed in the forum. >Few weeks back during a NXP workshop I discussed with the NXP guy >that topic - sram on the chip. He said srams on chip are expensive >as the srams (and we know that) are large structures so they occupy >most of the chip. The chipmakers are not happy with that. I >recommended him to go for 32nm fab instead of 90nm (9x bigger yield >from a single wafer) but the flash is limiting then (it seems the >flash cells cannot be made such small) and, of course, again the Q >was who will buy all that stuff to pay the dev costs. It seems they >do not sell too many devices these days..p. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
2011/12/17 Bogdan Marinescu <[hidden email]>
Freescale is claiming 1M->4M flash on chip. However, these won't be shipping for a long time (sometime next year); Freescale doesn't even have a part number list up yet so at this point I consider it all marketing-talk, not reality. I'm wondering what the price will be; Freescale has actually had PowerPC MCU's with lots of RAM and flash for years, but they are hard to get and very expensive (>$50). Renesas is another company with a roadmap (for the Rx CPUs) with lots of SRAM and flash, but their existing chips are hard to get and expensive. Getting back to off-chip memory, does anyone know what the impact of SDRAM is on eLua performance? My guess is that even 55nSec SRAM would have better performance, but the per bit cost of SDRAM is enticing. --Tony
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> Getting back to off-chip memory, does anyone know
> what the impact of SDRAM > is on eLua performance? My guess is that even > 55nSec SRAM would have > better performance, but the per bit cost of SDRAM > is enticing. If talking stm32f4 the SDRAM is not applicable unfortunately. The only alternative to SRAMs are PSRAMs when talking stm32f4. But all are BGA and ~55-70ns today. PSRAMs are SDRAMs with built-in SRAM interface and refresh. P. -- Nakupujte vánoční dárky levněji. Více o vánoční akci Economia najdete na http://web.volny.cz/data/click.php?id=1313 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Tony-12
2011/12/19 Tony <[hidden email]>
I think (and hope) the ARM chips will be priced a bit less aggresively, given the competition.
Yes. Also, many of their chips have expensive proprietary toolchains (I didn't check GCC's list of targets lately though, things might've got better in this area).
SDRAMs are a no-go for STM32 in particular. Other than that, we have a board built around a LPC2468 and generous ammount of SDRAM, it works quite well. Truth be told, until now I focused 85% on making eLua smaller and only 15% worrying about its performance, so I didn't run any actual tests, it was just a "hey, this feels quite snappy" feeling.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Pito
Though SDRAM isn't an option, there was some discussion around using
that type of RAM with AVR32 with eLua that might be relevant: http://groups.google.com/group/mizar32/browse_thread/thread/72f0ef650733f8f2?pli=1 I can't recall the timing configurations or wait states used with the SDRAM on that platform. I'm not completely sure what the timings and wait state configurations might be like based on a quick perusal of the code. Martin can probably speak to that a bit better. All in all, performance degradation could probably be pretty easily estimated based on running SRAM below the maximum spec and then extrapolating. You might want to check on whether prefetch and cacheing might be used for external SRAM or PSRAM as it is for internal types. As for pricing differences, might one just chalk that up to production volume differences and perhaps process differences? I suspect that if SRAM were about the same price as DRAM we would be using that in our PCs rather than SRAM since it tends to be faster and lower power consumption since it doesn't need to be refreshed periodically. I'm curious where this discussion leads though, as I wouldn't mind having a fairly painless way to add memory for an STM32F4. 2011/12/19 pito <[hidden email]>: >> Getting back to off-chip memory, does anyone know >> what the impact of SDRAM >> is on eLua performance? My guess is that even >> 55nSec SRAM would have >> better performance, but the per bit cost of SDRAM >> is enticing. > If talking stm32f4 the SDRAM is not applicable unfortunately. The > only alternative to SRAMs are PSRAMs when talking stm32f4. But all > are BGA and ~55-70ns today. PSRAMs are SDRAMs with built-in SRAM > interface and refresh. > P. > > > -- > Nakupujte vánoční dárky levněji. Více o vánoční akci Economia > najdete na http://web.volny.cz/data/click.php?id=1313 > > _______________________________________________ > 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 |
|
|
In reply to this post by Nuccio Raciti
On Sat, Dec 17, 2011 at 11:00 AM, Nuccio Raciti <[hidden email]> wrote:
> Il 17/12/2011 17:51, Bogdan Marinescu ha scritto: >> >> >> >> On Sat, Dec 17, 2011 at 6:35 PM, Nuccio Raciti <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> Il 17/12/2011 17:00, Bogdan Marinescu ha scritto: >> >> Hi Nuccio, >> >> >> On Sat, Dec 17, 2011 at 3:28 PM, Nuccio Raciti >> <[hidden email] <mailto:[hidden email]> >> <mailto:[hidden email] >> >> <mailto:[hidden email]>>> wrote: >> >> Hi All, >> >> potentially any eLua boards can have two or more UART, >> for example Mizar will have two physical UART plus one >> coming from >> the USB (CDC UART), >> so I think could be useful choice dynamically which UART >> will be >> used by the Console, by the TERM and so on.... >> >> So my proposal is to change dynamically (via eLua commands) the >> assignment. >> >> What do you think? >> >> >> It can be done, but I don't think I understand the use >> scenario. For example, let's assume that you want to change >> the console UART using an eLua command. But, in order to give >> an eLua command, you probably need to have eLua already up and >> running on an UART (the one configured at compile time). So >> what advantage would you have by changing the console UART at >> runtime when you already have a functional one? On the other >> hand, if you DON'T have a functional one, you probably won't >> be able to issue the eLua command(s) to change it. Right? Or >> I'm missing something? >> >> Best, >> Bogdan >> >> >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] <mailto:[hidden email]> >> >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> Hi Bogdan, >> >> suppose you have the console on Uart0 and a VGA module (like >> eluabrain or Mizar VGA module) on Uart1, now you could want to >> send commands via the console but you could get terminal output on >> VGA using TERM functionalities (using the VGA as a sort of >> "synoptic screen"). >> >> Also, I'm near to finish the IDE, inside it I have a console >> terminal with ANSI/VT100 capability (a minimal set for now), so >> the user can run some eLua programs as Hungman without Hardware. >> >> It will be wonderful, if without build and reprogram the board, he >> will able to see/run the same program on the VGA module. >> >> So is more important to be able to change the "TERM" assignment, >> but as we can have more UART also for the console, maybe we can >> start to think also for it. >> >> For example if the USB is not connected the Console is on Uart0 >> (via first HW serial port), but if the USB-CDC Uart is connected, >> the "platform/xxx/platform.c" should have the possibility to >> change (just during the boot) the default Console. >> >> I hope I have good exposed my point of view :-/ >> >> >> Perfectly, thank you. I understand where you're heading now. Implementing >> this kind of thing shouldn't be much of an effort. The terminal subsystem >> already has generic functions for input/output which are assigned at runtime >> using pointers, so changing them is as easy as reinitializing the terminal >> code by calling 'term_init' (never tried that, but it should work). The >> console has an equivalent mechanism (src/newlib/getstd.c); if you change the >> pointers to read/write functions you get yourself a new console (you >> probably also need to empty the stdio buffers before changing the console). >> I can help with specific implementation details if you need this. >> >> Best, >> Bogdan >> > Yes, isn't hard to implement, maybe just matter to change a constant > "CON_UART_ID" with a more dynamic thing....but I have seen that some > changes are in common code, so we needs a common agreement... I haven't tried this either, but it might be nice to have a few other things like this be configurable after boot time or be insertable into a configuration file that could live on a card or in flash and be loaded at boot time. We could significantly reduce the space of possible useful build configurations for platforms where flash space isn't a major problem by including all the needed components and making the options for these configurable at boot like networking (DHCP vs Static), Console type and endpoint (TCP vs UART vs virtual UART CDC). I don't think we would have to go crazy with it, but in addition to some of the usage described in this thread, there are definitely times where I've found myself making an array of builds to support some newer platforms like Soldercore which can have an ethernet or CDC console and it might be nice to make some of these options not dependent on the use of a full toolchain. I'd be willing to participate in some coding and discussion around making (if nothing else) adjustable console settings. -jsnyder > > Best, > Nuccio > > > > > > >> >> Ciao, >> >> Nuccio >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] <mailto:[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 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 |