I think that my question is a little bit dumb but i am really stuck in this problem.
I have an embedded SAMA5D27-SOM1-EK1 board which i build Linux OS image version 4.14 with YOCTO project.
Now i want to control a RBG LED using a push BUTTON existing both on the board.
They asked me to check for GPIO drivers if they are existing in my Linux Image, I don't know how to check, then to make the LED Lights when I push the Button.
For the moment i have only the PINS of the Led and the Button.
I don't know what i must do now.
Thank you for your help!
Related
I bought a new micro:bit v2 board, and want to add it to Scratch as an extension. I followed the 2 steps from https://scratch.mit.edu/microbit. The step 1 is ok, the led lights of my micro:bit board is flashing 5 characters "zepiv", but the step 2 failed.
The scratch link is running, and the bluetooth is enabled.
The os version is macOS Big sur 11.4(Mac mini late 2014), the bluetooth LMP version is 4.0(0x6).
The weird thing is that the board isn't visible to my Mac, but it is to my Android cell phone.
Is this a problem with my computer? Could anyone help me? Thanks in advance.
Good question, I had a lot of trouble with the same issue when connecting my LEGO MINDSTORMS EV3© to scratch. If you want to connect a device easily a good idea is to have it paired via Bluetooth already. To pair it with a mac:
Open the settings app
Select Bluetooth
Switch your micro:bit into pairing mode:
Hold down buttons A and B on the front of your micro:bit together. The front is the side with two buttons and the LED display. Keep the two buttons held down. Don’t let go of them yet!
While still holding down buttons A and B, press and then release the reset button on the back of the micro:bit. Keep holding down buttons A and B.
You should see “PAIRING MODE!” start to scroll across the micro:bit display. When you see this message start to appear you can release buttons A and B.
Eventually you’ll see a strange pattern on your micro:bit display. This is like your micro:bit’s signature. Other people’s micro:bits will probably display a different pattern.
(I found these instructions at this website)
In the Bluetooth menu, look for your micro:bit device and select Pair
After the device has paired, go back to scratch with scratch link activated, and attempt to connect to the device again.
This worked for me when I connected my EV3 device and I hope it helps you.
I am a software engineer working on a microcontroller system for a side project. The microcontroller I am using is the SparkFun ProMicro (based on the RP2040 board). I am trying to flash the board so that I can write data to the onboard flash memory.
All of the tutorials I have found online suggest starting in boot mode, dragging and dropping the UF2 file, and done!
When I do this, the microcontroller ejects from my computer. Is that meant to happen? It just reboots then doesn't reboot in bootloader?
Once I got MicroPython installed I moved on to writing and flashing code to the board.
I am using the Thonny IDE which identified the correct board (albeit the PICO), then saved the following file as main.py (taken from RPI foundation). It prints toggle, and I believe the output shows that it is being printed from the board, but the light on the board isn't blinking. (code and output below)
I considered that the pinout could be different from this board and the PICO, but some research shows they both use Pin 25 for the LED control.
All this leads me to believe I am on the right path, but I think I am missing something that is taken for granted in the tutorials. My end goal is to write arbitrary text data to flash storage, but I understand it can only take about 8000-10,000 writes before it becomes unreliable, so I want to test that I can write working code before I use some of those.
Is there something I am missing, or am I not thinking about this in the right way?
When I do this, the microcontroller ejects from my computer. Is that meant to happen? It just reboots then doesn't reboot in bootloader?
Yep.
but the light on the board isn't blinking.
Maybe your LED is busted, cause your code is right.
My end goal is to write arbitrary text data to flash storage
That's a terrible idea, unless you just like burning up boards for no good reason. Get an SD Card reader or concoct one out of a solution like this one, and use this sdcard library that will even mount your card, and add it to the syspath. Then you can essentially write all the arbitrary text data you like without burning up your RP2040.
Blinking this LED was harder than I expected. I ended up finding this sample code from AdaFruit and using the commented out neopixel code. The... bright side was that there was way more control over this led that I had realized.
Dont forget you have to add the neopixel.mpy from the bundle to your board.
With the RPi Pico W, you can now identify the led pin with "LED" instead of pin 25 (or another pin). This change is due to pin 25 being used for the Wifi chip on the Pico W. This works on Pico W as below
from machine import Pin
import time
led = Pin("LED", Pin.OUT)
while True:
led.toggle()
time.sleep(0.5)
I have verified this working on a RPi Pico W with MicroPython - using the unstable python version - rp2-pico-w-20220719-unstable-v1.19.1-181-gc947c2529.uf2.
I believe this is intended to become the standard way to access an on board led, since the port can be changed for different boards without changing source code.
That's not a simple LED connected to pin 25 on the Pro Micro RP2040 - it's a WS2812 RGB LED, sometimes called a NeoPixel. There's a one-wire protocol to drive these devices.
MicroPython has support for NeoPixel's built-in:
from machine import Pin
from neopixel import NeoPixel
pin = Pin(25, Pin.OUT) # set Pin 25 to output to drive a NeoPixel
np = NeoPixel(pin, 1) # create NeoPixel driver on Pin 25 for a single pixel
np[0] = (255, 0, 0) # set the first pixel to red (R, G, B)
np.write()
See the rp2 Quickref for more details.
I am a new STM32 user migrating from Atmel/Microchip's SAMD line.
I created my first project following along the tutorials here: https://www.youtube.com/watch?v=x_5rYfAyqq0&t=682s. It's a motor driver, with some other hardware shown outside of the screenshot below, but at the moment I am just trying to get statusLED to blink. I can successfully connect to the board with an STLink, when I press debug and resume, my LED will momentarily flash which I capture on video and scope, shown in the video here.
Strangely I don't lose connection to the board or anything, and my program continues to execute, but nothing else happens. As you can see from the code it's supposed to just blink every 500ms. Does anyone have an intuition as to what might be going on?
Here's a video showing the momentary flash (The LED is in the bottom right corner of the board and I press the debug/resume buttons off camera)
https://photos.app.goo.gl/BfGQbW1SX8EJT5eV8
I am using the internal clock for debug purposes, and only have Trace Asynchronous Sw debug + the statusLED set as GPIO output. My only added code is:
HAL_GPIO_WritePin (statusLED_GPIO_Port, statusLED_Pin,GPIO_PIN_SET);
HAL_Delay (500);
HAL_GPIO_WritePin (statusLED_GPIO_Port, statusLED_Pin,GPIO_PIN_RESET);
HAL_Delay (500);
Also here's the board schematic:
STM32F302R8 Board Layout
HAL_Delay depends on the SysTick interrupt being enabled and hooked up to the HAL.
You need to call HAL_Init() from main(), which in turn calls HAL_InitTick().
After that you need the function:
void SysTick_Handler(void)
{
HAL_IncTick();
}
The example projects in the STM32Cube package will include this.
if you configured your Hardware with CubeMX:
check your CubeMX configuration if your GPIO is set up correctly as "GPIO Output" in "Open Drain" oder "Push Pull" mode. According to the schematics "Open Drain" would be my recomendation, but Push Pull would also work.
One of my favourite mistakes is clicking one line to low in CubeMX, selecting "GPIO_Analog" for the pin instead of "GPIO_Output" and searching the code for a long time for a bug where there is none ;)
This turned out to be my having pulled up Boot0 with the intention of using a bootloader, and then forgetting about it. So I rotated my Boot0 resistor to be a pulldown and everything is working now.
Still unsure what configuration is going on to get the brief LED flash in the video, but definitely consider this resovled.
Hello everybody I am trying to make an STM USB HOST and taking some datas from keyboard and this data will show on LCD Panel.
But somehow I can't set the pins by using CubeMX. The program gives error when I try to open TFT-LCD properties after I opened USB HOST Mode. The program says the two features use the same pins.
Is it possible to open same properies at the same time?
Part numbers beginning with STM32F429I are in 176-pin packages that have enough pins to support both TFT and USB-FS at the same time. I've tried it in an empty project with a STM32F429IET MCU, the USB pins ended up on PA11 and PA12, and the TFT pins are all over the place (layout designers just love it). Now trying to find out what can cause the conflict. Clicking on PA11 reveals that the pin could be configured to LTDC_R4, but this function is assigned to PH10. Click on PA12, it could be configured to LTDC_R5, but this function is mapped to PH11. Of course, if you have set PH10 or PH11 before to some other function, then you have a problem.
Now I have a feeling that you are not designing hardware but trying to do stuff on an existing board. In this case, you can't define the pinout. Find the board schematics in the documentation, then work from there, assigning functions to pins according to their intended function. Trace the connections from the USB socket to the MCU to find out which pins are connected to it, then use the pin function mapping table in the datasheet to find out which USB controller can talk to it. Then activate that interface in CubeMX, and verify that it got mapped to the right pins. If not, you can hold down CTRL and drag it to the right place. Pin down the verified pins with the right mouse key, otherwise CubeMX will rearrange them at the hint of a conflict. When all pins are set, save a backup of the project as a baseline to return to when you start another software project on the same board.
A few Days ago my loved PC Mouse, a Razer Death Adder, died because of a rage attack of my boyfriend. So I decided to get a new one from Mad Catz, because why not trying ... A few days later I got her, a very nice Mad Catz R.A.T. PRO X.
I'm working with Unity 3D in the Version 4.0.0.0f. You may ask yourself why I'm not using the newest version? Answer is simple, I'm not allowed to, my University says all projects have to be done in the Version 4.0.0.0f.
Enough from the introduction... While testing a game I made, I pressed the DPI-Button on the R.A.T. and my character starts to constantly moving forward. It only stops if I leave the Screen and use for example my browser or another program or I restart unity completely.
I wrote a small script to show me what Buttons are pressed while I pressed the DPI-Button. It turns out that the following BUttons are Pressed if I press the DPI-Button:
JoystickButton6
Joystick1Button6
So I had a look in the Mad Catz Software and tried do define a custom Profile where the DPI-Button is simply a Shiftkey, the Software looks good but it had the same result in the game.
Is there any Unity 3D Developer with a Mad Catz R.A.T. PRO X with the same problem?
A simple Solution is to disable the Controller Driver of the Mouse.
It can be achieved by disabeling the driver in the computer management!