ferrous-systems / embedded-trainings-2020 Goto Github PK

https://github.com/ferrous-systems/embedded-trainings-2020/blob/master/beginner-workshop/src/radio-puzzle.md links to the heapless toplevel examples.

They do not contain examples on how to create an IndexMap. Navigating to https://docs.rs/heapless/0.5.5/heapless/struct.IndexMap.html provides you with examples to build a FnvIndexMap.

Quick examples inline would be useful to avoid frustrating people when constructing their first datastructure.

Try this instead:

    let mut port = serialport::new(&dongle.port_name, 115200).open()?;
    port.set_timeout(Duration::from_millis(10))?;

    static CONTINUE: AtomicBool = AtomicBool::new(true);

    // properly close the serial device on Ctrl-C
    ctrlc::set_handler(|| CONTINUE.store(false, Ordering::Relaxed))?;

    let stdout = io::stdout();
    while CONTINUE.load(Ordering::Relaxed) {
        let mut read_buf = [0u8; 8];
        match port.read(&mut read_buf) {
            Ok(n) => {
                let mut stdout = stdout.lock();
                stdout.write_all(&read_buf[..n])?;
                stdout.flush()?;        
            }
            Err(e) if e.kind() == std::io::ErrorKind::TimedOut => {
                // Go around
            }
            Err(e) => {
                println!("Error: {:?}", e);
                break;
            }
        }
    }

I am working my way through the beginner's course, and going well so far.

In section 3.4 (and slide 9 of the PDF slides), it says that asm::bkpt() will generate a stack backtrace.

This doesn't work for me. It seems that I have to do an asm::udf() to get a backtrace.

Is that right? Does the training material need to be updated?

The "Code Organization" section of the advanced course workbook here:

https://embedded-trainings.ferrous-systems.com/code-organisation.html

does not match the actual content of the GIT repo here:

https://github.com/ferrous-systems/embedded-trainings-2020/tree/main/advanced

Does the workbook need to be updated?

https://embedded-trainings.ferrous-systems.com/get-descriptor-config.html

2nd paragraph:

A GET_DESCRIPTOR Configuration request is a GET_DESCRIPTOR request where the descriptor type encoded in the high bit of wValue is CONFIGURATION.

The value of CONFIGURATION is 2, but never mentioned.

error:

  = note: ld: framework not found IOKit
          clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
``

from #128

rust-analyser now expands the #[entry], decides that it doesn't result in a fn main() and therefore doesn't offer the run button anymore.

We need to remove references to the run button from the training.

You seem to have two options:

1. Debug in VS Code, where you can single step, but you can't see the defmt log.
2. Run probe-run on the console where you can see the defmt log but you can't single step.

Just stumbled iver this in a training.
I think the point was that you should reject messages with a languageID != 0 because only string descriptors have language IDs

Both USB-3 and USB-4 require implementation of GET_DESCRIPTOR request:

https://github.com/ferrous-systems/embedded-trainings-2020/blame/master/embedded-workshop-book/src/data-stage.md#L11

https://github.com/ferrous-systems/embedded-trainings-2020/blame/master/embedded-workshop-book/src/supporting-standard-requests.md#L5

Only USB-4 needs it.

reasoning:

• seems to have irritated several participants
• more context switches in an already tool-heavy environment

we can still encourage people to look at the usb references if they want to practice using a spec

Please include within:
https://embedded-trainings.ferrous-systems.com/installation.html

The following Visual Studio Code Linux Setup steps:
For debian stable/unstable:

curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > packages.microsoft.gpg
sudo install -o root -g root -m 644 packages.microsoft.gpg /etc/apt/trusted.gpg.d/
sudo sh -c 'echo "deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/packages.microsoft.gpg] https://packages.microsoft.com/repos/vscode stable main" > /etc/apt/sources.list.d/vscode.list'
sudo apt-get update
sudo apt-get install code

usb-2-solution differs from usb-3, which is much simpler.

https://github.com/ferrous-systems/embedded-trainings-2020/blob/master/advanced/firmware/src/bin/usb-2-solution.rs#L48-L64

https://github.com/ferrous-systems/embedded-trainings-2020/blob/master/advanced/firmware/src/bin/usb-3.rs#L52-L56

This has been a source of confusion in several trainings, as U8 is pretty hard to distinguish from u8, especially when everything is new. Explicitly using consts::U8 makes it more clear that this is not a type, but a constant

https://embedded-trainings.ferrous-systems.com/setup-stage.html doesn't mention that DEVICE = 1 according to table 9-5 of the usb spec; TODO fix that

I'm in section 3.9.1 of the beginner course. When I run radio-send.rs, the course book says I should see the LQI on the serial-term output from the loopback app running on the dongle. This is true, but I also get the CRC of the message, which is not expected. The book says I should see

received 5 bytes (LQI=49)

But what I actually get is

received 5 bytes (CRC=Ok(0xdad9), LQI=62)

Does the book need to be updated?

Quote @japaric from internal chat:

right now the workshop uses the log crate + core::fmt (uncompressed, uncolored logs).
because the workshop also demoes cargo-embed and cargo-flash (which don't support defmt) the board support crate in the workshop material needs to support both log and defmt. I think adding a Cargo feature to the dk board support crate to switch between log and defmt would be the way to go here.

(+1 to that)

from the workshop matrix channel:

Christoph Siedentop he/him

I would love some help. : https://gist.github.com/siedentop/33db9d1e0025aeb6f38ac8bbce11d050
I went through the beginner workshop. Did the radio-puzzle exercise. I am doing something illegal, and I only get log output for half the program. It never prints the "END" log message.
I managed to reduce the issue to this. And I suspect that some how the u8 as char conversion breaks. BUT why don't I get a proper error / crash / etc?

jschievink

[...] try putting a delay between the logger calls (or logging less in general)

@japaric @Mirabellensaft
imo we should add a section about that in the hints channel. any objections?

... after knurling-rs/probe-run#108 makes its way into a crates.io release of probe-run AND
the version of cargo-flash and cargo-embed we recommend to install are both using probe-rs v0.10 (that'd be cargo-flash 0.10.1 and cargo-embed 0.10.0)

https://github.com/ferrous-systems/embedded-trainings-2020/blob/master/beginner-workshop/src/building-programm.md

has a bottom section that introduces "sections" (a term that may be unknown) and a lot of other jargon (ISA, etc.). This should either be more thoroughly explained or sectioned (e.g. by a headline "In detail") off for people that are new to handling binaries - maybe both :).

I am following the course workbook. I just finished the "General purpose tools" section at the end of section 1.2 "Installation Instructions."

It seems that the versions of these tools have moved on a bit...
probe-run is now at v0.2.6
flip-link is now at v0.1.5
nrfdfu is now at v0.1.2

1. Are these versions known to work OK with the rest of the course?
2. Should section 1.2 be updated to reflect those newer versions?

All the best, Rod Chapman, Director, Protean Code Limited

from #128 :

some renaming could be done to make things clearer, e.g. cargo xtask dongle output (or dongle logs) instead of serial-term. This can also be used to group commands, e.g. dongle-flash would become cargo xtask dongle flash so all dongle related tasks live under the dongle namespace

This issue is closed if:

• tools have been given m,ore useful names where necessary
• tools have been grouped where necessary
• mdbook sections that call these tools have been updated

While reading the Windows instructions for setup I noticed the details only cover the DK.

/installation.html#windows-only-zadig-jlink-driver

Students of this workshop are expected to use a dongle as well. Reading the Linux instructions it seems that the ID is 1915 521f.

/installation.html#linux-only-usb

Here it is in Zadig based on that:

It's unclear if this should be done for the Dongle based on the lack of instruction here.

in the past some participants had issues with micro-usb cablöes that turned out to be charging-only. the handbook should have some warning about this, maybe in https://embedded-trainings.ferrous-systems.com/preparations.html?highlight=cable#required-hardware ?

from the matrix chat:

On fedora for libudev dependency in the tools dir, systemd-devel must be installed.

I kind of skipped the flashing part, does it make sense to talk about what flashing is, that it happens as part of running it out of VS Code, but leave out the command, for simplicity?

we've had a workshop participant using https://github.com/sleighluxoft/ferrous_workshop who experienced trouble getting a full usb connection to the nrf DK:

root ➜ /workspaces/ferrous_workshop/embedded-trainings-2020/advanced/firmware (main ✗) $ cargo run --bin usb-2
   Compiling usb v0.0.0 (/workspaces/ferrous_workshop/embedded-trainings-2020/advanced/common/usb)
   Compiling firmware v0.0.0 (/workspaces/ferrous_workshop/embedded-trainings-2020/advanced/firmware)
    Finished dev [optimized + debuginfo] target(s) in 1.23s
     Running `probe-run --chip nRF52840_xxAA target/thumbv7em-none-eabihf/debug/usb-2`
  (HOST) INFO  flashing program (34.05 KiB)
  (HOST) INFO  success!
────────────────────────────────────────────────────────────────────────────────
INFO:usb_2 -- USB: UsbReset @ 159.655883788s

it might be worth investigating this if we have more participants using Docker in the future

I'm getting this error while trying to compile the hello.rs following instructions from https://embedded-trainings.ferrous-systems.com/building-program.html .

note: master has been renamed to main; still exists as not to break the repo for participants who cloned it in the old state but should be deleted soon-ish to avoid confusions or branch inconsistencies

NOTE:
last batch of workshops is on fr 24th july ; don't delete the branch before that!

I think the switch to mdbook broke our section links. for example, see https://embedded-trainings.ferrous-systems.com/supporting-standard-requests.html

Hi,

I started following the training material, up to the point where to flash the dongle.

This relies on nrfutil, and failed. Long story short, it turns out that using pip install nrfutil from a Python 3.9 setup (using Homebrew) fetches nrfutil 5.2.0, which is targeting Python2. Here is the corresponding issue in the pc-nrfutil repository.

I opened this issue in case someone else also encounter this problem. Maybe you want to update the training material while this situation exists?

Anyway, I like the course up to now, thank you for your work! ❤️

from #128

This issue is closed if:

• cargo xtask dongle-flash(with no arguments) prints all the valid hex files that can be flashed
• mdbook sections that call these tools have been updated

#145 introduces a temporary dependency on a git version of serialport to fix a macos deprecation. Once the PR over there is merged:

• revert dependency back to upstream
• delete local clone https://github.com/ferrous-systems/serialport-rs-hotfix

In "data stage": https://embedded-trainings.ferrous-systems.com/data-stage.html

Note that the device descriptor is 18 bytes long but the host may ask for fewer bytes (see wlength field in the SETUP data). In that case you must respond with the amount of bytes the host asked for. The opposite may also happen: wlength may be larger than the size of the device descriptor; in this case your answer must be 18 bytes long (do not pad the response with zeroes).

This paragraph seems to be confusing, I got multiple questions on it.

One confusion was as to why we are allowed to cut the response, if the host asked for more.

In src/hello-world.md, it says to "open the src/bin/hello.rs file from the advanced/apps folder" but there is no "apps" folder below "advanced"

Should that be "advanced/firmware" instead?

so that participants wondering why they can't instantiate a thing get a hint right where the problem is (I think it's mentioned in the book already)

Hi, I'm leaving this here in case anyone else is running into the same issue. I have not found much while googling.

Problem: Using cargo run --bin hello from within the beginner/apps folder finishes compiling and starts up probe-run. But then I get the following:

Running `probe-run --chip nRF52840_xxAA target/thumbv7em-none-eabihf/debug/hello`
(HOST) WARN  (BUG) location info is incomplete; it will be omitted from the output
Error: AP ApAddress { dp: Default, ap: 0 } is not a memory AP

The LED5 next to the FTDI chip on the DK goes off for a split second but no program is flashed.

Solution: It seems like my nRF52840-DK was shipped with the MCU in some kind of protected state. Using nrfjprog from the nRF command line tools you can run nrfjprog --recover which makes the MCU exit this state and programming etc. using probe-run works fine again.

On the bottom of the DK board, there is a coin cell battery 3v CR 2032.
There's a plastic tab underneith I assumed for shipping WHICH IS NOT THE CASE.

What I read is THE PLASTIC TAB SHOULD REMAIN
when the computer is connected to the DK with the usb 2.0 type A to micro-usb type B male cable
for programming it.

The board connectors surrounding the coin cell battery are unfamiliar to me.
I don't want to break the board while trying to remove the battery.
Does anyone know how to safely remove/insert that coin cell battery
without damaging the DK board? After removing that battery, I would safely remove the plastic tab and preserve it for future DK programming. I found no such guidance within the DK documentation nor within this workbook. I believe it should be provided in order to prevent damaging the DK.

Thank you for listening.

Good day, Firstly thank you for making the course materials available to wanna-be embedded rust developers. I purchased the required hardware from "Symmetry Electronics, part of TTI Semiconductor Group"

nRF52840 Development Kit for nRF52840 wireless SoC
https://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=94949
High-end Bluetooth 5/Thread/802.15.4/ANT/2.4GHz multiprotocol SoC
https://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=94964

I believe the DK requires this cable USB 2.0 Type A Male to Micro-USB Type B Male:
Hi-Speed USB Device Cable A Male / Micro-B Male, 1 m (3 ft.), Black
https://www.accessotronik.com/product_p/307161_m119.htm

Also it would be nice to see a picture of the entire setup with the board and dongle for others to follow easier.

it is expected that they are familiar with Cargo, the syntax and built-in operators like match. They should not need to be familiar with more rust-specific / advanced concepts like lifetimes, the borrow checker or generic code.

tasks:

• add test it to the setup page
• recommend reading some of the first chapters of the "The Rust Programming Book" or point to some other of the resources.

Q. should we also mention this in the course description so people can assess if they feel comfortable taking part?

we're not using cargo-embed anymore, do we still need it?

I noticed the 'DK' board implementation uptime function is broken and the uptime runs in double time. This is caused by the overflow interrupt being triggered twice. Here's a proposed patch that fixes it for me:

old handler:

#[interrupt]
fn RTC0() {
    let curr = OVERFLOWS.load(Ordering::Relaxed);
    OVERFLOWS.store(curr + 1, Ordering::Relaxed);

    // clear the EVENT register
    unsafe { core::mem::transmute::<_, RTC0>(()).events_ovrflw.reset() }
}

my replacement code (that checks whether the overflow bit is set):

#[interrupt]
fn RTC0() {
    unsafe {
        let rtc = core::mem::transmute::<_, RTC0>(());

        if rtc.events_ovrflw.read().events_ovrflw().bit_is_set() {
            OVERFLOWS.fetch_add(1, Ordering::Relaxed);
            rtc.events_ovrflw.reset()
        }
    }
}

mainly opening this for myself so I don't forget to look into this:

➜  dongle git:(main) ✗ cargo xtask serial-term
    Finished dev [unoptimized + debuginfo] target(s) in 0.19s
     Running `/Users/lottesteenbrink/ferrous/embedded-trainings-2020/xtask/target/debug/xtask serial-term`
(waiting for the Dongle to be connected)

when I run serial-term, it doesn't seem to recognize my dongle. usb-list doesn't show it either. Either I broke something in my setup or this is a regression

participants have run into ownership & referencing/dereferincing/slice-ifying problems while re-using our use of str::from_utf8() in the past. I'm wonderin if that#s an unncessary roadblock and it'd make more sense didactically just use as char for now, even though it's not the 100% safest option

from the WS matrix chat:

Christoph Siedentop he/him

Thanks!
BTW, is it a known defect in the instructions for the "blinky.rs" code, where the loop behavior changes significantly if you remove the logging?
Reproduce: 1) Set the timer to 20ms, (2) Keep log statement, (3) run, (4) observe the LED blinking rapidly but after a while start to "stutter" and blink much less frequently?. (5) Remove the log statement (in the loop), (6) run again, (7) Observe consistent blinking
This is obvious to me that it would happen. It's just not mentioned in the docs, and 20ms is the threshold where you can still see the blinking, so I guess a lot of people would observe this.

jschievink

probably not intended