Picon

Electric Imp

I would love to have a NuttX USB driver for this:  Electric Imp - WRL-11395 - SparkFun Electronics


Greg



__._,_.___
Posted by: spudarnia-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___
nuttx | 29 Jan 13:46 2015
Picon

New file uploaded to nuttx


Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the nuttx
group.

  File        : /sscanf.zip
  Uploaded by : spudarnia <spudarnia@...>
  Description : I have to change sscanf() from nuttx many times to improve formats
handling and to fix bugs. For now I wrote tests for test sscanf
functionality (for C89 and partially for C99) and now sscanf is passed
all tests (comparing with GNU libc implementation). But changes are too significant, and I have no time to
make reasonable
patch to lib_sscanf.c -- Kiril Frolov

You can access this file at the URL:
https://groups.yahoo.com/neo/groups/nuttx/files/sscanf.zip

To learn more about file sharing for your group, please visit:
https://help.yahoo.com/kb/index?page=content&y=PROD_GRPS&locale=en_US&id=SLN15398

Regards,

spudarnia <spudarnia@...>

------------------------------------

------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

Issues with fseek() and fclose() using FAT

Hello!

I experience a strange problem with seeking (possibly beyond file end, 
but not only) and writing. I'm not sure whether I'm doing everything 
correctly, but I just don't see anything wrong in what I do... I'd be 
grateful for any help or insight...

So there is a binary file which has 16 bytes of header and there is at 
least one data block, which has its size determined by one of the values 
in header. In each iteration I need to read the first data block (to do 
that I obviously also need to read the header) and write new data block 
at the end. The new data block has to be correctly positioned even if 
previous write did not finish successfully. So this is what I do:
1. I open the file twice with fopen() - once for reading with "r" and 
once for writing with "r+".
2. With the first instance I read the header (16 bytes) to get the size 
of data block.
3. I use the size of data block, size of header and size of file 
(obtained with fseek(..., SEEK_END); ftell(...)) to reposition the 
second instance of FILE (with fseek()) to a correct position, which may 
be past the end of file.
4. I read first 6 bytes from the first instance (that's the date and 
time of the block).
5. I write first 6 bytes to the second instance (as above - new date and 
time of the block).
6. I read a portion of data from the first instance which is used to 
obtain the same amount of data from another device, this portion of data 
is then written into the second instance of the FILE.
7. This process is repeated until the whole data block is read and the 
whole new data block is written. This loop can be terminated when there 
is some error in communication with the monitored device.
8. Both instances are closed with fclose().

Now this works perfectly fine as long as there is no error in the 
communication. However if the error is detected and files are closed 
prematurely, the data written to the second instance don't end up on the 
correct position, but somewhere else. This is hard to track, but I have 
a scenario in which it fails immediately - the written data (the first 6 
bytes that I write no matter what) end up ~1 data block earlier, which 
happens to be around the position that was previously read (not exactly, 
but really close). In this scenario fseek() does _NOT_ seek past the end 
of file, the new position is exactly at the end of file. In more 
realistic scenarios, the data is written a few blocks earlier, not 
necessarily at the position that was read just before, but that's the 
most common manifestation of the problem... The two instances I have are 
completely separate - I have two FILE structs, they both have different 
fd, I never attempt writing with the first one or reading with the 
second one and so on. Maybe the FAT implementation somehow shares the 
state when opening multiple files?

Any idea what could be the problem? If I open the second instance with 
fopen() and "a" flag, and just write zeros to adjust the end position 
instead of using fseek() then everything work fine too.

Thanks for any help!

Regards,
FCh

------------------------------------
Posted by: Freddie Chopin <freddie_chopin@...>
------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

ROS2 and NuttX



I stumbled across this video Intro to ROS2 embedded (the hold blog is here: OSRF Blog)

 

 

That's Victor Mayorales in the video.  Victor used be frequent this group often (and is still probably lurking out there).  Congratulations Victor!


Greg




__._,_.___
Posted by: spudarnia <at> yahoo.com



__,_._,___
Picon

How applications or examples entry point are mapped


I browsed the code and learn that CONFIG_USER_ENTRYPOINT in .config is mapped as the input function to a thread create in os_do_appstart(). 


Now in my config, CONFIG_USER_ENTRYPOINT=nsh_main.


If I change the user entry point to one of the examples in app, ( say mm) then won't I get the nsh prompt?


What I have already done?

# I am able to run as built in application. 

# I am able to run my code written as a task from within os_bringup.c.


What I want?

Basically, I want to build my application in examples/mycode directory and build along with nuttx and this should run as a separate task without modifying src files in nuttx directory.





__._,_.___
Posted by: benixvincent-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

Compile warning in uart_ioctl

Noticed this while working with ATMEGA:

serial/serial.c: In function 'uart_ioctl':

serial/serial.c:862:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

               *(int *)arg = count;

                ^

serial/serial.c:885:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

               *(int *)arg = count;

                ^


arg is unsigned long; count is int.

Don't think uart_ioctl is used anywhere...


__._,_.___
Posted by: jeditekunum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

ethernet work queue implementation

Hello,

I have started to implement work queues for stm32 (by copying over the
relevant parts from the tiva driver as Gregory suggested) and run into
an issue with a semaphore deadlock.

What seems to happen is that once the TCP connection stalls if nuttx
keeps receiving packets it will use up all the iob qentries in
g_iob_qpool. The next time a packet is received and
stm32_interrupt_process() calls iob_alloc() (through tcp_datahandler())
it will block. This does not happen if using interrupts because
iob_alloc() checks if it's called from an interrupt context and does not
block in that case. I added a hack so up_interrupt_context would return
true while inside stm32_interrupt_process() and that did seem to prevent
the deadlock (but still caused some packets to be lost).

TCP read ahead is enabled (as is standard on most configs).
We have the TCP receive window (and frame buffer size) set to 1500 and
IOB_NCHAINS is the default of 8. Increasing that delays the issue, but
does not solve it.

Could you try and reproduce this issue on the tiva? From what I read in
the code this issue should be present for all ethernet drivers using
work queues.

What I do to reproduce the issue is connect via telnet and spam nsh
with ps until the output stalls. Then check if the work task is waiting
on a semaphore. It should be waiting on &g_qentry_sem. When this happens
networking will not recover.

I attached the hack that I used as a reference.

Regards
Daniel

-- 
- Daniel Willmann <dwillmann@...>       http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

------------------------------------
Posted by: Daniel Willmann <dwillmann@...>
------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

[PATCH] stm32: rtc: fix building for STM32L15XX [1 Attachment]

<*>[Attachment(s) from Jussi Kivilinna included below]

Recent changes to stm32_rtcc.c do not compile with STM32L15XX configurations.

Signed-off-by: Jussi Kivilinna <jussi.kivilinna@...>
---
 nuttx/arch/arm/src/stm32/Kconfig      |    2 ++
 nuttx/arch/arm/src/stm32/stm32_rtcc.c |   16 ++++++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/nuttx/arch/arm/src/stm32/Kconfig b/nuttx/arch/arm/src/stm32/Kconfig
index c7c46b0..5dd9f29 100644
--- a/nuttx/arch/arm/src/stm32/Kconfig
+++ b/nuttx/arch/arm/src/stm32/Kconfig
 <at>  <at>  -3251,11 +3251,13  <at>  <at>  config RTC_LSECLOCK

 config RTC_LSICLOCK
 	bool "LSI clock"
+	depends on !STM32_STM32L15XX
 	---help---
 		Drive the RTC with the LSI clock

 config RTC_HSECLOCK
 	bool "HSE clock"
+	depends on !STM32_STM32L15XX
 	---help---
 		Drive the RTC with the HSE clock, divided down to 1MHz.

diff --git a/nuttx/arch/arm/src/stm32/stm32_rtcc.c b/nuttx/arch/arm/src/stm32/stm32_rtcc.c
index 817111d..bfafbb4 100644
--- a/nuttx/arch/arm/src/stm32/stm32_rtcc.c
+++ b/nuttx/arch/arm/src/stm32/stm32_rtcc.c
 <at>  <at>  -51,6 +51,8  <at>  <at> 

 #include "up_arch.h"

+#include "stm32_rcc.h"
+#include "stm32_pwr.h"
 #include "stm32_rtc.h"

 #ifdef CONFIG_RTC
 <at>  <at>  -77,6 +79,14  <at>  <at> 
 #  undef CONFIG_DEBUG_RTC
 #endif

+#ifdef CONFIG_STM32_STM32L15XX
+#  if defined(CONFIG_RTC_HSECLOCK)
+#    error "RTC with HSE clock not yet implemented for STM32L15XXX"
+#  elif defined(CONFIG_RTC_LSICLOCK)
+#    error "RTC with LSI clock not yet implemented for STM32L15XXX"
+#  endif
+#endif
+
 /* Constants ************************************************************************/

 #define SYNCHRO_TIMEOUT  (0x00020000)
 <at>  <at>  -435,6 +445,8  <at>  <at>  static int rtc_setup(void)
   uint32_t regval;
   int ret;

+#ifndef CONFIG_STM32_STM32L15XX
+
   /* We might be changing RTCSEL - to ensure such changes work, we must reset the
    * backup domain
    */
 <at>  <at>  -473,7 +485,11  <at>  <at>  static int rtc_setup(void)
   /* Enable the LSE clock */

   stm32_rcc_enablelse();
+#endif
+#else
+  /* Enable the LSE clock */

