I'm running an old version of eCos (2.0.98) from eCosCentric and I'm attempting to use cyg_flag_timed_wait to periodically update a display (see code, below). My event flag variable g_flags is initialized elsewhere before this thread is created. Other threads access the same event flag but use their own bits within the flag. My problem is with the timed wait behavior of the event flag. At startup I see an initial wait of 30 seconds before the first display update occurs, but the update occurs continually after the initial timeout. The local variable flags always reads 0, indicating timeout has occurred. My understanding is that calling cyg_flag_timed_wait at the top of the loop restarts the timer, but this does not seem to be the case. What am I missing here? Is there something I must do to clear the timeout event? Variable allocation and initialization: static cyg_flag_t g_flags; // thread sync event flags cyg_flag_init(&g_flags); // init thread sync flag // ogDisplayThread - update display static void ogDisplayThread(cyg_addrword_t data) { diag_printf("Entering ogDisplayThread...\r\n"); cyg_flag_setbits(&g_flags, OG_FLAG_DISP_RDY); // say this thread is ready while (1) { cyg_flag_value_t flags; flags = cyg_flag_timed_wait(&g_flags, // timed wait OG_FLAG_DISP_EXIT, // wait for EXIT flag or timeout CYG_FLAG_WAITMODE_AND, 3000); // 30 second timeout diag_printf("ogDisplayThread flag = %08X\r\n", flags); if (flags & OG_FLAG_DISP_EXIT) // if EXIT event occurred { diag_printf("Exiting ogDisplayThread\r\n"); cyg_flag_maskbits(&g_flags, // say this thread is no longer ready OG_FLAG_DISP_RDY|OG_FLAG_DISP_EXIT); cyg_thread_exit(); // and exit thread } else if (!flags) // if timeout occurred (normal condition) { diag_printf("ogDisplayThread sending data\r\n"); ogp_msg_t *msg; // send IP address if (NULL == (msg = malloc(sizeof(ogp_msg_t)))) // allocate a message buffer diag_printf("ogDisplayThread malloc error\r\n"); else { msg->sync = htonl(OGP_SYNC_WORD); // build message msg->src = LOCAL_CMD_SRC; msg->dst = LOCAL_CMD_DST_SET_IPADDR; msg->mtype = LOCAL_CMD_MTYPE; api_eth_get_ip(msg->data, 16); // get IP address string msg->len = htons(strlen(msg->data)+1); // set length ogpPutTxQ(msg); // send message } } else // should never get here diag_printf("ogDisplayThread unexpected event flag\r\n"); } } Debug output (continual after 30 seconds): ogDisplayThread flag = 00000000 ogDisplayThread sending data ogDisplayThread flag = 00000000 ogDisplayThread sending data ogDisplayThread flag = 00000000 ogDisplayThread sending data ogDisplayThread flag = 00000000 ogDisplayThread sending data ogDisplayThread flag = 00000000 ogDisplayThread sending data ogDisplayThread flag = 00000000 ogDisplayThread sending data ogDisplayThread flag = 00000000 ogDisplayThread sending data Thanks, Michael -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Hi Michael, do you initialize the flags somewhere with cyg_flag_init() ? This initialisation needs to be made before the first access of the event flag variable. Best Regards Richard www.itrgmbh.com > -----Ursprüngliche Nachricht----- > Von: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss- > owner@ecos.sourceware.org] Im Auftrag von Michael W. Ellis > Gesendet: Freitag, 27. Mai 2016 15:31 > An: ecos-discuss@ecos.sourceware.org > Betreff: [ECOS] cyg_flag_timed_wait doesn't seem to work as expected > > I'm running an old version of eCos (2.0.98) from eCosCentric and I'm > attempting to use cyg_flag_timed_wait to periodically update a display (see > code, below). My event flag variable g_flags is initialized elsewhere before > this thread is created. Other threads access the same event flag but use their > own bits within the flag. > > My problem is with the timed wait behavior of the event flag. At startup I > see an initial wait of 30 seconds before the first display update occurs, but > the update occurs continually after the initial timeout. The local variable > flags always reads 0, indicating timeout has occurred. My understanding is > that calling cyg_flag_timed_wait at the top of the loop restarts the timer, but > this does not seem to be the case. What am I missing here? Is there > something I must do to clear the timeout event? > > Variable allocation and initialization: > static cyg_flag_t g_flags; // thread sync event flags > cyg_flag_init(&g_flags); // init thread sync flag > > > // ogDisplayThread - update display > static void ogDisplayThread(cyg_addrword_t data) { > diag_printf("Entering ogDisplayThread...\r\n"); > > cyg_flag_setbits(&g_flags, OG_FLAG_DISP_RDY); // say this > thread is ready > > while (1) > { > cyg_flag_value_t flags; > > flags = cyg_flag_timed_wait(&g_flags, // timed wait > OG_FLAG_DISP_EXIT, // wait for EXIT flag or > timeout > CYG_FLAG_WAITMODE_AND, > 3000); // 30 second timeout > > diag_printf("ogDisplayThread flag = %08X\r\n", flags); > > if (flags & OG_FLAG_DISP_EXIT) // if EXIT event > occurred > { > diag_printf("Exiting ogDisplayThread\r\n"); > > cyg_flag_maskbits(&g_flags, // say this thread is no > longer ready > OG_FLAG_DISP_RDY|OG_FLAG_DISP_EXIT); > > cyg_thread_exit(); // and exit thread > } > else if (!flags) // if timeout occurred (normal > condition) > { > diag_printf("ogDisplayThread sending data\r\n"); > ogp_msg_t *msg; > > // send IP address > if (NULL == (msg = malloc(sizeof(ogp_msg_t)))) // allocate a > message buffer > diag_printf("ogDisplayThread malloc error\r\n"); > else > { > msg->sync = htonl(OGP_SYNC_WORD); // build message > msg->src = LOCAL_CMD_SRC; > msg->dst = LOCAL_CMD_DST_SET_IPADDR; > msg->mtype = LOCAL_CMD_MTYPE; > api_eth_get_ip(msg->data, 16); // get IP address string > msg->len = htons(strlen(msg->data)+1); // set length > ogpPutTxQ(msg); // send message > } > } > else // should never get here > diag_printf("ogDisplayThread unexpected event flag\r\n"); > } > } > > Debug output (continual after 30 seconds): > ogDisplayThread flag = 00000000 > ogDisplayThread sending data > ogDisplayThread flag = 00000000 > ogDisplayThread sending data > ogDisplayThread flag = 00000000 > ogDisplayThread sending data > ogDisplayThread flag = 00000000 > ogDisplayThread sending data > ogDisplayThread flag = 00000000 > ogDisplayThread sending data > ogDisplayThread flag = 00000000 > ogDisplayThread sending data > ogDisplayThread flag = 00000000 > ogDisplayThread sending data > > > Thanks, > Michael > > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 27/05/16 14:30, Michael W. Ellis wrote: > I'm running an old version of eCos (2.0.98) from eCosCentric and I'm > attempting to use cyg_flag_timed_wait to periodically update a > display (see code, below). My event flag variable g_flags is > initialized elsewhere before this thread is created. Other threads > access the same event flag but use their own bits within the flag. > > My problem is with the timed wait behavior of the event flag. At > startup I see an initial wait of 30 seconds before the first display > update occurs, but the update occurs continually after the initial > timeout. The local variable flags always reads 0, indicating timeout > has occurred. My understanding is that calling cyg_flag_timed_wait > at the top of the loop restarts the timer, but this does not seem to > be the case. What am I missing here? Is there something I must do > to clear the timeout event? > The problem is your use of 3000 for the timeout. In eCos, timeouts give the wakeup time, not the duration. So, the first call waits until tick 3000, but the rest return immediately since it is now past 3000. The solution is to use cyg_current_time()+3000 in the timeout argument. -- Nick Garnett Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. +44 1223 245571 Registered in England and Wales: Reg No: 4422071 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> -----Original Message----- > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss- > owner@ecos.sourceware.org] On Behalf Of Nick Garnett > Sent: Friday, May 27, 2016 11:27 AM > To: ecos-discuss@ecos.sourceware.org > Subject: Re: [ECOS] cyg_flag_timed_wait doesn't seem to work as > expected > > > > On 27/05/16 14:30, Michael W. Ellis wrote: > > I'm running an old version of eCos (2.0.98) from eCosCentric and I'm > > attempting to use cyg_flag_timed_wait to periodically update a > display > > (see code, below). My event flag variable g_flags is initialized > > elsewhere before this thread is created. Other threads access the > > same event flag but use their own bits within the flag. > > > > My problem is with the timed wait behavior of the event flag. At > > startup I see an initial wait of 30 seconds before the first display > > update occurs, but the update occurs continually after the initial > > timeout. The local variable flags always reads 0, indicating timeout > > has occurred. My understanding is that calling cyg_flag_timed_wait > at > > the top of the loop restarts the timer, but this does not seem to be > > the case. What am I missing here? Is there something I must do to > > clear the timeout event? > > > > The problem is your use of 3000 for the timeout. In eCos, timeouts give > the wakeup time, not the duration. So, the first call waits until tick > 3000, but the rest return immediately since it is now past 3000. > > The solution is to use cyg_current_time()+3000 in the timeout argument. > > -- > Nick Garnett Kernel Architect > eCosCentric Limited http://www.eCosCentric.com The eCos experts > Barnwell House, Barnwell Drive, Cambridge, UK. +44 1223 245571 > Registered in England and Wales: Reg No: 4422071 > This makes perfect sense now. I made this change and everything is working as I expect. Thanks, Michael -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
I have inherited a project based on eCos 2.0.98 and have reached a point where I need to rebuild my library. Most of the folks who originally worked on this project are no longer with the company and our internal documentation is scarce at best. My understanding is that the eCos Configuration Tool is used to make changes to a .ecc file, and then to use this file to build the library. I have located the .ecc file for my project and have attempted to rebuild the library but something seems to be amiss. I see the extras.o, libextras.a and libtarget.a files in _install/lib change but the target.ld and vectors.o files remain unchanged. On one of my changes I updated linker-related files for my hardware in the eCos repository, but the linker files never seem to be regenerated. If I manually delete target.ld and rebuild the library then a new linker file is created. Is there something I'm missing here? I have tried cleaning and then building but nothing seems to make a difference to the linker file. Michael -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 2016-06-16, Michael W. Ellis <mellis@pesa.com> wrote: > I have inherited a project based on eCos 2.0.98 and have reached a point > where I need to rebuild my library. Most of the folks who originally > worked on this project are no longer with the company and our internal > documentation is scarce at best. > > My understanding is that the eCos Configuration Tool is used to make > changes to a .ecc file, and then to use this file to build the library. Yes. However, there are two different ecos configuration tools. A command line one, and a GUI one (there might be multiple similar but different look/feel GUI ones, I don't really know). For all our actuall production code, we use the command-line ecosconfig utility exclusivly. That way you can write a shell script that calls the ecosconfig utility to generate an .ecc file from scratch and then creates the build tree. That shell script is then placed under source control just like the rest of source code. IMO, relying on a GUI tool and accurate/repeatable human clicking for building production code is a huge mistake. You can place the .ecc file under version control if you want, but (IMO) it's far more important that the script that _builds_ the .ecc file is under source control. > I have located the .ecc file for my project and have attempted to > rebuild the library but something seems to be amiss. I see the > extras.o, libextras.a and libtarget.a files in _install/lib change > but the target.ld and vectors.o files remain unchanged. You probably need to start with a new build tree. > On one of my changes I updated linker-related files for my hardware > in the eCos repository, but the linker files never seem to be > regenerated. Only the .c files are used directory from the repository. Most other files get processed and then copied into the build tree. > If I manually delete target.ld and rebuild the library then a new > linker file is created. > > Is there something I'm missing here? I have tried cleaning What do you mean by "cleaning"? > and then building but nothing seems to make a difference to the > linker file. If you're using the GUI config tool, I can't really help. If you're using the command-line one, start with an empty directory. Your script should start with ecosconfig new <platform> then, as needed ecosconfig add <package> econsonfig del <package> and finally change/set/clear whatever package options you need to cat >.tmp$$.cdl <<EOF cdl_component CYGSEM_KERNEL_SCHED_TIMESLICE {user_value 0} cdl_option CYGPKG_IO_NFILE {user_value 256} cdl_option CYGNUM_FILEIO_NFILE {user_value 256} cdl_option CYGNUM_FILEIO_NFD {user_value 256} cdl_option CYGPKG_NET_TFTP {user_value 0} EOF ecosconfig import .tmp$$.cdl That produces the .ecc file. Now you create the build tree ecosconfig tree Now you have a "build tree" that contains things like include files, Makefiles, linker scripts, and basically everything except the .c files. Finally do the build make If you want to rebuild because 0) you changed a CDL file: start over completely at the "ecosconfig new" step in an empty directory. 1) you changed a .h file or linker script or memory map file: start at the "ecosconfig tree" step in a directory containing nothing but the .ecc file. 2) you changed a .c file: you can generally just run "make" again. -- Grant Edwards grant.b.edwards Yow! I'm in direct contact at with many advanced fun gmail.com CONCEPTS. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> -----Original Message----- > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss- > owner@ecos.sourceware.org] On Behalf Of Grant Edwards > Sent: Thursday, June 16, 2016 12:10 PM > To: ecos-discuss@ecos.sourceware.org > Subject: [ECOS] Re: eCos Configuration Tool clewan and rebuild > > On 2016-06-16, Michael W. Ellis <mellis@pesa.com> wrote: > > I have inherited a project based on eCos 2.0.98 and have reached a > > point where I need to rebuild my library. Most of the folks who > > originally worked on this project are no longer with the company and > > our internal documentation is scarce at best. > > > > My understanding is that the eCos Configuration Tool is used to make > > changes to a .ecc file, and then to use this file to build the > library. > > Yes. However, there are two different ecos configuration tools. A > command line one, and a GUI one (there might be multiple similar but > different look/feel GUI ones, I don't really know). > > For all our actuall production code, we use the command-line ecosconfig > utility exclusivly. That way you can write a shell script that calls > the ecosconfig utility to generate an .ecc file from scratch and then > creates the build tree. > > That shell script is then placed under source control just like the > rest of source code. IMO, relying on a GUI tool and > accurate/repeatable human clicking for building production code is a > huge mistake. You can place the .ecc file under version control if you > want, but (IMO) it's far more important that the script that _builds_ > the .ecc file is under source control. Our approach in the past was to use the GUI tool but I agree that your approach is better since the script file more or less self-documents the process and is easily tracked under revision control. Getting from the GUI based configuration to script based configuration requires some trial and error grunt work with file comparison tools to figure out exactly what options were changed in the GUI but it's probably worth it in the long run. You asked what I meant by "cleaning". The GUI tool basically has three build options: clean, library and tests. I had tried using the build clean option, expecting it to remove all intermediate and output files (including my linker file) but this didn't seem to do what I expected. Thanks for the tips. This has helped clarify the situation immensely. Michael -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 2016-06-16, Michael W. Ellis <mellis@pesa.com> wrote: > Our approach in the past was to use the GUI tool but I agree that > your approach is better since the script file more or less > self-documents the process and is easily tracked under revision > control. Getting from the GUI based configuration to script based > configuration requires some trial and error grunt work with file > comparison tools to figure out exactly what options were changed in > the GUI but it's probably worth it in the long run. Yep, reverse-engineering a script from an existing .ecc file is a bit of a chore, but I think it's probably worth it. Like you said, it takes a bit of of file comparison. If enough work was done up-front so that there's a template that includes the proper set of packages it's possible that you won't need much more more than "ecosconfig new <whatever>" "ecosconfig tree" ... with perhaps a few option settings in between. You can also add new templates or change existing ones so that you have to do fewer "ecosconfig add" and "ecosconfig del" commands in your script. That's mostly a matter of personal taste. > You asked what I meant by "cleaning". The GUI tool basically has > three build options: clean, library and tests. Ah. I don't know what exactly what the GUI does when you tell it to "clean". It might just do a "make clean", or it might remove everything except the .ecc file and do an "ecosconfig tree". BTW: I've been assuming you're doing development on a *nix host. If you're doing it under Windows+Cywgin, pretty much all the advise applies, but you end up with a whole extra layer of possible issues with Cygwin. -- Grant Edwards grant.b.edwards Yow! An INK-LING? Sure -- at TAKE one!! Did you BUY any gmail.com COMMUNIST UNIFORMS?? -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 16/06/16 22:41, Grant Edwards wrote: > [...] > Ah. I don't know what exactly what the GUI does when you tell it to > "clean". It might just do a "make clean", That is exactly what it does. > or it might remove everything except the .ecc file and do an > "ecosconfig tree". BTW: I've been assuming you're doing development on > a *nix host. If you're doing it under Windows+Cywgin, pretty much all > the advise applies, but you end up with a whole extra layer of > possible issues with Cygwin. The anoncvs version of GUI configtool is broken when it comes to dependencies, the handling of templates, and even creating a new target configuration. In fact the ordering of the appearance of dependencies within CDL could change the configuration you ended up with as a result of the way that the anoncvs GUI configtool resolves dependencies. Using anoncvs ecosconfig is the better solution as you state, but it too has issues with dependencies so you are recommended to "make clean", "ecosconfig tree", and "make" to ensure everything is built from the correct headers and makefiles. FWIW, the issues with these tools have been been resolved within the eCosPro host tools since eCosPro 3.1.X (including dropping cygwin entirely) and the GUI configtool has become very useful but unfortunately these changes have not made their way back into anoncvs. -- Alex http://www.ecoscentric.com/ The eCos Experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Actually we prefer to work with the GUI. .ecc Files are application project related. It is much more convenient to create the eCos configuration by usage of GUI tool. We were working on all of our projects with the GUI config tool. We managed to create a version, not based on Cygwin as well. Regarding the build library behavior, there should be no difference to the Cygwin version. There is one issue maybe. When we are changing major things in our eCos configuration, we delete the complete build tree folders with file system. Then the config tool is forced to rebuild everything. The folders are somehow named like .\.......build and .\....install\. They are located relative to your path, where the .ecc file is. Richard Rauch www.itrgmbh.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 17/06/16 05:05, Richard Rauch wrote: > There is one issue maybe. When we are changing major things in our eCos > configuration, we delete the complete build tree folders with file system. > Then the config tool is forced to rebuild everything. > The folders are somehow named like .\.......build and .\....install\. They > are located relative to your path, where the .ecc file is. These are created <basename>_install and <basename>_build where <basename> is the base name of the saved .ecc file. Yes, when using the anoncvs GUI configtool the safest method when changing configurations is to delete all and rebuild. However, the anoncvs GUI configtool has a subtle major flaw when creating a configuration by selecting a target that is not the default. All new target configurations are created against the current target and template (often default target and "default" template), and switched to the new target (and/or template). If you have two similar but distinct targets you could end up with conflicts that the anoncvs GUI tool cannot resolve automatically. Even creating a new configuration for the default target can and often does result in a slightly different configuration (but entirely valid) to that created by ecosconfig. If you are using the anoncvs tools, the safest way to create a new configuration is to use "ecosconfig" - it is the tool that almost all eCos maintainers outside eCosCentric use. eCosPro users should upgrade to version 3.1.10 of the Host Tools which exhibit none of the anoncvs host tools issues - new configurations created by both tools are identical - and use the "File->New Target" functionality illustrated in http://www.ecoscentric.com/ecospro/doc/html/user-guide/using-configtool-windows-linux.html -- Alex http://www.ecoscentric.com/ The eCos Experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> > However, the anoncvs GUI configtool has a subtle major flaw when creating a > configuration by selecting a target that is not the default. > All new target configurations are created against the current target and > template (often default target and "default" template), and switched to the > new target (and/or template). If you have two similar but distinct targets you > could end up with conflicts that the anoncvs GUI tool cannot resolve > automatically. Even creating a new configuration for the default target can > and often does result in a slightly different configuration (but entirely valid) > to that created by ecosconfig. We delete the build folders only, but not the .ecc file. If rebuilding with GUI config tool (after build folders deleted) with same .ecc file, the result is exactly the same! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 18/06/16 13:01, Richard Rauch wrote: > We delete the build folders only, but not the .ecc file. > If rebuilding with GUI config tool (after build folders deleted) with same > .ecc file, the result is exactly the same! It ought to be - the same libcdl is called to regenerate the build tree if you use the same .ecc file. What I am saying is: File->New in the anoncvs configtool can generate a different configuration from the ecosconfig new <target> anoncvs command. -- Alex http://www.ecoscentric.com/ The eCos Experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
My application calls diag_printf() to display information to the debug console using serial port 0 of my processor. I would like to be able to implement some simple diagnostics that are initiated through the console port. Is it possible to accept input from the console? If so, how is this done? Michael -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> -----Original Message----- > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss- > owner@ecos.sourceware.org] On Behalf Of Michael W. Ellis > Sent: Thursday, June 30, 2016 9:54 AM > To: ecos-discuss@ecos.sourceware.org > Subject: [ECOS] Input from debug console > > My application calls diag_printf() to display information to the debug > console using serial port 0 of my processor. I would like to be able > to implement some simple diagnostics that are initiated through the > console port. Is it possible to accept input from the console? If so, > how is this done? Correction - I'm using the AT91SAM9260 processor and the debug console uses a serial port connected to the Debug Unit instead of serial port 0. The console device name is "/dev/ttydiag". Without writing new drivers, is it possible to get simple input from this port? Michael -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On Thu, Jun 30, 2016 at 11:02:53AM -0500, Michael W. Ellis wrote: > > -----Original Message----- > > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss- > > owner@ecos.sourceware.org] On Behalf Of Michael W. Ellis > > Sent: Thursday, June 30, 2016 9:54 AM > > To: ecos-discuss@ecos.sourceware.org > > Subject: [ECOS] Input from debug console > > > > My application calls diag_printf() to display information to the debug > > console using serial port 0 of my processor. I would like to be able > > to implement some simple diagnostics that are initiated through the > > console port. Is it possible to accept input from the console? If > so, > > how is this done? > > Correction - I'm using the AT91SAM9260 processor and the debug console > uses a serial port connected to the Debug Unit instead of serial port 0. > The console device name is "/dev/ttydiag". Without writing new drivers, > is it possible to get simple input from this port? > I read from /dev/dbgu on at91sam9363 using such code: cyg_io_handle_t serialH; err = cyg_io_lookup("/dev/dbgu", &serialH); cyg_io_read(serialH,...); -- /Evgeniy -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 2016-06-30, Michael W. Ellis <mellis@pesa.com> wrote: >> -----Original Message----- >> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss- >> owner@ecos.sourceware.org] On Behalf Of Michael W. Ellis >> Sent: Thursday, June 30, 2016 9:54 AM >> To: ecos-discuss@ecos.sourceware.org >> Subject: [ECOS] Input from debug console >> >> My application calls diag_printf() to display information to the debug >> console using serial port 0 of my processor. I would like to be able >> to implement some simple diagnostics that are initiated through the >> console port. Is it possible to accept input from the console? If > so, >> how is this done? > > Correction - I'm using the AT91SAM9260 processor and the debug console > uses a serial port connected to the Debug Unit instead of serial port 0. > The console device name is "/dev/ttydiag". Without writing new drivers, > is it possible to get simple input from this port? Does your eCos HAL profide hal_if_diag_read_char()? I thought that was pretty standard. I modified my HAL to also provide a non-blocking version of that call -- it only required writing a few lines of code. -- Grant -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss