Re: Bluetooth+WiFi+NuttX
I tried some Wifi and Bluetooth but know that some MCUs cannot handle them very well at the same time. Op za 29 okt. 2022 1:20 a.m. schreef Alan C. Assis : > Hi Tim, > > On 10/28/22, Tim Hardisty wrote: > > Bit of a tangential question this, but I know there are folk on here who > > are much more conversant with the way NuttX can be used with WiFi and > > Bluetooth modules than I am. > > > > I think these are important questions and other people could face > similar issues in the future. > > > I may have an opportunity forced on me to have to respin my custom board > > which currently has a SiLabs Bluetooth SoC as well as the main SAMA5D2 > > processor. I used that module as I already have experience of it - but > that > > predates my NuttX journey. > > > > I see there are some very good value combined WiFi + Bluetooth modules > now > > (Espressif for example...and I know there's a well-known proponent of > those > > devices here lol) and, having seen a few other questions here, I am > thinking > > that I can go the HCI route and make use of the Bluetooth Stack in NuttX: > > and add WiFi capability to my board at the same time. Winner! > > > > First let me explain the differences: > > Espressif modules are not used as external modules on NuttX, > everything is integrated inside the chip. > > During the WildernessLab's presentation on NuttX Workshop their team > shown an ESP32 solution sharing WiFi as an external module. > But they didn't use the default USRSOCK route, they implemented a new > solution at home. > > > I'm hoping I can program up a suitable module with generic radio > > co-processor software (HCI I think, and whatever is needed for WiFi) and > > access it via UART from my main processor and have it all under the NuttX > > system in a much more easily managed manner than a separate app on the > > SiLabs SoC that just happens to communicate on some way with my main app > on > > the SAMA5D2. > > > > Have I got this right? Is an Espressif module a good choice (email me > direct > > if you want to !!)? > > > > For Bluetooth (BLE) if there is a HCI firmware to SiLabs chip, then it > could be possible to you use it, but you'll need to do some tests and > debugging to get things working. > > For WiFi things are more complex because you need to implement a > USRSOCK yourself to the chip. > > I never tested others possibilities: i.e. share Internet using SLIP > between ESP32 and SAMA5D2, should be an easier route if it works, but > of course you wil be limited to UART speed. > > Ethernet could be a better option (since ESP32 has Ethernet hardware), > but it seems like an ugly and expensive workaround. > > BR, > > Alan >
Re: Which control version software are you using? //was Re: Poll: Which OS are you using to compile NuttX?
Git and Linux Op za 25 sep. 2021 12:58 a.m. schreef Alan Carvalho de Assis < acas...@gmail.com>: > Hi David, > > Nice you hear from you. > > I'm also using git: #1 > > BR, > > Alan > > On 9/24/21, David S. Alessio wrote: > > Hi, Alan, > > > > It’d be good to know how developers are managing their code: > > 1) git > > 2) mercurial > > 3) SVN > > 4) zip files on floppies > > 5) none > > > > My money is on #1 ;) > > > > Cheers, > > -david > > > >> On Sep 24, 2021, at 2:07 PM, Alan Carvalho de Assis > >> wrote: > >> > >> Hi Flávio, > >> > >> That is good idea, but I think we need to have some kind of maintainers. > >> > >> It is hard when someone adds some strange OS and the go out and leave > >> it to other developers to maintain it. > >> > >> Do you want to mainline some host OS? :-P > >> > >> BR, > >> > >> Alan > >> > >> On 9/24/21, Flavio Castro Alves Filho wrote: > >>> Alan, > >>> > >>> How about a poll asking "which other OS would you like to build NuttX?" > >>> :-P > >>> > >>> Best regards, > >>> > >>> Flavio > >>> > >>> Em sex., 24 de set. de 2021 às 17:45, Tim Hardisty > >>> escreveu: > > Linux > > > > On 24/09/2021, 21:07, "Alan Carvalho de Assis" > wrote: > > Sorry guys, I suppose you are using LinkedIn too. > > Yes, probably it will collect some data from you, but you are using > a > better MS gather: > > "Sent from Mail for Windows" > > So, if you are already in the hell, please give a warm hug in the > Lucifer :-D > > Now, let be serious here: for those who don't have LinkedIn access, > please reply this email with one of these options: > > 1) Linux > 2) MacOS > 3) Windows using Cygwin > 4) Windows Native > > Thank you for the understanding. > > BR, > > Alan > > On 9/24/21, Russell Haley wrote: > > The link gives me “This post cannot be displayed”. I am logged into > the > > Microsoft data collection site known as LinkedIn. > > > > Sent from Mail for Windows > > > > From: Tim Hardisty > > Sent: Friday, September 24, 2021 12:54 PM > > To: dev@nuttx.apache.org > > Subject: Re: Poll: Which OS are you using to compile NuttX? > > > > Needs a LinkedIn login? > > > > > > > > From: Alan Carvalho de Assis > > Reply to: "dev@nuttx.apache.org" > > Date: Friday, 24 September 2021 at 20:20 > > To: dev > > Subject: Poll: Which OS are you using to compile NuttX? > > > > Hi Everyone, Please help us to discover which OS people are using > most to > > compile NuttX: > > > > https://www.linkedin.com/feed/update/urn:li:activity:6847246067046596609/ > It > > will help us to decide how better support your host OS. BR, Alan > > > > > > > >>> > >>> > >>> -- > >>> Flavio de Castro Alves Filho > >>> > >>> flavio.al...@gmail.com > >>> Twitter: http://twitter.com/#!/fraviofii > >>> LinkedIn profile: www.linkedin.com/in/flaviocastroalves > >>> > > > > >
Re: Please submit your proposal to the NuttX Online Workshop before July 16
I want to bring in MultiWii/MSP for NuttX. Ben Op zo 20 jun. 2021 7:36 p.m. schreef Alan Carvalho de Assis < acas...@gmail.com>: > Hi NuttXers, > > The Nuttx Online Workshop's Call for Presentations is open: > > https://nuttx.events/call-for-participation-2021/ > > If you want to talk about some NuttX features or just want to talk > about some project developed with NuttX or show a demo, that is your > opportunity. > > BR, > > Alan >
Re: Dev environment
You can also use Virtualbox. I use this for my NuttX CI/CD. Works nice! Ben > >
Re: Dev environment
Tim. Maybe I can try to help you concerning this matter. How can we connect? Do you have telegram? Op di 11 mei 2021 6:42 p.m. schreef Tim : > Pulling my hair out here!! So apologies for the lengthy brain dump and plea > for help! > > > > All this starts from the CAN init code crashing (SAMA5D27) when it makes > any > call to print debug messages. Printf itself is fine. > > > > I need to debug it. I will need to get to that point regardless. > > > > The only way I can actually get Nuttx to build is using WSL - compiles no > problem at all. I have a MAC - it won't compile without errors and there's > not enough info (for me) to see what the error is - some complaint about > ./builtin_list.c > > > > Mac is the machine I know least. I have no "full" Linux machine. No > experience of Cygwin and its ilk - just a minefield to me. > > > > I know Windows best, and have successfully used eclipse under Windows for > Arm development for many years (sometimes compiling within eclipse, > sometimes from a command prompt). But although I can download and run code > via my jlink, eclipse will not correctly index the source code so I cannot > debug or set breakpoints. > > > > So I went back to trying to get it to compile under the Mac but no joy so > not even got as far as seeing if eclipse - or any other debugger- will run > and do its job. Eclipse is pointing at the source code properly and even if > I stop the program and manually point the eclipse debugger to the source > code - where I have inserted a while(1); - it completely refuses to pick up > the source code. I am suspected a "\" vs "/" issue or something dumb. This > is true either for a project pointing to a clone in the WSL location or in > a > more native windows location > > > > I have not succeeded in getting Nuttx to build via eclipse (in Windows) > either - although my "Bare Metal" SAMA5 code compiles just fine with the > eclipse GNU cross compilers and debugs nicely. > > > > I thought maybe I could run an X-windows emulator on my Win 10 machine and > run eclipse on WSL...but it doesn't get very far and just throws errors. > > > > Thought I'd try Visual GDB - no SAMA5D2 support it seems. Tried to run > OpenOCD (which purported to be "Windows ready") but it doesn't run. > > > > Has anyone got NuttX to successfully compile, and allow debug, under either > MAC or Windows. At all? Ever? > > > > If someone has any pointers I will be extremely grateful, as this is doing > my head in. I really don't want to waste yet more days finding a machine to > build up exclusively for Linux unless I REALLY have to!!! > >
Re: CAN example crashes
I use the CAN solution from NuttX with the SPI MCP2515. Made my own referenceboard for it. Is doing miliions of messages with multiple nodes. Works like a charm! Ben Op za 8 mei 2021 6:30 p.m. schreef murat tologlu : > Thanks for all the answers. I look forward to try Alan's next tutorial :) > BR, > > On 2021/05/08 16:24:51, Tim Hardisty wrote: > > >> Is there any description somewhere about this example ? > > >> > > >There is some in apps/examples/README.md, but not a lot of info. > > > > Not much, no, but the example code is pretty self-explanatory! > > > > > > >
Re: [OT] Realtime Control Systems using pysimCoder and NuttX
Sweet! Op ma 22 feb. 2021 2:46 p.m. schreef Alan Carvalho de Assis < acas...@gmail.com>: > Hi NuttXers, > > Mr. Roberto Bucher integrated NuttX on his pysimCoder: > > Part1: https://lnkd.in/dKn8tFN > Part2: https://lnkd.in/dW266HV > Part3: https://lnkd.in/dJ6r_mb > Part4: https://lnkd.in/dYXMfg3 > > How it is easy to create control systems using block diagram like > those used on Matlab. > > BR, > > Alan >
Re: about IDEs and dev boards
Try my blog http://nuttx.nl (english) or I can help you set it up. Hope this will get you going! Op do 10 dec. 2020 2:30 a.m. schreef Marlar Chan : > Dear Ben, >Is there any setup guideline for Nuttx debuggig with VSCode (normal > use) and Eclipse (Hard faults)? > > Best Regards, > Marlar > ____ > From: Disruptive Solutions > Sent: Wednesday, December 9, 2020 6:16 PM > To: dev@nuttx.apache.org > Subject: Re: about IDEs and dev boards > > VSCode (normal use) and Eclipse (Hard faults). > > STM32 stack (nucleos, blackboards, etc) and own reference board(s). > > Hardware as extra tools (logic analyzer, scope, seggers, st link, etc) > > And just having fun to use NuttX and the results one can achieve. Still > mind blowing!!! > > Ben > > Op wo 9 dec. 2020 8:39 a.m. schreef Marc Rosen : > > > > > Am 04.12.2020 um 02:54 schrieb Matias N.: > > > Hi, > > > I was wondering what IDEs do you use with NuttX and what is your > > preferred dev board (can be more than one). > > > I'm curious since I have used QtCreator for long time now and generally > > works well, but it has some quirks. > > Jetbrains CLion is the IDE i use. It is not that great with Makefile > > projects and debugging but it is getting better. > > And it works well if you also use some of their other dev tools and ides. > > > And on hardware side I always favored STM32 boards (with embedded > > debugger) but after getting into nRF52 I found > > > it to be much easier to work with and seems a very well designed SoC > > from the users perspective. The "mux (almost) any peripheral to any pin" > is > > great (any other chip does that?). > > > > > > Best, > > > Matias > > Mostly AVRs here, the ones too small for Nuttx, and STM32. Usually > > custom boards. > > > > regards, > > Marc > > > > > > > CONFIDENTIALITY: This email is intended solely for the person(s) named and > may be confidential and/or privileged. If you are not the intended > recipient, please delete it, notify us and do not copy, use, or disclose > its contents. > Towards a sustainable earth: Print only when necessary. Thank you. >
Re: about IDEs and dev boards
VSCode (normal use) and Eclipse (Hard faults). STM32 stack (nucleos, blackboards, etc) and own reference board(s). Hardware as extra tools (logic analyzer, scope, seggers, st link, etc) And just having fun to use NuttX and the results one can achieve. Still mind blowing!!! Ben Op wo 9 dec. 2020 8:39 a.m. schreef Marc Rosen : > > Am 04.12.2020 um 02:54 schrieb Matias N.: > > Hi, > > I was wondering what IDEs do you use with NuttX and what is your > preferred dev board (can be more than one). > > I'm curious since I have used QtCreator for long time now and generally > works well, but it has some quirks. > Jetbrains CLion is the IDE i use. It is not that great with Makefile > projects and debugging but it is getting better. > And it works well if you also use some of their other dev tools and ides. > > And on hardware side I always favored STM32 boards (with embedded > debugger) but after getting into nRF52 I found > > it to be much easier to work with and seems a very well designed SoC > from the users perspective. The "mux (almost) any peripheral to any pin" is > great (any other chip does that?). > > > > Best, > > Matias > Mostly AVRs here, the ones too small for Nuttx, and STM32. Usually > custom boards. > > regards, > Marc > >
Re: [ANNOUNCE] Apache NuttX 10.0.0-incubating released
Nice! Op zo 6 dec. 2020 10:15 p.m. schreef Brennan Ashton : > The Apache NuttX (incubating) project team is proud to announce > Apache NuttX 10.0.0-incubating has been released. > > The release artifacts and Release Notes can be found at: > https://nuttx.apache.org/download/ > https://nuttx.apache.org/releases/10.0.0/ > > This release has been a long time coming and I think is on of the most > tested releases since joining the Apache Incubator. > There is a breaking change for watchdog callbacks that people should be > aware of if they have out of tree drivers that consume the interface. > See: > https://nuttx.apache.org/releases/10.0.0/#watchdog-callback-argument-change > > Thanks, > Brennan Ashton > on behalf of Apache NuttX PPMC >
Re: ssd1306 oled help
Did you try the i2c tool?
Op za 5 dec. 2020 1:58 a.m. schreef Matt DeWall :
> Got it. Ok - looks like my 116 errors were from my later experimenting.
> If I completely disconnect or try other i2c pins, I get 116, so that makes
> sense.
>
> So it looks like when I connect the pins correctly I'm getting the 6 error.
>
> I'm wondering if that just means somehow my device has an i2c address that
> isn't the default that the driver is looking for?
>
> Mat
>
> On Fri, Dec 4, 2020 at 4:25 PM Gregory Nutt wrote:
>
> > Should have mentioned that the error code 6 is defined in
> include/errno.h:
> >
> > #define ENXIO 6
> > #define ENXIO_STR "No such device or address"
> >
> > And errcode code 116 is:
> >
> > #define ETIMEDOUT 116
> > #define ETIMEDOUT_STR "Connection timed out"
> >
> > Which is also reported by as an I2C failure by stm32_i2c_transfer():
> >
> >if (stm32_i2c_sem_waitdone(priv) < 0)
> > {
> >status = stm32_i2c_getstatus(priv);
> >ret = -ETIMEDOUT;
> >
> > On 12/4/2020 6:19 PM, Gregory Nutt wrote:
> > >
> > > As far as I can tell, this looks like an I2C problem. Alan problem
> > > knows better than I.
> > >
> > > I think the failure sequence is:
> > >
> > > fs/vfs:
> > > ioctl(FBIO_UPDATE)
> > >
> > > drivers/video/fb.c ioctl method:
> > > ret = fb->vtable->updatearea(fb->vtable, area);
> > >
> > > drivers/lcd/lcd_framebuffer.c, function lcdfb_updateearea():
> > > ret = pinfo->putrun(row, startx, run, width);
> > >
> > > drivers/lcd/ssd1306.c, putrun method:
> > > Calls ssd1306_sendbyte()
> > >
> > > arch/arm/src/stm32/stm32_i2c.c,
> > > else if (status & I2C_SR1_AF)
> > > {
> > > /* Acknowledge Failure */
> > >
> > > ret = -ENXIO;
> > > }
> > >
> > > So my best guess is that there is some issue with your I2C interface.
> > > It might be failing to acknowledge.
> > >
> > > On 12/4/2020 4:56 PM, Matt DeWall wrote:
> > >> Hello NuttX devs!
> > >>
> > >> I've followed Alan's great tutorial on setting up an OLED on the Blue
> > Pill
> > >> stm32f103-minimum board but running into trouble.
> > >>
> > >> Video:
> > >> https://www.youtube.com/watch?v=TZ4i71ArtRo=245s
> > >>
> > >> * I've compiled, flashed, and able to get into nsh
> > >> * The fb driver is listed as /dev/fb0 and the 'fb' app is present
> > >> * When I run the 'fb' app I get repetitive errors, two different
> codes,
> > but
> > >> usually '6' (sometimes '116')
> > >>
> > >> --
> > >> nsh> fb
> > >> VideoInfo:
> > >>fmt: 0
> > >> xres: 128
> > >> yres: 64
> > >>nplanes: 1
> > >> PlaneInfo (plane 0):
> > >> fbmem: 0x20002f40
> > >> fblen: 1024
> > >> stride: 16
> > >>display: 0
> > >>bpp: 1
> > >> Mapped FB: 0x20002f40
> > >> 0: ( 0, 0) (128, 64)
> > >> ERROR: ioctl(FBIO_UPDATE) failed: 6
> > >> 1: ( 11, 5) (106, 54)
> > >> ERROR: ioctl(FBIO_UPDATE) failed: 6
> > >> 2: ( 22, 10) ( 84, 44)
> > >> ERROR: ioctl(FBIO_UPDATE) failed: 6
> > >> 3: ( 33, 15) ( 62, 34)
> > >> ERROR: ioctl(FBIO_UPDATE) failed: 6
> > >> 4: ( 44, 20) ( 40, 24)
> > >> ERROR: ioctl(FBIO_UPDATE) failed: 6
> > >> 5: ( 55, 25) ( 18, 14)
> > >> ERROR: ioctl(FBIO_UPDATE) failed: 6
> > >> Test finished
> > >>
> > >>
> > >> * I have verified that the screen is working and wired up correctly
> > using
> > >> an Arduino Mega.
> > >> * I'm using this ssd1306 HiLet Go 128X64 OLED:
> > >>
> >
> https://www.amazon.com/gp/product/B06XRBTBTB/ref=ppx_yo_dt_b_asin_title_o02_s01?ie=UTF8=1
> > >> * AFAIK I've done an apples/apples with the tutorial, same board, same
> > >> screen, same wiring, but no luck.
> > >>
> > >> I'm at a loss, as debugging at this low of a level is pretty foreign
> to
> > >> me. It feels like I've missed something easy, but I've triple checked
> > the
> > >> connections and config and not sure where to go from here.
> > >>
> > >> Thanks!
> > >>
> > >> Matt
> > >>
> >
>
Re: Build problems - nuttx as an external library
Was this not included in the build tests? Op ma 16 nov. 2020 8:25 p.m. schreef Alan Carvalho de Assis < acas...@gmail.com>: > Hi Flávio, > > A simple band-aid fix: add this typedef inside > "arch/chip/stm32_gpio.h" just before it is called at > stm32_gpiosetevent(): > > typedef CODE int (*xcpt_t)(int irq, FAR void *context, FAR void *arg); > > int stm32_gpiosetevent(uint32_t pinset, bool risingedge, bool fallingedge, >bool event, xcpt_t func, void *arg); > > We need investigate which patch broke the "make export" and fix it. > > BR, > > Alan > > On 11/16/20, Flavio Castro Alves Filho wrote: > > Hello, > > > > I intend to build a nuttx application using the operating system as an > > external library. > > > > I am working on a custom board running stm32f417 and I am following > > the instructions from the following link: > > > https://acassis.wordpress.com/2020/06/28/using-nuttx-as-library-once-again/ > > > > For the first compilation, I am having the following compilation error: > > > > ubuntu@pc-ubuntu:~/Documents/nuttx/hello/nuttx-export-9.1.0$ > > arm-none-eabi-gcc -c -fno-builtin -Wall -Wstrict-prototypes -Wshadow > > -Wundef -g -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -I. -isystem > > ./include -pipe -I "./include" -I "./arch/chip" hello.c -o hello.o > > In file included from ./arch/chip/hardware/stm32f40xxx_pinmap.h:48:0, > > from ./arch/chip/hardware/stm32_pinmap.h:133, > > from ./arch/chip/chip.h:59, > > from ./include/arch/armv7-m/nvicpri.h:28, > > from ./include/arch/armv7-m/irq.h:37, > > from ./include/arch/irq.h:49, > > from ./include/nuttx/irq.h:53, > > from ./include/nuttx/sched.h:40, > > from ./include/sched.h:34, > > from ./include/stdio.h:48, > > from hello.c:1: > > ./arch/chip/stm32_gpio.h:538:36: error: unknown type name 'xcpt_t' > > bool event, xcpt_t func, void *arg); > > ^~ > > > > Could you give some advice on how to address this issue? > > > > Best regards, > > > > Flavio > > > > -- > > Flavio de Castro Alves Filho > > > > flavio.al...@gmail.com > > Twitter: http://twitter.com/#!/fraviofii > > LinkedIn profile: www.linkedin.com/in/flaviocastroalves > > >
Multiwii MSP
Me and a mate are trying to implement the MSP protocol in NuttX so we can also bring it back to the community. Maybe its allready done, but we could not find it. We really love the way one could configure your solution and flash it through dfu. Just like betaflight does. We will try (in the hecktic in our lives working) to implement this asap. Ben (& Edwin)
Re: [OT] Support to Sparkfun MicroMod
The first link gives a 404. The concept of modularity is nice, but it looks like "just another board". Its more the choice off a mcu family and needed criteria for your solution thats interesting. Like for e.g. the MCU finder from STM32 and MAPS from Microchip. Most of the solutions have a durable purpose and you make hardware in a design process. The flexibility is in releasing the MCU potentiontial in its functions and overthinking which functionalities one needs... With the need criteria in performance and other non functionals.. > >
Re: NuttX and continuous ADC conversion
Fixed it (workaround) by opening and closing ADC device. Then the FIFO cleans. It rather fast and performance is good enough for its purpose. Op wo 21 okt. 2020 9:33 p.m. schreef : > Nice.. I just want to use the ADC as feedback sensor for a plunger... I > all works fine until the FIFO is full > > -Oorspronkelijk bericht- > Van: Daniel Pereira Carvalho > Verzonden: woensdag 21 oktober 2020 21:01 > Aan: dev@nuttx.apache.org > Onderwerp: Re: NuttX and continuous ADC conversion > > Maybe you could propose a modification on ADC upper-half driver to enable > overwriting. So, if the FIFO is full the oldest value is replaced by the > new one. This could be an option on the config system. > > At this moment I am working on STM32L4 ADC driver. I am implementing the > low level operations, based on STM32 ADC driver. Using low level operations > you don't need to use the upper-half. > > Daniel Pereira de Carvalho > > > Em qua., 21 de out. de 2020 às 15:48, > escreveu: > > > I have implemented a daemon which uses sigaction. And indeed the ADC > > works with this solution until the FIFO is full... Maybe I have to add > > an IOCT that resets the ADC?... Or set the FIFO buffer back? Or make a > > ringbuffer instead of FIFO > > > > Ben > > > > -Oorspronkelijk bericht- > > Van: Nathan Hartman > > Verzonden: woensdag 21 oktober 2020 20:36 > > Aan: dev@nuttx.apache.org > > Onderwerp: Re: NuttX and continuous ADC conversion > > > > On Wed, Oct 21, 2020 at 2:26 PM wrote: > > > > > Thats correct... so I have to start the conversion every time over > > > again... and het the value after that conversion I have seen > > > continuous conversions ADC on an STM32... > > > > > > I will try to find a plausible solution. > > > > > > > Zero latency ISR to read ADC register into memory buffer? > > > > > >
Re: Say I do not want to use a board but a standalone MCU say the STM32F722RET6
Awesome, thanks! Op za 26 sep. 2020 10:31 p.m. schreef Bob Feretich < bob.feret...@rafresearch.com>: > Nuttx already supports the STM32F722RET6.� The configuration controls > can be found at > > https://github.com/apache/incubator-nuttx/tree/master/boards/arm/stm32f7/nucleo-144/configs/f722-nsh > > That chip family was tested using the Nucleo-144 development board, which > has the STM32F722ZE (144-pin version of that chip) mounted on it. > > To configure for the STM32F722RE MCU, change the defconfig file replacing: > CONFIG_ARCH_CHIP_STM32F722ZE=y > with > CONFIG_ARCH_CHIP_STM32F722RE=y > > You then need to examine the other files in the� > incubator-nuttx/boards/arm/stm32f7/nucleo-144/ > subtree and modifying whatever is needed to account for any differences > between your board and the Nucleo-144. > > Regards, > Bob > > > On 9/26/2020 12:32 AM, disruptivesolution...@gmail.com wrote: > > NuttX speaks of "boards" and not about MCUs. Maybe a dumb question, but does > NuttX run on custom made PCB's where one uses the MCU named in "boards"? Or > is there something with a bootloader or something? With DFU I can push > nuttx.bin right (if the mcu supports it). > > > > Is there some wish to add the STM32F722RET6? And could one make one in > NuttX based on a F7 already? > > > > Thanks in advance > > Ben > > > > >
Re: NuttX Online Workshop
Ah oke. 14:00 Amsterdam time Op za 15 aug. 2020 11:13 schreef Alan Carvalho de Assis : > Hi Ben, > > The YouTube link will be announce at https://nuttx.events/ at 12:00 GMT > > BR, > > Alan > > On 8/15/20, disruptivesolution...@gmail.com > wrote: > > And will there be a Zoom link? Or did I miss some info? > > > > Ben > > > > -Oorspronkelijk bericht- > > Van: Schock, Johannes - NIVUS GmbH > > Verzonden: zaterdag 15 augustus 2020 10:33 > > Aan: 'dev@nuttx.apache.org' > > Onderwerp: NuttX Online Workshop > > > > Just a hint: > > If I'm correct, https://nuttx.events/ is broken at the moment: > > There's no link to register for N.O.W. (or is registration closed?) and > the > > countdown is only showing some html garbage. > > > > JOhannes > > > > > > > > >
Re: stm32f7 CAN driver
Oleg do you mean the SPI version (mcp) or native with a say tja1050? The SPI version I use on different platforms. The stm32f7 I have to try though... Ben Op di 21 jul. 2020 23:06 schreef Oleg Evseev : > Hi all, > > Did anybody use the NuttX CAN driver with stm32f7 mcu? Does it work ok? > > --- > With regards, Oleg. >
Millis() equivalent
Is there a millis() equivalent? Where the system timer (milliseconds) is kept solid in the back? Where you can obtain "passed system time"... without delay interventions from threads etc?
Re: NuttX config browser
See also http://nuttx.nl. I am using it for a long time already. Just know that, when you want to debug for a hardvault, you still need Eclipse. So it seems. Have fun with it. Ben
Re: From 8.2 to 9.x??
I scanned through the wiki off 9.1 and could it be I am missing "tools" as a package which is used in previous releases? Maybe it is best, as a dev/user, I just have to try and clone the 9.1 branch (apps and nuttx) and see if my apps and drivers (which have some fixes in 8.2) are working and that I can still build and configure Nuttx like I was used to do. And that my board and apps are still working. Op do 2 jul. 2020 01:51 schreef Brennan Ashton : > In addition to what Anthony said I would recommend trying to base your > port off of the > releases/9.1 branch, there is an RC1 release right now that I would > expect to be the next release or very close to it. > > --Brennan > > On Wed, Jul 1, 2020 at 4:46 PM Anthony Merlino > wrote: > > > > > > > > I just went through this with my codebase. All in all, it hasn't been > too > > > bad. > > > > > > I shouldn't have said that. All in all, it has been a breeze. Sure a few > > minor snags, but that's unavoidable. > > > > I have been waiting for the dust to settle down... > > > > > > > I really should be giving a big thank you to those who have been kicking > up > > the proverbially dust in the first place. Things are looking good! > > > > > > On Wed, Jul 1, 2020 at 7:40 PM Anthony Merlino > > wrote: > > > > > Ben, > > > > > > I just went through this with my codebase. All in all, it hasn't been > too > > > bad. > > > > > > I think most of your answers can be found: > > > > > > here for 9.0 > > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.0 > > > and here for 9.1 > > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1 > > > > > > I'll point out a few of the issues I hit: > > > > > > I had problems with not having any heap allocated because of this > change: > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-RenameEXTRADEFINEStoEXTRAFLAGS > > > > > > > > > I also was using the set command inside of a script that I was running > > > using the sh command. > > > As Greg pointed out for me: > > > > > > The sh command now behaves like the bash 'sh' command... it does modify > > >> the environment of the caller. The old behavior of 'sh' is now called > > >> 'source'. So this should work: > > >> > > >> echo "set TEST hello" >> /mnt/sdcard0/env.nsh > > >> source /mnt/sdcard0/env.nsh > > >> > > >> sh and source now conform to OpenGroup.org standards. > > >> > > > > > > > > > Hope this helps and best of luck. > > > > > > > > > On Wed, Jul 1, 2020 at 7:25 PM Disruptive Solutions < > > > disruptivesolution...@gmail.com> wrote: > > > > > >> I have been waiting for the dust to settle down... I am still using > 8.2 > > >> (BSD). Is it ready to go and migratie to a 9.x version? Is this still > the > > >> incubator Github? Are there "user changes" which I have to know? Make > > >> menuconfig still works? Are drivers ported and tested? Can I migratie > > >> easily? Etc etc > > >> > > >> Thanks > > >> Ben > > >> > > > >
From 8.2 to 9.x??
I have been waiting for the dust to settle down... I am still using 8.2 (BSD). Is it ready to go and migratie to a 9.x version? Is this still the incubator Github? Are there "user changes" which I have to know? Make menuconfig still works? Are drivers ported and tested? Can I migratie easily? Etc etc Thanks Ben
Re: Tutorial: Using NuttX as library
Nice! Op ma 29 jun. 2020 14:12 schreef Alan Carvalho de Assis : > Hi Everyone, > > I updated my tutorial about using NuttX as a library, very useful when > you want to use an IDE or create a simple Makefile to compile your > application, I hope it could be useful: > > https://acassis.wordpress.com/2020/06/28/using-nuttx-as-library-once-again/ > > BR, > > Alan >
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
+1 Op wo 24 jun. 2020 02:40 schreef Brennan Ashton : > On Tue, Jun 23, 2020 at 5:36 PM Brennan Ashton > wrote: > > > > On Tue, Jun 23, 2020 at 5:35 PM Brennan Ashton > > wrote: > > > > > > On Tue, Jun 23, 2020 at 5:31 PM Justin Mclean < > jus...@classsoftware.com> wrote: > > > > > > > > Hi, > > > > > > > > I’ve not done a full check (which I will do) but I would be -1 on > this release as it looks like it’s been signed with an expired key: > > > > > > > > gpg: Good signature from "Brennan Ashton " > [expired] > > > > gpg: Note: This key has expired! > > > > > > > > It's also a good idea to sign with an “@apache.org” email address. > > > This key is not expired and has been signed by my apache.org email > > > address as well: > > > > https://keyserver.ubuntu.com/pks/lookup?search=0x3554D78458CEB6954B020E12E1B6E30DB05D6280=on=index > > > This is also indicated here: > > > https://dist.apache.org/repos/dist/release/incubator/nuttx/KEYS > > > > > > --Brennan > > > > Hmm I take that back about the KEYS file. I must have messed up my > > SVN foo, because I certainly updated my local copy of that file... > > Sorry for all the emails... Wrong link, the KEYS file in dev is correct. > https://dist.apache.org/repos/dist/dev/incubator/nuttx/KEYS > If you can let me know what is wrong here I will be happy to fix it, > but this seems correct to me. > > --Brennan >
Re: Meadow.OS .NET Standard 2.0 on STM32F7 (NUTTX + Mono Framework)
Nice! Azure Edge Computing :-) Op do 14 mei 2020 01:21 schreef Alan Carvalho de Assis : > Very interesting: > > https://www.youtube.com/watch?v=1tMX7gCeaFc >
Re: Start of the NuttX 9.0 release cycle
Nice! Op di 7 apr. 2020 om 21:03 schreef Nathan Hartman : > On Mon, Apr 6, 2020 at 10:16 AM Abdelatif Guettouche > wrote: > > As discussed in the previous thread [1], today is the start of the > > NuttX 9.0 release cycle. The release process is outlined in the link > > below. > > This is another chance for others to express their opinions, > > suggestions or concerns. > > > > Otherwise, we will move forward with the proposed release process. > > So today we create the nuttx-9.0 branch and start the first release > candidate. > > > > [1]. > https://lists.apache.org/thread.html/ref65dd30876e134cd4f86dd83668370bf414138b9adcf618292cd779%40%3Cdev.nuttx.apache.org%3E > > Hi all, > > First of all, thanks to everyone for helping this great project make > this important milestone! > > The nuttx-9.0 branch has been created. > > Do we intend to also make an apps-9.0 branch for the > incubator-nuttx-apps repository? > > At this time, we will need nuttx-9.0-incubating-rc1 (and, possibly, > nuttx-apps-9.0-incubating-rc1) tarballs. > > Perhaps we could get Greg's input, as far as steps did you take when > making tarballs for earlier releases? It will, of course, be important > that we document what we do as well as possible. > > For completeness, here's a link to the 9.0 Release Checklist on Confluence: > https://cwiki.apache.org/confluence/display/NUTTX/Release+9.0+Checklist > > Nathan >
NuttX seminar online 1th April 2020 14:30 European time
In these Corona days I have the idea to make a online seminar “Getting started with Nuttx”. I also made a VirtualBox image for the participants. I am still learning Nuttx myself, but you learn the most when you teach right? https://us04web.zoom.us/j/361350421?pwd=RGlhUkcxOG5XOUhDYVdINks5eFVrZz09 https://www.dropbox.com/sh/n51ficlngwpn6l7/AADaqVA-B0bICxNZp1ZskQXLa?dl=0 Maybe I will see you there? I have never used this platform before and it can handle 100 participants. So I hope all goes well. I have tested it with a few people. Thanks. @Alan I have tried to reach you and thought something was wrong. But I heared you are fine. I am glad!! Ben Verstuurd vanaf mijn iPhone
Re: Breakout apps/ ?
I agree. Verstuurd vanaf mijn iPhone > Op 20 mrt. 2020 om 18:51 heeft Alan Carvalho de Assis het > volgende geschreven: > > Hi Greg, > > I agree with this idea! A NuttX distribution makes sense and will > avoid licensing issues, we could let the user to select which licenses > he accept to use. > > BR, > > Alan > >> On 3/20/20, Gregory Nutt wrote: >> Hi, group, >> >> There has been talk for years about the idea of creating a separate >> project out of apps/, extending it so that it is a real NuttX >> "Distribution," basically like OpenEmbedded, Buildroot, or Yocto for >> NuttX. It would: >> >> * Download and install the NuttX >> * Select and build the custom firmware >> >> I have always thought this was a novel idea, but I have not particularly >> been an advocate. But I think that Apache licensing issues might drive >> us to reconsider this idea. The nuttx/ repository is really pretty >> clean. There is certainly some bits of third party code and certainly >> some ICLAs will be needed, but the code is really very clean. >> >> You cannot say this about apps. apps/ is a collection of code with a >> lot of third party code. There are full ports of third party >> applications (like interprers/bas, or netutils/thttpd, or modbus, or >> wapi, or ...). There are original applications (like NSH). And there >> is all manner of things in between. Mostlyare original applications >> with varying amounts of highly modified third party code. NxWidgets >> contains some Whoopsi code, for example. >> >> So perhaps we could simply things by pulling some or all of the apps/ >> out of the NuttX repositories. There apps/ are NOT the OS. They are a >> hodge-podge collection of applications that runs on the OS. The OS in >> the nuttx/repository stands alone and does not depend on the existence >> of apps/. So there is no imperative reason that we should retain apps/ >> in the nuttx/ respository. >> >> Certainly doing so is a convenience. But if licensing becomes an issue, >> then we should consider some options: >> >> * We could pull the entire apps/ repository out of the Apache >>repositories and manage it as a separate project outside of Apache. >>This would be the cleanest way to deliver a complete NuttX >>distribution in the spririt of OpenEmbedded or Buildroot. But there >>are some cons: The build system and PR checks depend on the >>existing configuration and such a change would potentially cause >>breakage or complexity. Some of the applications such as NSH really >>are very connected to the OS. Finally, there is no project structure >>in place to manage such a NuttX distribution. >> * We could also just move any dubious components out of apps/ and into >>a separate repository/project. As components that could be >>installed in apps/. This use case would be awkward and there is >>really no way to develop a "Distribution" from this. >> * Finally, we can do nothing and deal with the third party software in >>apps/ as we encountered it. >> >> Thoughts? >> >> Greg >> >> >>
Re: Snek in NuttX
Nice. Python is a language which matters. Although one has to think when to use what solution. Even with Nuttx you have to keep in mind when to use it. With hardware getting smaller factor and more resources it seems like a “normal” small OS is pushing the embedded RTOS Microsoft is also getting bigger with their Azure stack and when “connectivity” gets more deterministic it also shows its power. Our world is keep getting more solutions every day. Sometimes its best to stick to one believe, else you are getting lost and you will not achieve anything else then reading a lot of “new stuff”. Verstuurd vanaf mijn iPhone > Op 16 feb. 2020 om 19:54 heeft Gregory Nutt het > volgende geschreven: > > Ran across this: https://sneklang.org/ "Snek in NuttX"
Re: [VOTE] Remove Windows Native support?
-1 Verstuurd vanaf mijn iPhone > Op 20 jan. 2020 om 15:58 heeft Nathan Hartman het > volgende geschreven: > > On Mon, Jan 20, 2020 at 9:20 AM Gregory Nutt wrote: > >> The [DISCUSS] phase has complete and comments have been received. It is >> time to vote for or against removing Windows native support from the >> NuttX RTOS. >> >> Anyone in the community may vote on this question to express their >> opinion. However, only votes form PPC members will used to determine >> the outcome. A minimum of 3 PPMC +1 votes and more +1 PPMC votes than >> -1 PPMC are required to pass this vote. >> >> You may vote one of the following: >> >>[ ] +1 Remove all support for the Windows native build from the RTOS >>[ ] 0 No strong opinion >>[ ] -1 Retain support for the Windows native build in the RTOS >> >> Voting will close in 72 hours. > > > -1 > > I would urge us to keep the Windows Native build intact and label it > "experimental" until willing volunteers fix the rough edges and implement > nightly tests. > > Nathan
Re: [DISCUSS] Remove Windows Native support?
The Windows Cygwin build is a lot slower but it works. (See my video). My vote goes to keeping Windows. It keeps Nuttx followers and Windows is, as stated before, really making effort to support the IoT concept. And its also getting better in Open Source projects. Also their Cloud (Edge) solutions are beating IBM. in IDE and tooling they also make new efforts... Post a Windows related video and you will get 10x followers easy also many Engineering Companies and Engineers wok primarily in a Windows host. So the have to setup Virtual environments to establish a development environment. Also Nuttx had a “build and run everywhere” feeling and POSIX is also Windows... Why is Nuttx reviewing its core principles? What does Nuttx keep distinguished from its competitors loosing the BSD license already had impact Is the numbers of participants going up again? Does this effort already show benefits? First keep it like it is and Windows users did their thing and had questions... because it was still an option. First things first right? Focus on whats really important and get contributers back and get trust back in the solid platform (in perspective because testing could be a lot better in drivers etc). Arduino is getting into the STM stack and if an RTOS is compliant with that platform then people will go for that option. why? Because noobs can “make things”. My 2 cents and just saying... Verstuurd vanaf mijn iPhone > Op 16 jan. 2020 om 14:48 heeft Gregory Nutt het > volgende geschreven: > > >> What I means the full is that all config must pass the automation >> build and run the build system regularly like other host. > > Yes, the problem is a circular one. Why is the native build always out of > date? Because it is not tested. Why don't we test it? Because it is out of > date. > > There are only two ways to break that circular dependency: Remove it or make > it work. There is less inertia to removing it but I don't think that is a > good decision. Is it not motivated only by making the job easier? > > I have not tried a native build in some time. I will try that later today. > There is only one native build configuration in the repository: > stm32f4discovery:winbuild. Let me experiment a little to see where things > are. > >
Re: Towards making your first Apache release
I have been reading: http://www.apache.org/dev/release-publishing.html Verstuurd vanaf mijn iPhone > Op 15 jan. 2020 om 23:52 heeft Justin Mclean het > volgende geschreven: > > Hi, > > Is anyone willing to be the first release manager? > > Thanks, > Justin
Re: Towards making your first Apache release
Hello Justin, I cannot determine what the capabilities are that are needed and what the impact in hours will be? And I would need guidance I have a strong passion about Nuttx, but maybe thats not enough... Ben Verstuurd vanaf mijn iPhone > Op 15 jan. 2020 om 23:52 heeft Justin Mclean het > volgende geschreven: > > Hi, > > Is anyone willing to be the first release manager? > > Thanks, > Justin
Re: Can't make work shared file for CAN
Oleg: do you use an extended ID or standard ID? And do you use the CAN app from examples? Verstuurd vanaf mijn iPhone > Op 15 jan. 2020 om 22:02 heeft Oleg Evseev het volgende > geschreven: > > Hi! > > When I use usual file descriptor for can device: > file_open(>file, "/dev/can0", O_RDWR); > everything works, thread blocks if further read() and, when can message > receive, returns correct nbytes. > > When I open can0 with > file_open(, "/dev/can0", O_RDWR); > > it opens correctly and file_ioctl seems to work. But file_read from > do not block and return immediately same nbytes as requested with some > garbage in data. But there is no data on CAN bus. Polling (of course with > POLLFILE mask) also do not get blocked and return POLLIN event immediately. > > Doing file_detach() as describe in > https://www.nuttx.org/doku.php?id=wiki:nxinternal:detachedfds leads to the > same result. > > Any thoughts? > > Thanks. > > -- > With regards, > Oleg Evseev
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
Then you have the same situation where Nuttx came fromhaving Greg be that only person. The only difference is people had to see the 1400+ mails also reading this “signal”. So is this problem solved? Is there a “buddylist” where tasks are consolidated? Ben Verstuurd vanaf mijn iPhone > Op 14 jan. 2020 om 06:32 heeft Justin Mclean het > volgende geschreven: > > Hi, > >> Haitao Liu is the person in charge of developing the automated workflow, but >> we will start off simple. > > Why he may be doing the work it’s probably not correct from an ASF point of > view to say he’s in charge. Any contributor should be able to come along and > help out, make suggestion and propose changes. The group as a whole decide > what direction to go in. > > With a volunteer organisation assigning a task to a single person means that > some of them don’t get done, it's better if the community as a whole work on > things and take responsibility. > > Having a single person to rely on for critical infrastructure is also > problematic for a number of other reasons. For instance what happens if they > leave (for whatever reason) the project? > > Thanks, > Justin >
Re: Nuttx and SPI when using a gate 74AHC1G125
Yes I did. It seems that every SPI board already has this functionality... its working when I bypass the gate. Verstuurd vanaf mijn iPhone > Op 12 jan. 2020 om 15:25 heeft Alan Carvalho de Assis het > volgende geschreven: > > Hi Ben, > > I saw the circuit you sent privately to me. Actually you are using the > 74AHC1G125 as buffer to MISO signal, not MOSI as I was thinking. > > I see no reason it is not working, did you try to change the SPI frequency? > > BR, > > Alan > >> On 1/12/20, Alan Carvalho de Assis wrote: >> Hi Ben, >> >> You need to describer better your issue and what you are trying to do. >> We cannot guess what is happening at your side. >> >> Normally the /CS should goes low before the SPI data transfer and >> should go high at end of the transfer. So if you are connecting it to >> 74AHC1G125 to /OE you should see the MOSI signal at the pin Y. >> >> Are you connecting the /CS at your other device that probably is >> connected to 74AHC1G125 ? >> >> BR, >> >> Alan >> >>> On 1/12/20, disruptivesolution...@gmail.com >>> wrote: >>> Why is the CS not pulled low at the end? So it can receive the last 0xFF? >>> >>> When I bypass the gate it is working.. Using the gate it is not? >>> >>> >>> >>> Thanks >>> >>> >>> >>> Ben >>> >>> >>> >>> >>
Re: stm32_extmem.c and FSMC SDRAM solution in Nuttx?
Oke I want it to extend the RAM just like FSMC does on the STM429i.. so in boot it has to expand and that the framebuffer can use it as if it already was there.. I will look into some examples where I can begin the 23LC1024 I will try first. Verstuurd vanaf mijn iPhone > Op 9 jan. 2020 om 00:23 heeft Alan Carvalho de Assis het > volgende geschreven: > > Hi Ben, > > AFAIK NuttX doesn't have support to Serial SRAM yet. > > At least I never see a driver to it. > > Normally people use real SDRAM chips controlled by FMSC (in the case of > STM32). > > It should be a nice addition if you create a driver for Serial SRAM. > > BR, > > Alan > >> On 1/8/20, disruptivesolution...@gmail.com >> wrote: >> I just got a 23LC1024 (128kb SDRAM 1MBit) and want to "attach" this as >> external RAM. To scale up the free mem. >> >> I am looking at examples like stm32_extmem.c and qspi.. which one is best >> to >> use? And do I have to "make" a driver for it? And bind it to SPI? Or are my >> thoughts wrong? >> >> Thanks again... >> >>
Re: Jenkins CI
Is there a “code style” formatter possible for say Eclipse for Apache Nuttx? This can be custom made and gives the quality already while coding? Or is this not preferred adding it to a backend styling in git? Just thinking. Verstuurd vanaf mijn iPhone > Op 8 jan. 2020 om 05:03 heeft Gregory Nutt het volgende > geschreven: > > >> >>> Since code check part is available now, could I and Duo prepare to setup >>> Jenkins CI job firstly? >> Where are you intending to set up this job? Here [1] or elsewhere? > > Hopefully not in the end-user directories :-\ > > Greg >
Re: Apache NuttX website
This is a good thing! Verstuurd vanaf mijn iPhone > Op 6 jan. 2020 om 08:49 heeft Justin Mclean het > volgende geschreven: > > Hi, > >> One thing I wanted to get feedback from Justin on is can we link to the old >> releases before Apache. If so what kind of disclaimer do we need to >> provide? > > As long as they are very clearly marked as not being Apache releases that > fine. > > Thanks, > Justin
Re: stm32_extmem.c and FSMC SDRAM solution in Nuttx?
Thanks all! I will look into all options! Verstuurd vanaf mijn iPhone > Op 5 jan. 2020 om 23:05 heeft Gregory Nutt het volgende > geschreven: > > >> If I remember right stm32f407 doesn't support sdram. >> > A large external SRAM could be used, however.
Re: NX Graphics
Ahhh so say FSMC with say a DS3231 I2C Precision Clock with AT24C32 Memory???
The resources onboard are insufficient...?
Ben
Verstuurd vanaf mijn iPhone
> Op 5 jan. 2020 om 14:53 heeft Gregory Nutt het volgende
> geschreven:
>
> You need to allocate **contiguous** memory for the framebuffer. The largest
> contiguous region in the heap has size 124,192 bytes. You can allocate
> nothing larger than that.
>
> The size of the framebuffer you are tying to allocate is 153,600 bytes. So
> any attempt to allocate that framebuffer from that heap will fail.
>
>> On 1/5/2020 7:49 AM, disruptivesolution...@gmail.com wrote:
>> Oke I think I am getting somewhere
>>
>> Priv has (during lcd_framebuffer):
>> fblen -> 153600
>> xres -> 320
>> yres -> 240
>> stride -> 640
>> display -> 0 '\0'
>>
>> fbmem = 0x0
>> *fbmem -> 72 'H'
>>
>> But it stil runs into this error:
>> priv->fbmem = (FAR uint8_t *)kmm_zalloc(priv->fblen);
>> if (priv->fbmem == NULL)
>> {
>> --?> lcderr("ERROR: Failed to allocate frame buffer memory\n");
>>
>> What am I overlooking here? Yes fbmem is 0... .
>>
>> Total; used; free; largest;
>> Umem: 191920 7568 184352 124192
>>
>> Ben
>>
>> -Oorspronkelijk bericht-
>> Van: Gregory Nutt
>> Verzonden: zaterdag 4 januari 2020 22:39
>> Aan: dev@nuttx.apache.org
>> Onderwerp: Re: NX Graphics
>>
>>
>>> Priv->fblen = 0
>> Trying to allocate a buffer of zero length will return the value NULL too.
>>
>>
>>
>
Re: Build testing
Very interesting... I would like to use build scripts in the Jenkins solution I have running to test my STM book configs... Verstuurd vanaf mijn iPhone > Op 2 jan. 2020 om 18:40 heeft Gregory Nutt het volgende > geschreven: > > >> I have some scripts that I use to perform build testing. That is, just >> build as many configurations. This only verifies that no existing builds >> are broken. It does not prove that a change is correct or that a change >> will not break a build that actually uses the change. It would take a much >> smarter test to do that then such a brute force test (when, I don't advocate >> such dumb build testing). >> >> But it would be nice to have it running as a 'cron' somewhere. It currently >> builds 419 ARM configurations! plus several dozen sim, AVR, and MIPS (PIC32 >> configurations). It would be nice if there were available online some so >> that if someone wants to make a change to many files like this in the >> future, we can at least be assured it won't break builds. >> >> The build test is based primarily on nuttx/tools/testbuild.sh which will >> build a list of configurations. The configuration lists are elsewhere at >> https://bitbucket.org/nuttx/tools/src/master/buildtest/ There are also some >> bonehead scripts at the location that only work on my machine. These >> basically just setup paths, and manage running nuttx/tools/testbuild.sh. >> Those bonehead scripts are setup to work only in my environment and would >> not work anywhere else without modification. >> >> But if we could make this runnable online (perhaps via Jenkins?), then we >> could avoid such extensive code breakage in the future. > > I should also mention how I use this. > > * I keep the last "successful" build test output in, for example, > armtest.log.last > * I run the test generating a new armtest.log > * I then 'diff -u armtest.log.last armtest.log | vim -' and I can see > if any new warnings or errors occur. > > There is another bonehead script, monitor.sh, that just shows me the running > status of the test. I am sure that the people on this list with more devops > skills than I could make this all work smoother. > > >
Re: ILI9341 port to STM32F4
That would be very nice! Op wo 1 jan. 2020 19:57 schreef Dave Marples : > Ben, > > I have this up and running on an imxrt with a 'generic' spi driver > (i.e.that should work with any spi device rather than the platform specific > one that was previously in use). When I'm back at my desk this evening I'll > send the files to you so you can compare and contrast to make something > suitable for inclusion based on what you've already got. > > Regards > > Dave > > On Wed, 1 Jan 2020, 18:39 Gregory Nutt, wrote: > > > > > > Disabling the colormap config (CONFIG_STM32_FB_CMAP) it gives a white > > > screen (no text "Hello World"), but no hardfault... and if I start > > nxhello > > > for the second time I get: > > > stm32_spi2select: devid: 262144 CS: assert > > White is probably better. That just means that the data sent to the LCD > > is bad (all ones?) but the backlight is on. > > > ili9341_getplaneinfo: planeno: 0 bpp: 16 > > bpp=16, certainly you are not using a colormap. > > > * and if I start nxhello for the second time I get: * > > > > The example probably does not disconnect from NX. If it did disconnt, > > the screen should go black you would see nothing. I think all of the > > other nxhello examples run standalone (not sure). > > > > > > >
Re: ILI9341 port to STM32F4
I am trying to put it all together, because I am not using the STM32F429i-disco with integrated TFT-LCD. But a ILI9431 Here I could find the Memory regions (also FMC and 3 memory regions [if I get it right...]) https://www.st.com/content/ccc/resource/technical/document/application_note/group0/25/ca/f9/b4/ae/fc/4e/1e/DM00287603/files/DM00287603.pdf/jcr:content/translations/en.DM00287603.pdf And this is my datasheet for the ILI9341 and its a QVGA (320 x 240) https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf The display: https://www.ebay.com/itm/3-2-inch-LCD-TFT-With-Resistive-Touch-Screen-ILI9341-Display-Module-320-240-/183001025101 When the memory regions are not correct defined I do get that I get hardfaults... but I am struggling with these definitions. CONFIG_STM32_DMA2D_FB_BASE=0xD07B5000 CONFIG_STM32_DMA2D_FB_SIZE=15 CONFIG_STM32_DMA2D_LAYER_PPLINE=240 CONFIG_STM32_DMA2D_NLAYERS=2 CONFIG_STM32_LTDC=y CONFIG_STM32_LTDC_FB_BASE=0xD076A000 CONFIG_STM32_LTDC_FB_SIZE=15 CONFIG_HEAP2_BASE=0xD000 CONFIG_HEAP2_SIZE=15 Op wo 1 jan. 2020 om 19:29 schreef Gregory Nutt : > Does that hardware support color mapping? Normally that is used with > 8-bit palette colors like old fashioned computers from the 80's. You > probably don't want it. > > On 1/1/2020 11:56 AM, Disruptive Solutions wrote: > > I am close, but looking in a loop? > > > > In ili9341_getvideoinfo the vinfo struct is filled correctly? > > fmt = 11 > > xres = 320 > > yres = 240 > > nplanes = 1 > > noverlays = 0 > > > > Is seems that the colormap is setting some problems in nxbe_colormap.c > > (lcd.h) > > /* Then set the color map */ > > > >ret = dev->putcmap(dev, ); > > > > Disabling the colormap config (CONFIG_STM32_FB_CMAP) it gives a white > > screen (no text "Hello World"), but no hardfault... and if I start > nxhello > > for the second time I get: > > stm32_spi2select: devid: 262144 CS: assert > > > > stm32_ili93414ws_sendcmd: cmd=0029 > > > > stm32_spi2select: devid: 262144 CS: de-assert > > > > ili9341_getvideoinfo: fmt: 11 xres: 320 yres: 240 nplanes: 1 > > > > ili9341_getplaneinfo: planeno: 0 bpp: 16 > > > > > > * and if I start nxhello for the second time I get: * > > > > nsh> nxhello > > > > nxhello_initialize: nx_connect failed: 28 > > > > nxhello_main: NX handle=0 > > > > nxhello_main: Failed to get NX handle: 28 > > > > nsh> > > > > Somebody has an idea? > > > > Op wo 1 jan. 2020 om 13:06 schreef spudaneco : > > > >> Sent from Samsung tablet. > >> It seems strange that by not selecting CONFIG_NX_KBD it stil is trying > >> tocompile stuff that has relations with this > >> config?src/cnxwidget.cxx:691:65: error: 'class > NXWidgets::CWidgetControl' > >> has nomember named 'doubleClick' if (m_flags.doubleClickable && > >> hasFocus() &_widgetControl->doubleClick())DoubleClick has nothing to > do > >> with the ketboard. That is mouse codeAnd other problems. It seems I > have > >> to make changes in the NX side of Nuttxto get this going..?I don't > >> understand that. > > >
Re: ILI9341 port to STM32F4
I am close, but looking in a loop? In ili9341_getvideoinfo the vinfo struct is filled correctly? fmt = 11 xres = 320 yres = 240 nplanes = 1 noverlays = 0 Is seems that the colormap is setting some problems in nxbe_colormap.c (lcd.h) /* Then set the color map */ ret = dev->putcmap(dev, ); Disabling the colormap config (CONFIG_STM32_FB_CMAP) it gives a white screen (no text "Hello World"), but no hardfault... and if I start nxhello for the second time I get: stm32_spi2select: devid: 262144 CS: assert stm32_ili93414ws_sendcmd: cmd=0029 stm32_spi2select: devid: 262144 CS: de-assert ili9341_getvideoinfo: fmt: 11 xres: 320 yres: 240 nplanes: 1 ili9341_getplaneinfo: planeno: 0 bpp: 16 * and if I start nxhello for the second time I get: * nsh> nxhello nxhello_initialize: nx_connect failed: 28 nxhello_main: NX handle=0 nxhello_main: Failed to get NX handle: 28 nsh> Somebody has an idea? Op wo 1 jan. 2020 om 13:06 schreef spudaneco : > Sent from Samsung tablet. > It seems strange that by not selecting CONFIG_NX_KBD it stil is trying > tocompile stuff that has relations with this > config?src/cnxwidget.cxx:691:65: error: 'class NXWidgets::CWidgetControl' > has nomember named 'doubleClick' if (m_flags.doubleClickable && > hasFocus() &_widgetControl->doubleClick())DoubleClick has nothing to do > with the ketboard. That is mouse codeAnd other problems. It seems I have > to make changes in the NX side of Nuttxto get this going..?I don't > understand that.
Re: ILI9341 port to STM32F4
This has docu...
http://nuttx.org/doku.php?id=documentation:nxgraphics --> Strange...
sometimes its white?
Op wo 1 jan. 2020 om 11:47 schreef Disruptive Solutions <
disruptivesolution...@gmail.com>:
> I wanted to use NX on the ILI9341... but is the documentation somewhere
> filled? Or are there some examples how to configure this?
>
> https://nuttx.org/doku.php?id=documentation:nxgraphics --> Is empty?
>
> Ben
>
> Op wo 1 jan. 2020 om 11:31 schreef Disruptive Solutions <
> disruptivesolution...@gmail.com>:
>
>> I just checked your proposal Brennan. In my install base it's not doing
>> it for me. Eclipse does. I already had this extension installed. To bad
>> though. I really loved Visual Studio Code and I can use it for some
>> coding... but for debugging I have to jump to Eclipse.
>>
>> Ben
>>
>> Op wo 1 jan. 2020 om 11:20 schreef Disruptive Solutions <
>> disruptivesolution...@gmail.com>:
>>
>>> In have Cortex-Debug but I have to look at this, maybe its a different
>>> version. In my version I could not Copy-Paste the LR register address in PC
>>> and then go from there
>>>
>>> Verstuurd vanaf mijn iPhone
>>>
>>> > Op 1 jan. 2020 om 10:50 heeft Brennan Ashton <
>>> bash...@brennanashton.com> het volgende geschreven:
>>> >
>>> > Ben,
>>> > If you want to use vscode use this extension.
>>> >
>>> >
>>> https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug
>>> >
>>> > It gives you the debug functionality that you are asking about. There
>>> are
>>> > also a lot of other powerful features if you dig into setting it up
>>> > including ITM graphing.
>>> >
>>> > --Brennan
>>> >
>>> >> On Wed, Jan 1, 2020, 1:38 AM Disruptive Solutions <
>>> >> disruptivesolution...@gmail.com> wrote:
>>> >>
>>> >> Thank you David! I do not need to make a new video, your video is very
>>> >> clear! And I always give credits to the people who deserve it ;-)
>>> >>
>>> >> The
>>> https://mcuoneclipse.com/2012/10/27/assembly-instruction-stepping/ is
>>> >> very useful and this seems to make Eclipse the only IDE that has this
>>> >> feature..? It seems to exclude on this criteria Visual Studio Code...
>>> that
>>> >> is a shame..?
>>> >>
>>> >> I have some NX questions and keep getting hardfaults the first
>>> >> hardfault I solved ;-) It was a too large FB size.
>>> >>
>>> >> It seems strange that by not selecting CONFIG_NX_KBD it stil is
>>> trying to
>>> >> compile stuff that has relations with this config?
>>> >>
>>> >> src/cnxwidget.cxx:691:65: error: 'class NXWidgets::CWidgetControl'
>>> has no
>>> >> member named 'doubleClick'
>>> >> if (m_flags.doubleClickable && hasFocus() &&
>>> >> m_widgetControl->doubleClick())
>>> >>
>>> >> And other problems. It seems I have to make changes in the NX side of
>>> Nuttx
>>> >> to get this going..?
>>> >>
>>> >> Ben
>>> >>
>>> >> Op zo 29 dec. 2019 om 19:44 schreef Disruptive Solutions <
>>> >> disruptivesolution...@gmail.com>:
>>> >>
>>> >>> It looks like its happening here... (type previous mail: graphical)
>>> >>>
>>> >>> stm32_ltdc_lclear(overlay);
>>> >>>
>>> >>> /* Set layers framebuffer */
>>> >>>
>>> >>> stm32_ltdc_lframebuffer(layer); <---??
>>> >>>
>>> >>> Op zo 29 dec. 2019 om 19:39 schreef Disruptive Solutions <
>>> >>> disruptivesolution...@gmail.com>:
>>> >>>
>>> >>>> I have most of it done for porting the grapical TFT-LCD ILI9341
>>> through
>>> >>>> SPI...
>>> >>>>
>>> >>>> But I get a PANIC when it is trying to do:
>>> >>>> stm32_ltds_linit(LTDC_LAYER_L1); in stm32_ltdc.c
>>> >>>>
>>> >>>> Does someone know this?
>>> >>>>
>>> >>>> Ben
>>> >>>>
>>> >>>> /* Initialize ltdc layer */
>>> >>>>
>>> >>>> lcdinfo("Initialize ltdc layer\n");
>>> >>>> stm32_ltdc_linit(LTDC_LAYER_L1);
>>> >>>> #ifdef CONFIG_STM32_LTDC_L2
>>> >>>> stm32_ltdc_linit(LTDC_LAYER_L2);
>>> >>>> #endif
>>> >>>>
>>> >>>>
>>> >>
>>>
>>
Re: ILI9341 port to STM32F4
I just checked your proposal Brennan. In my install base it's not doing it
for me. Eclipse does. I already had this extension installed. To bad
though. I really loved Visual Studio Code and I can use it for some
coding... but for debugging I have to jump to Eclipse.
Ben
Op wo 1 jan. 2020 om 11:20 schreef Disruptive Solutions <
disruptivesolution...@gmail.com>:
> In have Cortex-Debug but I have to look at this, maybe its a different
> version. In my version I could not Copy-Paste the LR register address in PC
> and then go from there
>
> Verstuurd vanaf mijn iPhone
>
> > Op 1 jan. 2020 om 10:50 heeft Brennan Ashton
> het volgende geschreven:
> >
> > Ben,
> > If you want to use vscode use this extension.
> >
> > https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug
> >
> > It gives you the debug functionality that you are asking about. There are
> > also a lot of other powerful features if you dig into setting it up
> > including ITM graphing.
> >
> > --Brennan
> >
> >> On Wed, Jan 1, 2020, 1:38 AM Disruptive Solutions <
> >> disruptivesolution...@gmail.com> wrote:
> >>
> >> Thank you David! I do not need to make a new video, your video is very
> >> clear! And I always give credits to the people who deserve it ;-)
> >>
> >> The https://mcuoneclipse.com/2012/10/27/assembly-instruction-stepping/
> is
> >> very useful and this seems to make Eclipse the only IDE that has this
> >> feature..? It seems to exclude on this criteria Visual Studio Code...
> that
> >> is a shame..?
> >>
> >> I have some NX questions and keep getting hardfaults the first
> >> hardfault I solved ;-) It was a too large FB size.
> >>
> >> It seems strange that by not selecting CONFIG_NX_KBD it stil is trying
> to
> >> compile stuff that has relations with this config?
> >>
> >> src/cnxwidget.cxx:691:65: error: 'class NXWidgets::CWidgetControl' has
> no
> >> member named 'doubleClick'
> >> if (m_flags.doubleClickable && hasFocus() &&
> >> m_widgetControl->doubleClick())
> >>
> >> And other problems. It seems I have to make changes in the NX side of
> Nuttx
> >> to get this going..?
> >>
> >> Ben
> >>
> >> Op zo 29 dec. 2019 om 19:44 schreef Disruptive Solutions <
> >> disruptivesolution...@gmail.com>:
> >>
> >>> It looks like its happening here... (type previous mail: graphical)
> >>>
> >>> stm32_ltdc_lclear(overlay);
> >>>
> >>> /* Set layers framebuffer */
> >>>
> >>> stm32_ltdc_lframebuffer(layer); <---??
> >>>
> >>> Op zo 29 dec. 2019 om 19:39 schreef Disruptive Solutions <
> >>> disruptivesolution...@gmail.com>:
> >>>
> >>>> I have most of it done for porting the grapical TFT-LCD ILI9341
> through
> >>>> SPI...
> >>>>
> >>>> But I get a PANIC when it is trying to do:
> >>>> stm32_ltds_linit(LTDC_LAYER_L1); in stm32_ltdc.c
> >>>>
> >>>> Does someone know this?
> >>>>
> >>>> Ben
> >>>>
> >>>> /* Initialize ltdc layer */
> >>>>
> >>>> lcdinfo("Initialize ltdc layer\n");
> >>>> stm32_ltdc_linit(LTDC_LAYER_L1);
> >>>> #ifdef CONFIG_STM32_LTDC_L2
> >>>> stm32_ltdc_linit(LTDC_LAYER_L2);
> >>>> #endif
> >>>>
> >>>>
> >>
>
Re: ILI9341 port to STM32F4
Thank you David! I do not need to make a new video, your video is very
clear! And I always give credits to the people who deserve it ;-)
The https://mcuoneclipse.com/2012/10/27/assembly-instruction-stepping/ is
very useful and this seems to make Eclipse the only IDE that has this
feature..? It seems to exclude on this criteria Visual Studio Code... that
is a shame..?
I have some NX questions and keep getting hardfaults the first
hardfault I solved ;-) It was a too large FB size.
It seems strange that by not selecting CONFIG_NX_KBD it stil is trying to
compile stuff that has relations with this config?
src/cnxwidget.cxx:691:65: error: 'class NXWidgets::CWidgetControl' has no
member named 'doubleClick'
if (m_flags.doubleClickable && hasFocus() &&
m_widgetControl->doubleClick())
And other problems. It seems I have to make changes in the NX side of Nuttx
to get this going..?
Ben
Op zo 29 dec. 2019 om 19:44 schreef Disruptive Solutions <
disruptivesolution...@gmail.com>:
> It looks like its happening here... (type previous mail: graphical)
>
> stm32_ltdc_lclear(overlay);
>
> /* Set layers framebuffer */
>
> stm32_ltdc_lframebuffer(layer); <---??
>
> Op zo 29 dec. 2019 om 19:39 schreef Disruptive Solutions <
> disruptivesolution...@gmail.com>:
>
>> I have most of it done for porting the grapical TFT-LCD ILI9341 through
>> SPI...
>>
>> But I get a PANIC when it is trying to do:
>> stm32_ltds_linit(LTDC_LAYER_L1); in stm32_ltdc.c
>>
>> Does someone know this?
>>
>> Ben
>>
>> /* Initialize ltdc layer */
>>
>> lcdinfo("Initialize ltdc layer\n");
>> stm32_ltdc_linit(LTDC_LAYER_L1);
>> #ifdef CONFIG_STM32_LTDC_L2
>> stm32_ltdc_linit(LTDC_LAYER_L2);
>> #endif
>>
>>
Re: ILI9341 port to STM32F4
It looks like its happening here... (type previous mail: graphical)
stm32_ltdc_lclear(overlay);
/* Set layers framebuffer */
stm32_ltdc_lframebuffer(layer); <---??
Op zo 29 dec. 2019 om 19:39 schreef Disruptive Solutions <
disruptivesolution...@gmail.com>:
> I have most of it done for porting the grapical TFT-LCD ILI9341 through
> SPI...
>
> But I get a PANIC when it is trying to do:
> stm32_ltds_linit(LTDC_LAYER_L1); in stm32_ltdc.c
>
> Does someone know this?
>
> Ben
>
> /* Initialize ltdc layer */
>
> lcdinfo("Initialize ltdc layer\n");
> stm32_ltdc_linit(LTDC_LAYER_L1);
> #ifdef CONFIG_STM32_LTDC_L2
> stm32_ltdc_linit(LTDC_LAYER_L2);
> #endif
>
>
Re: Podling Nuttx Report Reminder - January 2020
Nice... Who is going to do this? Verstuurd vanaf mijn iPhone > Op 28 dec. 2019 om 06:11 heeft jmcl...@apache.org het volgende geschreven: > > Dear podling, > > This email was sent by an automated system on behalf of the Apache > Incubator PMC. It is an initial reminder to give you plenty of time to > prepare your quarterly board report. > > The board meeting is scheduled for Wed, 15 January 2020, 10:30 am PDT. > The report for your podling will form a part of the Incubator PMC > report. The Incubator PMC requires your report to be submitted 2 weeks > before the board meeting, to allow sufficient time for review and > submission (Wed, January 01). > > Please submit your report with sufficient time to allow the Incubator > PMC, and subsequently board members to review and digest. Again, the > very latest you should submit your report is 2 weeks prior to the board > meeting. > > Candidate names should not be made public before people are actually > elected, so please do not include the names of potential committers or > PPMC members in your report. > > Thanks, > > The Apache Incubator PMC > > Submitting your Report > > -- > > Your report should contain the following: > > * Your project name > * A brief description of your project, which assumes no knowledge of >the project or necessarily of its field > * A list of the three most important issues to address in the move >towards graduation. > * Any issues that the Incubator PMC or ASF Board might wish/need to be >aware of > * How has the community developed since the last report > * How has the project developed since the last report. > * How does the podling rate their own maturity. > > This should be appended to the Incubator Wiki page at: > > https://cwiki.apache.org/confluence/display/INCUBATOR/January2020 > > Note: This is manually populated. You may need to wait a little before > this page is created from a template. > > Note: The format of the report has changed to use markdown. > > Mentors > --- > > Mentors should review reports for their project(s) and sign them off on > the Incubator wiki page. Signing off reports shows that you are > following the project - projects that are not signed may raise alarms > for the Incubator PMC. > > Incubator PMC
Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)
This sounds like it was... clone the repo to local. Do our thing making a feature branch.. commit to our own private repo ... Send patch (format patch) in (after nxstyle, indent, etc and README addition) and let it reviewed by sending it to central channel (was Google Group) and checkout locally to master, pull the latest patches from origin/master and do another feature... same proces again. Ben Verstuurd vanaf mijn iPhone > Op 27 dec. 2019 om 21:28 heeft Nathan Hartman het > volgende geschreven: > > On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao > wrote: >>> On Fri, Dec 27, 2019 at 10:59 PM David Sidrane >>> wrote: >>> Notice what happened in the repo. >> >> Yes, you manually create a branch in official repo without any review >> process. >> >>> See https://github.com/apache/incubator-nuttx-website/branches >>> >>> Now do you see why the argument makes sense? >>> >> >> No, since the normal contributor even don't have right to modify >> anything in official repo. Only committer can hit this issue, you just >> abuse the committer power. >> This also demonstrate PX4 workflow encourage people modify the >> official repo directly just like local fork, I don't think it's a good >> habit. >> >>> Are we going to prohibit this? Think about the ramification. We as >>> committers will not be able to use the UI when it makes sense. >> >> Of course, we should prohibit any modification which doesn't pass the >> review process like this enter the repo. >> You can do anything in your fork with UI, but shouldn't mess up the >> official repo. >> Many people will sync up with the official repo, any partial or stale >> work just make the newbie confusion. > > Exactly. > > Any changes you want to make (whether you are a committer or not): > * If you are using GitHub, make a fork, make your changes in your > fork, open a PR. > * If you are using git, make a clone, make your changes in your clone, > send a 'git request-pull' or 'git format-patch'. > * If you are using no SCM / other SCM, get the release tarball, make > your changes, produce a patch. > > Committers are not allowed to bypass the above and put stuff directly > in the repo without going through the same process and review as > everyone else. > > Nathan
Re: Why the text displayed by SSD1306 / I2C is reversed along the vertical axis
Typo: SAD=SSD and I had the same “issues” with the other drivers. Verstuurd vanaf mijn iPhone > Op 27 dec. 2019 om 08:37 heeft Disruptive Solutions > het volgende geschreven: > > Say a generic SAD 1306 through I2C. I have it working with only the block > thing just now, but wanted to try to show some text or bitmap (battery icon > or something) > > Verstuurd vanaf mijn iPhone > >> Op 27 dec. 2019 om 03:26 heeft Nii Jyeni het volgende >> geschreven: >> >> At the beginning, I was not sure what kind of OLED was used, so I tried >> using UG2864HSWEG01, and the result went further and further on the wrong >> path. Later when the SSD1306 universal driver was selected for the last >> attempt, it would then display normally. So I chose the wrong driver from >> the beginning, which is a very serious low-level error. This is really a >> joke, so before any attempt, you must figure out what device you are using. >> This is the lesson I learned through this attempt. >> BR >> NiiJyeni >> >>> 2019年12月26日 下午5:40，Disruptive Solutions >>> 写道： >>> >>> Maybe you could share your defconfig? And did you had to add files to src? >>> And/or header files? >>> >>> Maybe others could benefit also from your journey? >>> >>> Ben >>> >>> Verstuurd vanaf mijn iPhone >>> >>>>> Op 26 dec. 2019 om 04:23 heeft Nii Jyeni het >>>>> volgende geschreven: >>>> >>>> Thanks, I found a solution. I used the wrong driver chip! >>>> BR >>>> NiiJyeni >>>> >>>>> 2019年12月24日 下午4:48，Sebastien Lorquet 写道： >>>>> >>>>> hello >>>>> >>>>> IIRC the config menus allow you to flip the display direction. Did you >>>>> have a >>>>> look over there? >>>>> >>>>> Sebastien >>>>> >>>>>> Le 24/12/2019 à 08:39, Nii Jyeni a écrit : >>>>>> Hi~ >>>>>> I am trying the graphics module of nuttx. I just used the nxtext sample >>>>>> program and found that the text displayed on oled is reversed. It seems >>>>>> that each character is flipped vertically. Does anyone know what is >>>>>> going on here? how should I solve this? Thank you! >>>>>> >>>>>> BOARD:STM32F407VE（compatible stm32f4discovery） >>>>>> HOST:macOS >>>> >>
Re: Why the text displayed by SSD1306 / I2C is reversed along the vertical axis
Say a generic SAD 1306 through I2C. I have it working with only the block thing just now, but wanted to try to show some text or bitmap (battery icon or something) Verstuurd vanaf mijn iPhone > Op 27 dec. 2019 om 03:26 heeft Nii Jyeni het volgende > geschreven: > > At the beginning, I was not sure what kind of OLED was used, so I tried > using UG2864HSWEG01, and the result went further and further on the wrong > path. Later when the SSD1306 universal driver was selected for the last > attempt, it would then display normally. So I chose the wrong driver from the > beginning, which is a very serious low-level error. This is really a joke, so > before any attempt, you must figure out what device you are using. This is > the lesson I learned through this attempt. > BR > NiiJyeni > >> 2019年12月26日 下午5:40，Disruptive Solutions 写道： >> >> Maybe you could share your defconfig? And did you had to add files to src? >> And/or header files? >> >> Maybe others could benefit also from your journey? >> >> Ben >> >> Verstuurd vanaf mijn iPhone >> >>>> Op 26 dec. 2019 om 04:23 heeft Nii Jyeni het >>>> volgende geschreven: >>> >>> Thanks, I found a solution. I used the wrong driver chip! >>> BR >>> NiiJyeni >>> >>>> 2019年12月24日 下午4:48，Sebastien Lorquet 写道： >>>> >>>> hello >>>> >>>> IIRC the config menus allow you to flip the display direction. Did you >>>> have a >>>> look over there? >>>> >>>> Sebastien >>>> >>>>> Le 24/12/2019 à 08:39, Nii Jyeni a écrit : >>>>> Hi~ >>>>> I am trying the graphics module of nuttx. I just used the nxtext sample >>>>> program and found that the text displayed on oled is reversed. It seems >>>>> that each character is flipped vertically. Does anyone know what is going >>>>> on here? how should I solve this? Thank you! >>>>> >>>>> BOARD:STM32F407VE（compatible stm32f4discovery） >>>>> HOST:macOS >>> >
Re: Release Manager
https://cwiki.apache.org/confluence/display/REEF/Release+Manager+Guide Verstuurd vanaf mijn iPhone > Op 26 dec. 2019 om 16:11 heeft Gregory Nutt het > volgende geschreven: > > With all of the talk about work flow, there are several other things that we > need to keep our eye on. One is releases. > > I think that one person on the PPMC should step up and volunteer to > coordinate releases as a Release Manager (RM). I don't know what all is > involved in the Apache release process but it is fairly complex, we need an > RM to coordinate. Hopefully, the effort can be shared, but one person has to > put is all together. > > Mid-January of 2020 was the next, planned release data for NuttX-8.3. I > agreed when we started that that we would not worry about making planned, > release dates during the project transition. I think we are probably still > 1-2 months away from the first Apache NuttX release. We need to get past the > workflow requirements definition that is sucking all of the air out of the > room now and we must deal with the new Apache release process. Then we can do > the release. I don't see that happening until February or March. > > Greg > > >
Re: Apache NuttX website
NuttX Team Members --> code incompletion Wiki jumps to the wrong link I think? Jou want to jump to the "home" Wiki "Nuttx"? my 2 cents Ben Op do 26 dec. 2019 om 11:24 schreef Hans : > Hi all, > > I forked the great work Brennan has done and put it on Github Pages > (temporarily) for you guys to review. > > https://apache-nuttx-website.github.io/ > > I happen to have some Jekyll and web development experiences. > And I also know some professional graphics designers who have agreed to > help with future website and logo desgin voluntarily. > > I think I can take the responsibility maintain our website. > :-) > > Thanks, > Huahang > > > On Sun, Dec 22, 2019 at 10:05 PM Gregory Nutt wrote: > > > Did someone call a vote on this? This is all very confusing. > > > > First, we have adopted the shorthand of +1 just to mean you agree with > > something. That is not a vote and a little confusing in most contexts. > > > > Votes should be formally called with [VOTE] in the subject. Otherwise, > > how can I tell if I am voting, or if people are just using the shortand > > to agree with things? > > > > Greg > > > > On 12/22/2019 8:01 AM, Alin Jerpelea wrote: > > > +1 > > > > > > On Sat, Dec 21, 2019, 10:04 Disruptive Solutions < > > > disruptivesolution...@gmail.com> wrote: > > > > > >> +1 > > >> > > >> Verstuurd vanaf mijn iPhone > > >> > > >>> Op 21 dec. 2019 om 08:27 heeft David Sidrane < > david.sidr...@nscdg.com> > > >> het volgende geschreven: > > >>> +1 > > >>> > > >>> -Original Message- > > >>> From: Brennan Ashton [mailto:bash...@brennanashton.com] > > >>> Sent: Friday, December 20, 2019 8:54 PM > > >>> To: dev@nuttx.apache.org > > >>> Subject: Re: Apache NuttX website > > >>> > > >>> Could we create the repo for the website. > > >>> http://www.apache.org/dev/project-site.html > > >>> > > >>> The one I created is based off the Jekyll template as discussed here. > > >>> > https://incubator.apache.org/guides/sites.html#publishing_your_website > > > > > > > > -- > 刘华航 (Hans) > 行走, 思考, 在路上 >
Re: Why the text displayed by SSD1306 / I2C is reversed along the vertical axis
Maybe you could share your defconfig? And did you had to add files to src? And/or header files? Maybe others could benefit also from your journey? Ben Verstuurd vanaf mijn iPhone > Op 26 dec. 2019 om 04:23 heeft Nii Jyeni het volgende > geschreven: > > Thanks, I found a solution. I used the wrong driver chip! > BR > NiiJyeni > >> 2019年12月24日 下午4:48，Sebastien Lorquet 写道： >> >> hello >> >> IIRC the config menus allow you to flip the display direction. Did you have a >> look over there? >> >> Sebastien >> >>> Le 24/12/2019 à 08:39, Nii Jyeni a écrit : >>> Hi~ >>> I am trying the graphics module of nuttx. I just used the nxtext sample >>> program and found that the text displayed on oled is reversed. It seems >>> that each character is flipped vertically. Does anyone know what is going >>> on here? how should I solve this? Thank you! >>> >>> BOARD:STM32F407VE（compatible stm32f4discovery） >>> HOST:macOS >
Re: Single Committer
A platform like this could help? Samsung seems to use it? Does Apache has something like this “Helix Core” and “Swarm” ?? https://www.perforce.com/products/helix-swarm Benefit drom these ideas? And you could start with 1 commiter and scale up later. The way of working will be getting more clear and get to the “standards” Greg sees?? Verstuurd vanaf mijn iPhone > Op 24 dec. 2019 om 06:07 heeft Nathan Hartman het > volgende geschreven: > > On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt wrote: >> >> Recent events have made me reconsider some decisions I made. I threw >> off the single committer mantle when I saw the abuse of privilege in the >> repositories. If the PPMC agrees to it, I will take up that role again. >> >> But let's be frank. Here is what I think that means: >> >> * I would be sole committer of changes. The repositories would have >>to be treated as read-only just as back in the Bitbucket days. >> * I would grandfather in the i.MXRT changes. >> * I will decline all workflow related changes until workflow >>requirements are established (that is my only real motivation for >>suggesting this: To make certain that we have proper requirements >>in place before we accept PX4 workflow into our repositories. We >>need to do this right and I am willing to protect the repositories >>until the workflow requirements are established. I expect that to >>take about two weeks.) >> * I would create a dev branch and expect all PRs to be against that >>dev branch. >> * As soon as the PPMC is confident that it has the processes in place >>to handle the commit workload I will gladly relinquish this role. >> * THIS IS NOT THE APACHE WAY. This is an interim dictatorship role to >>expedite the avalanche of commits expected after the holidays. >> >> If any of this concerns people, please "Just Say No." I am not married >> to the idea and I am not forcefully advocating it. This is what people >> wanted me to do a few days ago and if I can protect our right to define >> the workflow, then I will do it. For me it is a sacrifice that I would >> take with no pleasure in. >> >> Pros: This will provide project continuity until the PPMC is fully >> functional. Having workflow requirements will be a huge step in that >> direction. People stressed about the commit process can relax with >> confidence. This will protect the code base from premature work flow >> changes until we have an understanding of what we want. No harm is done >> by deferring workflow changes until we as a team are prepared to deal >> with them. >> >> Cons: This is not the Apache way. People who are trying to bulldoze >> the PX4 work flow into the repositories will hate the idea. Mentors >> will hate the idea. An approach more consistent with the Apache way >> would just be to let the chaos prevail. That is fine with me too as >> long as we do not let PX4 advocates take away our group right to define >> our own workflow. We can still just put all workflow changes on hold >> until we have the requirements in hand. >> >> I am not pushing anything. Think about it and let me know what you >> would like to do. > > I agree with this because it is premature to change the way we work > before there is a documented workflow that helps us understand what to > do. > > Over the next two weeks, we should focus on designing the top-down > workflow. It doesn't have to be final and it doesn't have to be > perfect. We can improve it over time. But right now it's not ready, > so I appreciate Greg's offer to do that, while the workflow is prepared. > > Thanks to Greg and everyone, > Nathan
Re: Single Committer
+1 Verstuurd vanaf mijn iPhone > Op 24 dec. 2019 om 06:07 heeft Nathan Hartman het > volgende geschreven: > > On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt wrote: >> >> Recent events have made me reconsider some decisions I made. I threw >> off the single committer mantle when I saw the abuse of privilege in the >> repositories. If the PPMC agrees to it, I will take up that role again. >> >> But let's be frank. Here is what I think that means: >> >> * I would be sole committer of changes. The repositories would have >>to be treated as read-only just as back in the Bitbucket days. >> * I would grandfather in the i.MXRT changes. >> * I will decline all workflow related changes until workflow >>requirements are established (that is my only real motivation for >>suggesting this: To make certain that we have proper requirements >>in place before we accept PX4 workflow into our repositories. We >>need to do this right and I am willing to protect the repositories >>until the workflow requirements are established. I expect that to >>take about two weeks.) >> * I would create a dev branch and expect all PRs to be against that >>dev branch. >> * As soon as the PPMC is confident that it has the processes in place >>to handle the commit workload I will gladly relinquish this role. >> * THIS IS NOT THE APACHE WAY. This is an interim dictatorship role to >>expedite the avalanche of commits expected after the holidays. >> >> If any of this concerns people, please "Just Say No." I am not married >> to the idea and I am not forcefully advocating it. This is what people >> wanted me to do a few days ago and if I can protect our right to define >> the workflow, then I will do it. For me it is a sacrifice that I would >> take with no pleasure in. >> >> Pros: This will provide project continuity until the PPMC is fully >> functional. Having workflow requirements will be a huge step in that >> direction. People stressed about the commit process can relax with >> confidence. This will protect the code base from premature work flow >> changes until we have an understanding of what we want. No harm is done >> by deferring workflow changes until we as a team are prepared to deal >> with them. >> >> Cons: This is not the Apache way. People who are trying to bulldoze >> the PX4 work flow into the repositories will hate the idea. Mentors >> will hate the idea. An approach more consistent with the Apache way >> would just be to let the chaos prevail. That is fine with me too as >> long as we do not let PX4 advocates take away our group right to define >> our own workflow. We can still just put all workflow changes on hold >> until we have the requirements in hand. >> >> I am not pushing anything. Think about it and let me know what you >> would like to do. > > I agree with this because it is premature to change the way we work > before there is a documented workflow that helps us understand what to > do. > > Over the next two weeks, we should focus on designing the top-down > workflow. It doesn't have to be final and it doesn't have to be > perfect. We can improve it over time. But right now it's not ready, > so I appreciate Greg's offer to do that, while the workflow is prepared. > > Thanks to Greg and everyone, > Nathan
Re: Power Management on the L432KC
Thank you I will look into it! Verstuurd vanaf mijn iPhone > Op 24 dec. 2019 om 00:05 heeft Gregory Nutt het > volgende geschreven: > > >>> I want to use the STANDBY mode in Power Management in the Nucleo-L432KC. >>> Now I am reading that in the STM32 Power Management is implemented. >>> >>> What is the best way to get this working for the L432KC? I see that in arch >>> there are some power routines implemented. The standby register settings >>> "look" ok. >>> >>> Say I want to trigger (event when power fails and "line" is pulled down) it >>> sets the Nucleo in "STANDBY" so my RTC is still "OK". And the coin battery >>> (CR2032) kicks in... >>> >>> Then I want it to get back "ALIVE" again when I put a rising edge on WKUP1 >>> (PA0) event... >>> >>> How could I best tackle this? >> >> Use the NuttX PM (Power Management) subsystem. Search through the boards >> defconfig files for CONFIG_PM for some very simple examples. There is no >> real documentation (only this >> http://www.nuttx.org/doku.php?id=documentation:pmreport). More real world >> usage is more complex. I don't believe that there is any defconfig for the >> STM32L4 family so that will be an interesting challenge > > There might be something useful to you in this post: > https://groups.google.com/forum/#!searchin/nuttx/power$20management|sort:date/nuttx/1q7jIsrRW5I/wOhaPYDwAAAJ > >
Power Management on the L432KC
A content question (I think this is possible?) . I want to use the STANDBY mode in Power Management in the Nucleo-L432KC. Now I am reading that in the STM32 Power Management is implemented. What is the best way to get this working for the L432KC? I see that in arch there are some power routines implemented. The standby register settings "look" ok. Say I want to trigger (event when power fails and "line" is pulled down) it sets the Nucleo in "STANDBY" so my RTC is still "OK". And the coin battery (CR2032) kicks in... Then I want it to get back "ALIVE" again when I put a rising edge on WKUP1 (PA0) event... How could I best tackle this? Thanks. Ben
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Did you look at https://www.atlassian.com/nl/software/crucible ?? And: https://www.perforce.com/solutions/static-analysis https://www.atlassian.com/git/tutorials/comparing-workflows The concept "The Centralized Workflow" was the "old" workflow, but now maybe the concept "Feature branching" is maybe a way to go? Say there are people working on "features" in Nuttx? Drivers, Kernel, Apps, etc?? Or is "Gitflow" already" choosen? Ben Op ma 23 dec. 2019 om 20:27 schreef Justin Mclean : > Hi, > > > Brennan created a page in the Confluence for the workflow document. I > > know that only committers can edit the Confluence wiki directly but > > that is not a problem: Anyone can write some text and email it to this > > list, and a committer can edit it into the Confluence page. > > Non committers can also ask for access. > > Thanks, > Justin >
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
+1 keep it simple Verstuurd vanaf mijn iPhone > Op 23 dec. 2019 om 17:06 heeft Sebastien Lorquet het > volgende geschreven: > > OK. > > That is too much email for me, I just cant follow and understand all these > discussions anymore. Almost 300 messages among multiple overlapping threads > full > of heated opinions in 2-3 days is insane. > > I just cant dedicate enough time reading any more of this. I have other things > to do than trying to understand these multiple rebooted workflows proposals > that > span days (and nights!) of discussions. > > So I can't vote on anything. I dont understand what is going on anymore. I'm > lost. Probably not important since I did not ask and choose to be a committer, > but since opinions are asked, here are mine. > > > Can someone please sum up what we have to decide in a short email, less than > a page? > > > To be honest, viewed from here, I just seem to understand that some opinions > are > very pushy and are trying to act before decisions are settled. > > Also some kind of extra-heavy decisions on a full process NO ONE has been able > to install up to now for years. > > I just want to say that going to apache should not be an occasion to try to > force the process of someone liking or another just because not everyone has > an > equally stronger opinion and voice and free time for emails. > > On my part, seeing too hard pushes in any specific direction just rings an > alarm > bell to be extra-cautious. > > > I think the process should be as simple as possible, and improved later. Just > select the absolute bare minimum that could start to work and discard > everything > else so this project can work again. > > > We are using git so things are reversable, right? We will not get this right > the > first time, so lets keep room for errors. If I understand correctly the > bitbucket repositories are still in a consistent pre-apache state and the > apache > ones can be reset? or is the apache->bb mirroring already active? > > Also, I did not see a notification that the BB repositories had been frozen. > > > These workflow and reviewing discussions are just killing extremely valuable > time for everyone without visible progress (because too many messages). > > > So again, I would like to read a very short state of the union at monday > 2019-Dec-23 17:01 UTC+1. > > Otherwise I cant make decisions. And I guess I am not the only one. > > > Sebastien > > >> Le 22/12/2019 à 17:25, Gregory Nutt a écrit : >> >>> Let's get everyone's thoughts on the table >> >> I suppose that we should keep the discussion for 72 hours then call the >> vote. >> We need to allow time for everyone to comment and with the holidays, we may >> not be able to get good feedback. Should we still call a vote if people are >> not participating? >> >> I will call the vote on your behalf in 72 hours. >> >> Greg >> >> >> >
Re: Testing the new repository
Thats what I stated from day 1. Maybe its an idea to come up with a plan / roadmap so people can see whats going on and what has to be done and which issues are there... lead people . now its grey and shady over A) expertise B) progress their in the dark now? These mails are giving back uncertainty? I thought Apache would bring in their workflow and automated tooling and experience with these projects? But now it seems that the Nuttx/Bitbucket workflow was not that bad. it worked from 2007... so how bad was it really? Oké only Greg as master committer was a SPOF... but could be fixed also right? Maybe Apache can chip in to come with suggestions? I personally think that there are people who still believe in the greatness of Nuttx but are waiting for a good progress and more solid and stable choices? And maybe people want to help out but are not in a position to do so? And the license switch could bring uncertainty also for some? I can only say that change is always good, but it gives insight and insight gives change!! So I hope you all find a solution to maybe a minor problem Nuttx was already a succes, just needs some automation and it has the same problems in CI/CD like every large project in C in teams at other big firms..?? Thats where Apache could cone to the rescue? As a big software deployer? Maybe this articles gives one some ideas: https://proandroiddev.com/how-to-set-up-an-efficient-development-workflow-with-git-and-ci-cd-5e8916f6bece Heads up and keep believing! Maybe I should not share my thought, but like most of us I do not care what other people think :-) I am just concerned.. A spectator Ben Verstuurd vanaf mijn iPhone > Op 22 dec. 2019 om 02:34 heeft Gregory Nutt het > volgende geschreven: > > >>> Can we do that for the PR that David created? (I mean applying it on >>> bitbucket and I bring it to github) >> >> It would takes some agreement to do that. But I don't want to do that >> either anymore. The more I think about not having to apply patches >> everyday, the better I feel about it. I feel liberated. So I don't really >> want to do that at all anymore. It is the PPMC's responsibility to manage >> the workflow, not mine. It is better that way. > > Related thoughts: > > I did tell the IPMC before the project was voted in there would be a > knife-edge transition: The day that the Apache repositories are created > would be the day that I stop updating Bitbucket and turn over full > responsibility of the changes to the PPMC. > > Despite some confusion, I have met that commitment. There have been no > further changes to Bitbucket and the PPMC now has full responsibility for the > disposition of changes. > > There is essential no change activity in the project. Normally there are > might be 50 changes per week, but I think that there were only 6 last week. > That is good and bad. It is good because I don't see any reason for the PPMC > to fear it is going to overwhelmed by changes in the near future. > > It is bad because I interpret this to mean that people have lost confidence > in the project and are just no longer submitting changes. There could be > other reasons, but if it is due to lack of confidence that would be an > indication that the project is being damaged by the lack of coordination. > >
Re: Testing the new repository
+1 And the patch is the same format and put on this mail address just like when we were in the Google Group? Verstuurd vanaf mijn iPhone > Op 21 dec. 2019 om 12:30 heeft Xiang Xiao het > volgende geschreven: > > Hi all, > I would suggest that we still follow the original process before the > new workflow is ready which mean that: > 1.We post the patch to dev@nuttx.apache.org or > 2.Send the pull request to https://github.com/apache/incubator-nuttx > 3.Only Greg can commit the patch to apache/github repo > I am seeing that PMC member is starting to create the branch in the > offical repo as they see the needed. > If we don't control this situation, we will have dozen(even hundred) > of branches in the offical repo soon. > These random named and created branches just confuse people who clone the > repo. > It's important to keep the original workflow and ensure all patches > reviewed and committed by Greg before the automation tool is ready. > > Thanks > Xiang > > >> On Sat, Dec 21, 2019 at 5:59 AM Alan Carvalho de Assis >> wrote: >> >> Hi Guys, >> >> We you can see the new repository is working fine. >> >> I submitted the i2C driver for STM32G070/NUCLEO-G070RB that was added >> to bitbucket. >> >> As a rules of thumb, please don't commit directly to the "master". >> >> I created a brash called "stage" that we could use before merging in >> to "master", this way other will have the chance to review. >> >> BR, >> >> Alan
Re: [CALL for TOP Down workflow Requirements]
You would like te see some REQuirements would be addressed by some DevOps thoughts.. but C/C++ are still challenging here. And then the principle: automate where you can! ( https://www.google.nl/amp/s/devops.com/devops-challenges-c-c-projects/amp/) Also one would like that the code to be tested (also hacktesting) through something like SonarCube. Release gates, Ring based deployments, DTAP, Feature Flags, etc... all ideas to use or to look at? Nuttx in the Cloud? Ben Verstuurd vanaf mijn iPhone > Op 21 dec. 2019 om 08:56 heeft Brennan Ashton het > volgende geschreven: > > On Fri, Dec 20, 2019, 11:22 PM David Sidrane wrote: > >> All, >> >> Please help flesh this out. >> >> Proposed Workflow Requirements (REQ) and Derived Requirements (DREQ) >> >> REQ1) master is branches of apps and nuttx have to always build >> REQ1.1) ALL development work is done on branches. >>DREQ1.1.1) master is branch protected prevention pushes to it. >> >> REQ2) git bisect shall always be able to build master of the project at >> every commit. >> DREQ2.a) merges to master may use squash commits from a PR when >> atomic commits are needed to insure REC2. >> DREQ2.b) merges to master may use rebase commits from a PR when NON >> atomic commits will for insure REC2. >> >> REQ3) Submissions shall be PRs against branches typically master. But PR >> shall be accepted against other branches. >> (i.e netlink_crypto) >> REQ3.1) naming conventions shall reflect lineage: >> REQ3.1.a) naming conventions of branches shall be in the form >> _ >> master_pr-add_imxrt20, netlink_crypto-pr-bugfix_AES >> REQ3.1.b) submissions affecting multiple repos shall use the same >> branches name on all repos. >> DREQ3.1.b.1) CI shall test multiple repos by branch name >> > > I would like to loosen up the branch naming requirements, it will make it > harder for people to contribute little things coming from the "GitHub" > world, it's not something I see too much outside of the workplace. Also the > generated branches on GitHub from a PR are using the ids. I'm not trying > to bring tooling in, but I think we should be aware of this and I think it > brings minimal gain. I would be more in favor of the title or body of a PR > doing the linking if we really need the standard to link things together. > We need to be very sensitive to increases in complexity or we will loose > new contributors. > > > >> >> REQ4) committer may collaborate on branches. >> >> REC5) While PR's are preferred, patches may be accepted. >> DREC5.1) Committers receiving patches shall apply them to a new branch >> (per REQ3) and open a PR. >>REC5.1) Committers shall attribute work to the person submitting patch >> >> REC6) All PR requires a review. >> DREC6.1) the project shall publish a list of subject experts >> REC6.1) Request for review shall be made via email to subject experts or >> PPMC. >> REC6.1.1) Multiple reviewers shall be required on OS internals. >> REC6.1.2) Multiple reviewers may be required on NON OS internals. >> >> >> David > > > The rest sounds good. I would say let's start minimal and work up if we > find quality or complexity issues. > > --Brennan
Re: Apache NuttX website
+1 Verstuurd vanaf mijn iPhone > Op 21 dec. 2019 om 08:27 heeft David Sidrane het > volgende geschreven: > > +1 > > -Original Message- > From: Brennan Ashton [mailto:bash...@brennanashton.com] > Sent: Friday, December 20, 2019 8:54 PM > To: dev@nuttx.apache.org > Subject: Re: Apache NuttX website > > Could we create the repo for the website. > http://www.apache.org/dev/project-site.html > > The one I created is based off the Jekyll template as discussed here. > https://incubator.apache.org/guides/sites.html#publishing_your_website
Re: Away for two weeks
?? Apache has backup right? I thought ruling out one person failure was the reason for bringing it to Apache ?? Or am I mistaking here? The PMC and ASF can chip in ? Maybe I am getting it wrong. Have a good holiday then Justin! Verstuurd vanaf mijn iPhone > Op 21 dec. 2019 om 02:07 heeft Justin Mclean het > volgende geschreven: > > H, > > I’m off on a two week break, while I’ll have some time to answer questions, > where I'm going for the first week has limited internet access, no mobile > phone reception and no mains electricity. I may be able to check messages > once a day so I may be slow in responding to any questions that need mentor > help, hopefully your other mentors will be able to fill in as needed. > > Thanks, > Justin
Re: Testing the new repository
This looks progress!! Good job!! Verstuurd vanaf mijn iPhone > Op 20 dec. 2019 om 23:10 heeft Alan Carvalho de Assis het > volgende geschreven: > > On 12/20/19, Gregory Nutt wrote: >> >>> We you can see the new repository is working fine. >>> >>> I submitted the i2C driver for STM32G070/NUCLEO-G070RB that was added >>> to bitbucket. >>> >>> As a rules of thumb, please don't commit directly to the "master". >>> >>> I created a brash called "stage" that we could use before merging in >>> to "master", this way other will have the chance to review. >> >> That seems like a good sense. Except aren't you creating a workflow >> definition from thin air. I suppose that is natural in a vaccum -- even >> thin air is more substantial than a vacuum -- but we really need to >> define such rules in a workflow requirements document. >> > > Hehehe, I agree! > > It is better to have a minimum logic sequence to follow before the > workflow get defined. Otherwise the chaos will reign. I'm open to > suggestions. > > I think now we are feeling that things are moving to Apache project. > > BR, > > Alan
Re: [DISCUSS - NuttX Workflow]
Maybe one can make a roadmap and milestones when we can expect things getting back to “normal”. What is who doing and what has to be done? Maybe its better to write a getting started guide how to contribute? Making patches, code conventions, etc etc Ben Verstuurd vanaf mijn iPhone > Op 18 dec. 2019 om 22:41 heeft Justin Mclean het > volgende geschreven: > > Hi, > >> We never had a Getting Started guide. We need one. And because it's so >> hard for someone "in the know" not to assume knowledge, we may need >> the help of some total n00bs to get this guide written -- to see where >> they get stuck and waste time looking for answers, and write those >> things in the guide. But that's a subject for another thread. > > I can probably help there, being the total n00b that is :-) I’ve not used > Nuttx but have some RTOS experience. I’m also a part time teacher. > > Thanks, > Justin >
Re: [Test] Joined
[Test] Joined Verstuurd vanaf mijn iPhone > Op 10 dec. 2019 om 01:00 heeft david.sidr...@gmail.com het volgende > geschreven: > > [Test] Joined > > Is it alive? > > David
Re: [TEST] Joined
It seems alive.. Verstuurd vanaf mijn iPhone > Op 10 dec. 2019 om 01:11 heeft Alan Carvalho de Assis het > volgende geschreven: > > David, > > I think if we still doing it here, Apache people will think we are Nut! > > Hehehe > > BR, > > Alan > >> On Monday, December 9, 2019, wrote: >> [TEST] Joined >> >> Hi Group, >> >> Is this thing live yet? >> >> *David Sidrane* >> >> >> *david.sidr...@gmail.com * >>
Re: [Test] Joined
Reply Verstuurd vanaf mijn iPhone > Op 10 dec. 2019 om 00:37 heeft Abdelatif Guettouche > het volgende geschreven: > > Reply if you get this message. > > Thanks.