+  stm32_rcc_enablelse();
 #endif

   /* Wait for the RTC Time and Date registers to be synchronized with RTC APB

---
 nuttx/arch/arm/src/stm32/Kconfig      |    2 ++
 nuttx/arch/arm/src/stm32/stm32_rtcc.c |   16 ++++++++++++++++
 2 files changed, 18 insertions(+)

<*>Attachment(s) from Jussi Kivilinna:

<*> 1 of 1 File(s)
https://groups.yahoo.com/neo/groups/nuttx/attachments/253705348;_ylc=X3oDMTJya28zdWFoBF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDYXR0YWNobWVudARzbGsDdmlld09uV2ViBHN0aW1lAzE0MjIzNzEwOTQ- 
  <*> stm32-rtc-fix-building-for.patch

------------------------------------
Posted by: Jussi Kivilinna <jussi.kivilinna@...>
------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

[PATCH] stm32_exti_gpio: fix disabling IRQ for EXTI lines with shared IRQ handler [1 Attachment]

<*>[Attachment(s) from Jussi Kivilinna included below]

Disabling any of EXTI 5-9 interrupts was disabling interrupts for all EXTI 5-9. Same issue with EXTI 10-15.

Signed-off-by: Jussi Kivilinna <jussi.kivilinna@...>
---
 nuttx/arch/arm/src/stm32/stm32_exti_gpio.c |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/nuttx/arch/arm/src/stm32/stm32_exti_gpio.c b/nuttx/arch/arm/src/stm32/stm32_exti_gpio.c
index f897691..b445798 100644
--- a/nuttx/arch/arm/src/stm32/stm32_exti_gpio.c
+++ b/nuttx/arch/arm/src/stm32/stm32_exti_gpio.c
 <at>  <at>  -245,12 +245,17  <at>  <at>  xcpt_t stm32_gpiosetevent(uint32_t pinset, bool risingedge, bool fallingedge,
   int      irq;
   xcpt_t   handler;
   xcpt_t   oldhandler = NULL;
+  int      nshared;
+  xcpt_t   *shared_cbs;
+  int      i;

   /* Select the interrupt handler for this EXTI pin */

   if (pin < 5)
     {
       irq = pin + STM32_IRQ_EXTI0;
+      nshared = 1;
+      shared_cbs = &stm32_exti_callbacks[pin];
       switch (pin)
         {
           case 0:
 <at>  <at>  -278,11 +283,15  <at>  <at>  xcpt_t stm32_gpiosetevent(uint32_t pinset, bool risingedge, bool fallingedge,
     {
       irq     = STM32_IRQ_EXTI95;
       handler = stm32_exti95_isr;
+      shared_cbs = &stm32_exti_callbacks[5];
+      nshared = 5;
     }
   else
     {
       irq     = STM32_IRQ_EXTI1510;
       handler = stm32_exti1510_isr;
+      shared_cbs = &stm32_exti_callbacks[10];
+      nshared = 6;
     }

   /* Get the previous GPIO IRQ handler; Save the new IRQ handler. */
 <at>  <at>  -299,7 +308,19  <at>  <at>  xcpt_t stm32_gpiosetevent(uint32_t pinset, bool risingedge, bool fallingedge,
     }
   else
     {
-      up_disable_irq(irq);
+      /* Only disable IRQ if shared handler does not have any active
+       * callbacks. */
+
+      for (i = 0; i < nshared; i++)
+        {
+          if (shared_cbs[i] != NULL)
+            break;
+        }
+
+      if (i == nshared)
+        {
+          up_disable_irq(irq);
+        }
     }

   /* Configure GPIO, enable EXTI line enabled if event or interrupt is

---
 nuttx/arch/arm/src/stm32/stm32_exti_gpio.c |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

<*>Attachment(s) from Jussi Kivilinna:

<*> 1 of 1 File(s)
https://groups.yahoo.com/neo/groups/nuttx/attachments/454153171;_ylc=X3oDMTJyMmM5OGdjBF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDYXR0YWNobWVudARzbGsDdmlld09uV2ViBHN0aW1lAzE0MjIzNzEwNTc- 
  <*> stm32_exti_gpio-fix-disabling.patch

------------------------------------
Posted by: Jussi Kivilinna <jussi.kivilinna@...>
------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

Help with ATMEGA1284P bring up

I've got an ATMEGA1284P (128KB/16KB) Moteino MEGA board that I'm trying to bring up.  (config moteino-mega)  I've used amber and teensy as a start.

My changes are at u/jeditekunum / NuttX - GIT / [57ae5f].  I've gotten past the assert/panic I had at first after fixing the interrupt vectors.

I'm now to the point where I'm looking for a prompt from nsh :) and not seeing anything - on either USART0 or USART1.  From what I can tell so far, using a LED other than the board LED, its getting pretty far; maybe I'm still missing interrupts.

As I'm new to NuttX it would be helpful if someone more familiar with NuttX and maybe the current AVR support could take a quick peek to see if I'm missing something obvious.

Thanks



__._,_.___
Posted by: jeditekunum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

Patches to add some more math library functions [3 Attachments]

<*>[Attachment(s) from Brennan Ashton included below]

I have attached some patches that should add support for inverse
hyperbolic trig functions, isfinite, and error function.

I have not run very many tests on the values, but they look correct to
me.  Next I will be sending some patches for gamma functions, but
those are a little more tricky.

After I have tgammaf and lgammaf micropython should build with math support.

--Brennan

<*>Attachment(s) from Brennan Ashton:

<*> 3 of 3 File(s)
https://groups.yahoo.com/neo/groups/nuttx/attachments/421584928;_ylc=X3oDMTJydjdubTBqBF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDYXR0YWNobWVudARzbGsDdmlld09uV2ViBHN0aW1lAzE0MjIyOTk3MTE- 
  <*> 0001-Add-support-for-inverse-hyperbolic-functions.patch
  <*> 0002-Add-math-library-definition-for-isfinite.patch
  <*> 0003-Add-error-function-to-math-library.patch

------------------------------------
Posted by: Brennan Ashton <bashton@...>
------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/


Gmane