Re: Problems and a bug in samd2l2 ADC code
Hi Bernd, On 11/3/20, Bernd Walter wrote: > On Mon, Nov 02, 2020 at 03:09:12PM +0100, Bernd Walter wrote: >> On Mon, Nov 02, 2020 at 10:17:41AM -0300, Alan Carvalho de Assis wrote: >> > This should be a better idea because you will have 32KB of RAM. They >> > after getting it working you can remove not necessary features to >> > eventually get it working reliable on 16KB RAM. > > Ok - on the Zero and with predefined config (plus options to enable ADC and > the workarround for the include files), it works. > Have to see if the problem just didn't appear or if it is somehow related > to my setup. > Great! Nice to hear that it works on Arduino Zero board! Now you can "strip" your config! :-D BR, Alan
Re: IP Clearance
On Wed, Oct 14, 2020 at 9:54 AM Matias N. wrote: > > The scripts are still in a draft PR, they were not merged. I was waiting for > confirmation for others to test. > The remaining issue was about the ability to deal with files in submodules. > Right now it just errors out. > I will see I can add an option that could help with this or if the old > submodules can be used to retrieve the missing data. > Either way, I can also document it in Documentation/ > > After that I can remove the draft and you can merge it. I think the PR was merged already? Correct me if I'm mistaken. Is there some kind of minimal HOWTO for our IP clearance process? If not, as a community we should collaborate to make one, preferably a simple document that explains how to use the tool and basic steps. That should be integrated into the documentation so that new volunteers who want to earn a commit bit can come forward and help. Earlier in this thread, I wrote: > 1. Integrate license clearing with ongoing work like we are already doing for > nxstyle, *AND* > > 2. Ongoing calls for non-coders to participate (license clearing, > documentation, artwork, marketing), *AND* > > 3. Seek funding and/or corporate support to pay for professional license > clearing and Matias added: > Maybe the fourth point would be to distribute the load to committers? I think > that in the end > we should collectively realize of the importance of this task in order to > guarantee this project > stays afloat. If point (3) is to be pursued and you agree that (4) should be > a fallback then (3) > should have some kind of deadline, otherwise we will be waiting for too long > until it is too late. somehow as a project we all have to make progress on this, so that we can move forward and graduate from the Incubator. If we have a HOWTO I can start doing a little bit each day, like I have been doing for nxstyle. If everyone joins in, we will start making progress... Nathan
Re: Problems and a bug in samd2l2 ADC code
Hi Bernd,
Did you disable the serial console?
CONFIG_NO_SERIAL_CONSOLE=y (Device Drivers -> Serial Driver Support ->
Serial console (No serial console) ).
BR,
Alan
On 11/3/20, Bernd Walter wrote:
> On Tue, Nov 03, 2020 at 03:34:46PM +0100, Bernd Walter wrote:
>> On Mon, Nov 02, 2020 at 03:09:12PM +0100, Bernd Walter wrote:
>> > On Mon, Nov 02, 2020 at 10:17:41AM -0300, Alan Carvalho de Assis wrote:
>> > > This should be a better idea because you will have 32KB of RAM. They
>> > > after getting it working you can remove not necessary features to
>> > > eventually get it working reliable on 16KB RAM.
>>
>> Ok - on the Zero and with predefined config (plus options to enable ADC
>> and
>> the workarround for the include files), it works.
>> Have to see if the problem just didn't appear or if it is somehow related
>> to my setup.
>
> Wow - that was very unexpected.
> I've stripped my code to nearly nothing.
> Stack sizes had been restored to original NuttX values
> board_app_initialize did (almost) nothing.
> My main only called boardctl(BOARDIOC_INIT, 0); and then in config_init()
> It hang in stat because of a broken inode table.
>
> This is my config_init btw:
> static
> void
> config_init()
> {
> #ifdef HAVE_W25
> FILE *f;
> ssize_t len;
>
> struct stat st;
> if (stat(CONFIGFILE, &st) == 0) {
> len = st.st_size;
> f = fopen(CONFIGFILE, "rb");
> if (f != NULL) {
> syslog(LOG_NOTICE, "json reading %d bytes\n", len);
> char *data = malloc(len + 1);
> if (data != NULL) {
> len = fread(data, 1, len, f);
> if (len >= 0) {
> data[len] = '\0';
> } else {
> free(data);
> data = NULL;
> }
> }
> fclose(f);
>
> if (data != NULL) {
> syslog(LOG_NOTICE, "json data read: %s\n",
> data);
> json_config = cJSON_Parse(data);
> free(data);
> }
> }
> }
> #endif
> if (json_config == NULL) {
> syslog(LOG_NOTICE, "reseting json config\n");
> json_config = cJSON_CreateObject();
> }
> }
>
> Nothing fancy - HAVE_W25 was set, but the mounting code in
> board_app_initialize() disabled.
>
> And then there it was, the only thing left in board_app_initialize():
> printf("test\n\r");
>
> I do not have a console and obviously stdio wasn't linked to /dev/null.
> This wasn't a problem on my other console less board using older NuttX, but
> with memory corruption I also just might have been lucky.
>
> Is there any example on how to link /dev/null?
>
> --
> B.Walter http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>
Re: Problems and a bug in samd2l2 ADC code
On Wed, Nov 04, 2020 at 06:56:50PM -0300, Alan Carvalho de Assis wrote: > Hi Bernd, > > Did you disable the serial console? > > CONFIG_NO_SERIAL_CONSOLE=y (Device Drivers -> Serial Driver Support -> > Serial console (No serial console) ). [194]nuttx-devel> grep CONSOLE contrib/nuttx/.config # CONFIG_DEV_CONSOLE is not set # CONFIG_SERIAL_CONSOLE is not set Don't have that option avaiable. CONFIG_SERIAL=y This one is still enabled, although I think I don't need it. The board has no NuttX UART on the controller enabled. I do run SERCOM3 as UART, but because of strict Modbus/RTU timing in my own code. SERCOM0 is SPI for W25Q16 used with NXFFS SERCOM1 is I2C for FM24CL16 used for raw access SERCOM2 is disabled and no available pins to use it. SERCOM3 out of NuttX -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Re: sim target failures 10.0 branch
We still have a handful of outstanding bugs on the 10.0.0 release identified. If anyone wants to jump in a dig into one of them it would be much appreciated. Some of these failures we found this release have been around in previous releases and were only recently discovered, so it would be nice to get them closed out. https://github.com/apache/incubator-nuttx/issues?q=is%3Aissue+is%3Aopen+label%3Areleases%2F10.0.0++label%3Ablocker --Brennan On Sat, Oct 24, 2020 at 4:34 PM Brennan Ashton wrote: > > In preparation for cutting the release I started running all of the > simulation targets before digging into more hardware testing. There > were quite a few failures, it is possible that some are environment > related, in which case we should document them better, but some look > like clear bugs. I would like to see these addressed or at the very > least acknowledged before we cut the release. > > https://github.com/apache/incubator-nuttx/issues?q=is%3Aissue+is%3Aopen+label%3Areleases%2F10.0.0++label%3Ablocker > > You can also see my testing sheet here: > https://docs.google.com/spreadsheets/d/1qMQV_CSN5Ka13_wr73QNo2Uh-NiSumjcwINuc0BkyIs/edit?usp=sharing > > I commit for the 10.1 release wiring up actual integration testing for > these so we have better automation validation beyond just "it > compiles" > > --Brennan
