I am trying to build custom Micropython firmware with ethernet support for STM32F407VE. I've forked working board without ethernet support and trying to modify it with ethernet support.
Things I have done:
defined MICROPY_HW_ETH_* variables in mpconfigboard.h
added MICROPY_PY_LWIP = 1 to mpconfigboard.mk
added ETH_* pins to pins.csv
added additional pins from Port F, G, H, I to pins.csv
Here is my modified board: https://github.com/untitledlt/BLACK_F407VE
Now when I'm trying to build it, i get:
In file included from eth.c:31:
eth.c: In function 'eth_mac_init':
eth.c:163:106: error: implicit declaration of function 'STATIC_AF_ETH_RMII_REF_CLK'; did you mean 'STATIC_AF_ETH_RMII__REF_CLK'? [-Werror=implicit-function-declaration]
mp_hal_pin_config_alt_static(MICROPY_HW_ETH_RMII_REF_CLK, MP_HAL_PIN_MODE_ALT, MP_HAL_PIN_PULL_NONE, STATIC_AF_ETH_RMII_REF_CLK);
^~~~~~~~~~~~~~~~~~~~~~~~~~
pin_static_af.h:42:48: note: in definition of macro 'mp_hal_pin_config_alt_static'
mp_hal_pin_config(pin_obj, mode, pull, fn_type(pin_obj)) /* Overflow Error => alt func not found */
^~~~~~~
cc1: all warnings being treated as errors
make: *** [build-BLACK_F407VE/eth.o] Error 1
What am I doing wrong here?
There was a bug (typo) in Micropython branch.
ETH_RMII__REF_CLK should be replaced with ETH_RMII_REF_CLK in ports/stm32/boards/stm32f405_af.csv file.
It's already fixed by https://github.com/micropython/micropython/pull/5308.
All Credit goes to Mike Causer.
Thanks, Mike!
Related
I have to work with RIOT OS and currently I'm testing out how everything
works (or not work).
Info: RIOT OS is a IOT OS which run on mircocontrollers and arms.
I develop under Debian with Eclispe, the develop environment was setup after the GitHub Guide from RIOT. The Guide
The hello world example works for me without problems.
Now I want to load some of the RIOT modules and then I get errors.
That's what I did so far.
I created a new folder for my project, copy the hello-world example and
adjust the makefile.
Then I adjust the riot project properties like in the guide, just for my example.
Created the new symbol and include xml and imported them.
Re-indexed the riot project
Changed the basic hello world code with my example code.
Try to build it....
This is my example main, it doesn't do much, just init a gpio pin.
#include <stdio.h>
#include "periph/gpio.h"
int main(void)
{
gpio_t pin = GPIO(1,22);
gpio_init(pin,GPIO_OUT);
return 0;
}
And this is the makefile for it
# name of your application
APPLICATION = test
# If no BOARD is found in the environment, use this default:
BOARD ?= nucleo-f303
# This has to be the absolute path to the RIOT base directory:
RIOTBASE ?= $(CURDIR)/../..
# Comment this out to disable code in RIOT that does safety checking
# which is not needed in a production environment but helps in the
# development process:
DEVELHELP ?= 1
# Change this to 0 show compiler invocation lines by default:
QUIET ?= 1
FEATURES_REQUIRED = periph_gpio
include $(RIOTBASE)/Makefile.include
By building the project I get following errors:
In english it would be something like:
- the rule for target "path" failed.
- the rule for target "link" failed.
- make: [link] error 2
- make(1): ["path/main.o"] error 1
This is the part in the riot makefile where the error happen.
Its exactly the same in both file (Makefile.include and Makefile.base).
I hope anybody can me explain what I did wrong or where are my mistakes.
EDIT:
The problem was GPIO() was wrong... its called GPIO_PIN() thats cause the error.
I am new to Linux Kernel Development and I want to implement a Char device driver which handles Port expansion using a MCP23017 with a RaspberryPi (Raspbian Wheezy) using C.
A control for port expansion (MCP23017) is required. A less of a driver in the true sense, but more with porting functions in a driver.
The module is addressed via I2C. I need to implement the following functions in the driver:
· Configuration of the I2C address
· Configuration of the IOs
· Configuration of Pull-Ups
· Configuration of interrupts
· Read / write the IOs
It is important that up to 8 modules can be opened/operated simultaneously (8 is the max. possible number of addresses of the block).
I have seen a number of examples in the internet and implemented a simple char device driver with init, open, read and write functions and also tested I2C operations for MCP23017. I have got a brief idea about a device driver but don't know how to further implement the functions.
I would like to know/clarified about the following:
How does the dev_open work? How can I try to open a device through a linux command and check if the device is opened/ the number of times the device is opened through dmesg command?
I want 8 different modules to be opened simultaneously using the device driver and the Configuration of the MCP23017 IOs, Pullups and Interrupts. How is it done?
Errors:
/home/pi/i2c_gpio/mcp23017.c: In function ‘mcp23s08_direction_input’:
/home/pi/i2c_gpio/mcp23017.c:269:9: error: implicit declaration of function
‘gpiochip_get_data’ [-Werror=implicit-function-declaration]
struct mcp23s08 *mcp = gpiochip_get_data(chip);
/home/pi/i2c_gpio/mcp23017.c: In function ‘mcp23s08_probe_one’:
/home/pi/i2c_gpio/mcp23017.c:615:11: error: ‘struct gpio_chip’ has no
member named ‘parent’
mcp->chip.parent = dev;
/home/pi/i2c_gpio/mcp23017.c:681:2: error: implicit declaration of
function ‘gpiochip_add_data’ [-Werror=implicit-function-declaration]
status = gpiochip_add_data(&mcp->chip, mcp);
^
I'm implementing the ad hoc AODV routing protocol on ARM based system Sabrelite http://boundarydevices.com/products/sabre-lite-imx6-sbc/ ......... After configuring and building the kernel that match to the one used on the board. I get the following errors:
error: unknown type name '__kernel_ulong_t'
__kernel_ulong_t loads[3]; /* 1, 5, and 15 minute load averages */
error: unknown type name '__kernel_ulong_t'
__kernel_ulong_t totalram; /* Total usable main memory size */
^
/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi/usr/include/linux/sysinfo.h:18:2: error: unknown type name '__kernel_ulong_t'
__kernel_ulong_t freeram; /* Available memory size */
^
error: unknown type name '__kernel_ulong_t'
__kernel_ulong_t sharedram; /* Amount of shared memory */
^
/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi/usr/include/linux/sysinfo.h:28:22: error: '__kernel_ulong_t' undeclared here (not in a function)
char _f[20-2*sizeof(__kernel_ulong_t)-sizeof(__u32)]; /* Padding: libc5 uses this.. */
^
make: * [nl-arm.o] Error 1
As the errors suggested, it is something along with the cross compilation source tree but i don't know how on earth i get those errors because the used SDK works perfectly.
I followed the tutorial cited in the README file provided by AODV packages..
Has anyone ever experienced implementing AODV on ARM ? and did they got these errors
How can i resolve these issues ?
Thanks
well, the solution was to properly upgrade the makefile to work for post 2.6 kernel. If you happen to read this page: write your makefile like this:http://lwn.net/Articles/21823/
How to set the property of sink pad in program
for example:
sin_00::outWidth=1280 sin_00::outHeight=720 in this way pipeline was run using gst-launch-0.10 .....
And to set this property Ive used gst_pad_set_property() API but its not working
it shows following error :
3_video_temp.c: In function 'main':
3_video_temp.c:551: warning: implicit declaration of function 'gst_pad_set_property'
/tmp/cc2zDbzt.o: In function `main':
/home/project/compWorkspace/Edubeam/3_video_temp.c:551: undefined reference to `gst_pad_set_property'
collect2: ld returned 1 exit status
make: *** [all] Error 1
Please tell how to set that value as soon as possible.
If the pads have properties (like the pads in videomixer has), you just use g_object_set like you would with any property, so something like:
g_object_set (pad, "width", 1280, NULL);
Most pads don't have properties. width and height are usually negotiated via caps that are set on buffers and pads.
What version of GStreamer do you have installed on your system? Quickly check using:
gst-inspect --version
Where did you find a doc or example for gst_pad_set_property()? I just searched for gst_pad_set_property in /usr/include/gstreamer-0.10/gst/* on my Linux development system and came up empty-handed. But when I search through the latest source snapshot for GStreamer, the function appears. This leads me to believe you might be looking at docs or examples for an in-development version of GStreamer that has new convenience APIs not seen in earlier versions (I have run into similar problems on occasion).
Exactly what property are you trying to set on the sink pad?
In my CRC8.c I have this function:
BOOL isCRCValid(const UINT8 *ptr, UINT8 Len, UINT8 CRCChar){
return CRCChar == generateCRC(ptr, Len); //generareCRC returns a UINT8
}
It's is declared in CRC8.h, but PC Lint returns me the following.
Info 714: Symbol 'isCRCValid(const unsigned char *, unsigned char, unsigned
char)' not referenced
Info 830: Location cited in prior message
Help says 714 is:
714: Symbol 'Symbol' (Location) not referenced -- The named external
variable or external function was defined but not referenced. This
message is suppressed for unit checkout (-u option).
and 830 is:
830 Location cited in prior message -- Message 830 is a vehicle to
convey in 'canonical form' the location information embedded within
some other message. For example, consider the (somewhat simplified)
message:
file x.c line 37: Declaration for 'x' conflicts with line 22
This contains the location ("line 22") embedded in the text of the
message. Embedded location information is not normally understood by
editors and IDE's (Interactive Development Environments) which can
only position to the nominal location (line 37 in this example). By
adding this additional message with the nominal location of line 22
the user can, by stepping to the next message and, in this case, see
what the 'conflict' is all about. This message and message 831 below
do not follow the ordinary rules for message suppression. If they did
then when the option -w2 was employed to turn the warning level down
to 2 these messages (at level 3) would also vanish. Instead they
continue to function as expected. To inhibit them you need to
explicitly turn them off using one of:
-e830
-e831
They may be restored via +e830 and +e831; they state of suppression
can be saved and restored via the -save -restore options. Options such
as -e8* and -e{831} will have no effect.
As I'm newbie with PC Lint, and relative newbie with C, I'm not achieving resolving this problem.
Can anyone help me with this problem?
The message simply means that PCLint didn't find anything that actually uses this function, so it could be dead code/candidate for removal.
It could also mean that you did not use the input arguments in your function.