[riot-devel] RIOT OS port for the icoBoard FPGA board - icoSoC / picorv32 RISC-V platform

[Tomas Styblo]

Hi guys,
so far it's only an experiment, but I've started porting RIOT OS to the
icoBoard Lattice FPGA / icoSoC / picorv32 RISC-V softcore CPU platform.

The Lattice chip used on the icoBoard is probably the only FPGA device
supported by open source tools. And it will be the first FPGA device
supported by RIOT OS (AFAIK)

RIOT OS already supports the HiFive E310 RISC-V MCU, but that is a very
different piece of hardware with RISC-V Privileged Architecture support.
Still I've been able to reuse some code chunks.

So far It's only an experiment (and I'm a newbie at this!), but all the
important features already work, including shell over UART. It is really
fascinating to be able to use a tiny FPGA board this way.

If you are interested, you can find the (alpha, experimental!) code at:

https://github.com/tstyblo/RIOT-icoboard

It would make no sense trying to merge it into the mainline now, as the
code needs a lot of testing, comments and improvements. But I'd like to use
this opportunity to invite anyone interested in FPGA devices or in the
RISC-V platform to check it out.

Regards,

--
Tomas Styblo
tsty...@gmail.com
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] problem mounting littlefs

[Benjamin Valentin]

Hi,

Can you check if the issue is still present on the master branch?

There has been some rework on the MTD layer recently, the 
mtd_read_page() function used by littlefs should only return non-0 on error.


However, so should mtd_spi_nor_read() on the 2020.07 branch.


What is your setup? Are you using plain mtd_spi_nor or is there some 
mtd_mapper involved?



Best,

Benjamin

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Does the servo driver work on atmegas?

[Marian Buschsieweke]

Hi,

care to open an issue on Github for this? This sounds very much like a bug in
RIOT.

Could you also provide the board details. If you're using an out of tree board,
especially the clock configuration would be of interest.

Kind regards,
Marian

On Tue, 1 Sep 2020 21:58:32 +0200
Wouter Symons  wrote:

> Thanks for the quick response Marian!
> 
> > So, double check that you are using PWM_LEFT.  
> The servo driver uses PWM_LEFT hardcoded.
> 
> > Do you have an logic analyzer at hand to confirm the PWM output is correct? 
> >  
> Great idea! I had already tried checking the output with an oscilloscope 
> I had laying on my desk yesterday, and also tried to hook up a small 
> buzzer, and both more or less indicated that the output was fine. 
> However... I checked with a logic analyzer now, as per your suggestion, 
> and indeed... something is off: if I apply a PWM decoder to the output, 
> it gives me a duty cycle of 0.390221%. It varies slightly, but not by 
> much, and it is not sweeping like it should.
> 
> > Does the serve has any
> > requirements on the PWM frequency?  
> I tried an SG90 and an MG995 servo. Both require a 50Hz frequency 
> according to the datasheet. I adjusted this in the servo driver.
> 
> > this is because currently only the 8 bit timers are used for PWM. There are
> > also 16 bit timers that can be used for PWM, but those are not yet 
> > implemented.
> > I heard that @benpicco's avr-rss2 boards have an on-board LED connected to 
> > the
> > 16 bit PWM output - so he might jump on this and implement the missing 16 
> > bit
> > support ;-)  
> I might have a look myself if I can find some time to spare. However, 
> the project I'm working on also has its deadlines, so I might also just 
> cheat by ordering a I2C PWM controller breakout board instead.
> 
> 
> But I still find it a bit strange though. I quote @smlng on #10498: 
> "/Please note, that this finally brings in the missing PWM periph for 
> the atmega-based Arduinos/". It sounds like PWM should work just fine on 
> this board (unless RIOT handles arduino boards differently than 
> non-arduino boards with the same cpu, but that sounds unlikely). Why 
> would it suddenly not work anymore?
> 
> 
> Kind regards,
> 
> Wouter
> 
> 
> On 9/1/20 8:39 PM, Marian Buschsieweke wrote:
> > Hi,
> >  
> >> I was wondering if it is even possible at all. The current version of
> >> the PWM peripheral has its resolution limited to 256.  
> > this is because currently only the 8 bit timers are used for PWM. There are
> > also 16 bit timers that can be used for PWM, but those are not yet 
> > implemented.
> > I heard that @benpicco's avr-rss2 boards have an on-board LED connected to 
> > the
> > 16 bit PWM output - so he might jump on this and implement the missing 16 
> > bit
> > support ;-)
> >
> > Not that for ATmegas currently only PWM_LEFT is implemented, PWM_RIGHT and
> > PWM_CENTER won't work. So, double check that you are using PWM_LEFT.
> >
> > Do you have an logic analyzer at hand to confirm the PWM output is correct?
> > Otherwise, the brightness of an LED connected to the PWM output should also 
> > be
> > good indicator. (Don't forget to take into account that most ATmegas 
> > operate at
> > 5 V when choosing the resistor for the LED ;-)) Does the serve has any
> > requirements on the PWM frequency?
> >
> > Kind regards,
> > Marian
> >
> > On Tue, 1 Sep 2020 20:00:09 +0200
> > Wouter Symons  wrote:
> >  
> >> Hello all,
> >>
> >> I spent quite some time yesterday trying to get a servo working on an
> >> atmega1284p, unfortunately to no avail.
> >>
> >> I was wondering if it is even possible at all. The current version of
> >> the PWM peripheral has its resolution limited to 256. I think this
> >> limitation is probably the cause for it not working.
> >>
> >> I tried removing the asserts that enforce this limitation, and this
> >> caused the servo to rotate into one direction, but then stop moving
> >> again (I could not get it to rotate in the other direction).
> >>
> >> I tried the same servo on a nucleo-board and this worked just fine.
> >> However... only with a resolution way higher than 256. (Because STM32
> >> does not have this limitation)
> >>
> >> So I wonder... should atmega be blacklisted for this test, since it
> >> cannot work? And would there maybe be a workaround to this problem? I'm
> >> not that experienced on this matter, so I'm not really sure why the
> >> limitation on this resolution was put in place, but is it possible to
> >> make changes to the peripheral driver so we can increase it?
> >>
> >> It's also possible that I'm simply doing something very wrong, and that
> >> it should work without any changes. (hence the reason I asked on this
> >> mailing list instead of opening an issue straight away)
> >>
> >> Kind regards,
> >>
> >> Wouter
> >>
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> https://lists.riot-os.org/mailman/listinfo/devel  
> >
> 

[riot-devel] problem mounting littlefs

[Bert Thomas]

Hi all,

I am migrating from an old(er) version of RIOT to the 7-2020 version. I run 
into a problem mounting the littlefs filesystem.

At initialization function lfs_dir_fetch() is invoked. On line 448 of lfs.c the 
block is read into memory. The mtd function that implements this returns the 
number of bytes read, in my case that is 256 bytes. It appears to me that the 
following code considers this an "errorcode" where lfs_dir_fetch() is returning 
by the return on line 454. In lfs_mount() the return value is checked and 
causes  a goto to label "cleanup" where lfs_deinit() is invoked and the return 
value returned to the upper layer. In my application the error check fails as 
it only checks for negative values, but that is less important.

Is my analysis correct? How is it supposed to work?

Regards,
Bert
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel