May 16, 2024, 12:27:54 PM

Recent posts

Pages1 2 3 ... 10
#1
STMP1 / Re: Olimex STMP1 SOM - Error s...
Last post by Gaël - Today at 11:45:25 AM
So, should I create a new thread ?
#2
A20 / Building u-boot for A20-OLinuX...
Last post by luimarma - Today at 10:34:19 AM
Hello,

I am trying to compile u-boot for the A20 Olinuxino micro with emmc, for the current Bullseye image with olimex 5.10.180-olimex kernel.
The reason is to avoid some drivers checking and speed up booting.

I have started just compiling with the default configuration, but the resulting u-boot is not applying the overlays in /boot/uEnv.txt

The procedure I have followed is the next one:

I have downloaded the source from here, https://github.com/OLIMEX/u-boot-olinuxino
Next applied the following commands to set the default config and compile.

#make CROSS_COMPILE=arm-linux-gnueabihf- distclean
#make CROSS_COMPILE=arm-linux-gnueabihf- clean
#make CROSS_COMPILE=arm-linux-gnueabihf- A20-OLinuXino_MICRO-eMMC_defconfig
#make CROSS_COMPILE=arm-linux-gnueabihf-

And finally to install the new u-boot and make sure that all is consistent, I did the following.
copy u-boot-sunxi-with-spl.bin to /usr/lib/u-boot-olinuxino/a20-olinuxino/u-boot-sunxi-with-spl.bin
#u-boot-install /dev/mmcblk0
#/usr/sbin/update-initramfs -u
#/etc/kernel/postinst.d/uboot-fit 5.10.180-olimex

When booting with the new u-boot the board boots, but I no longer see the overlays reflected at uEnv.txt loading, before I could see the following output after the FIT image overlays:

   Loading Kernel Image
   Loading Ramdisk to 49781000, end 49fffdd6 ... OK
   Loading Device Tree to 49772000, end 49780490 ... OK
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/spi1-spidev.dtbo'...
408 bytes read in 5 ms (79.1 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/spi2-spidev.dtbo'...
408 bytes read in 7 ms (56.6 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-can.dtbo'...
732 bytes read in 8 ms (88.9 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-i2c0.dtbo'...
722 bytes read in 6 ms (117.2 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-i2c1.dtbo'...
726 bytes read in 8 ms (87.9 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-i2c2.dtbo'...
726 bytes read in 5 ms (141.6 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-spi0.dtbo'...
1001 bytes read in 6 ms (162.1 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-spi1.dtbo'...
1005 bytes read in 7 ms (139.6 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-spi2.dtbo'...
1005 bytes read in 5 ms (196.3 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart3.dtbo'...
863 bytes read in 6 ms (139.6 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart4.dtbo'...
867 bytes read in 5 ms (168.9 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart5.dtbo'...
867 bytes read in 6 ms (140.6 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart6.dtbo'...
867 bytes read in 8 ms (105.5 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart7.dtbo'...
867 bytes read in 7 ms (120.1 KiB/s)

Starting kernel ...

[    0.006145] /cpus/cpu@0 missing clock-frequency property
[    0.006201] /cpus/cpu@1 missing clock-frequency property

But now only the following:

   Loading Kernel Image
   Loading Ramdisk to 49781000, end 49fffdd1 ... OK
   Loading Device Tree to 49772000, end 49780490 ... OK

Starting kernel ...

[    0.006245] /cpus/cpu@0 missing clock-frequency property
[    0.006302] /cpus/cpu@1 missing clock-frequency property

With stock u-boot and compiled one I can see the uEnv.txt loading BTW.

Boot script loaded from mmc
Checking for /uEnv.txt...
Checking for /boot/uEnv.txt...
1210 bytes read in 2 ms (590.8 KiB/s)
Loaded environment from /boot/uEnv.txt

What am I missing?

Thanks in advance,

Luis
#3
ESP32 / Re: ESP32-WROOM-32E-N8 - LoRa8...
Last post by Steff - Today at 10:30:28 AM
Yes it works  ;D

My Code is based on https://github.com/lnlp/LMIC-node and i'm using platform.io in VSCode.
Thanks to LubOlimex this post directed me in the right direction https://forum.mcci.io/t/olimex-mod-lora868/264

Created /include/HalConfig.h
Code Select
// HalConfig.h

#ifndef _HalConfig_h_
#define _HalConfig_h_

#include <arduino_lmic_hal_configuration.h>

class MyHalConfig_t : public Arduino_LMIC::HalConfiguration_t {

public:
    MyHalConfig_t();
    virtual TxPowerPolicy_t getTxPowerPolicy (TxPowerPolicy_t policy, int8_t requestedPower, uint32_t frequency) override;
};

#endif
then created src/HalConfig.cpp
Code Select
// HalConfig.cpp

#include <arduino_lmic_hal_configuration.h>
#include "HalConfig.h"
#include "Boards.h"

#define LMIC_FORCE_POWER_POLICY Arduino_LMIC::HalConfiguration_t::TxPowerPolicy_t::RFO

// Init
MyHalConfig_t::MyHalConfig_t(){};

// Override getTxPowerPolicy
Arduino_LMIC::HalConfiguration_t::TxPowerPolicy_t MyHalConfig_t::getTxPowerPolicy (
    Arduino_LMIC::HalConfiguration_t::TxPowerPolicy_t policy,
    int8_t requestedPower,
    uint32_t frequency
) {
    LMIC_API_PARAMETER(policy);
    LMIC_API_PARAMETER(requestedPower);
    LMIC_API_PARAMETER(frequency);

    #ifdef LMIC_FORCE_POWER_POLICY
        return LMIC_FORCE_POWER_POLICY;
    #endif

    // default: use PA_BOOST exclusively
    return Arduino_LMIC::HalConfiguration_t::TxPowerPolicy_t::PA_BOOST;
};

Create src/baords/sbc_olimex_v1.h (copy from bsf_ttgo_lora32_v1.h)
I've changed the definitions, added include and myHalconfig and changed the pinmap
Code Select
#pragma once

#ifndef BSF_SBC_OLIMEX_V1
#define BSF_SBC_OLIMEX_V1

#include "config.h" // from packages/toolchain-xtensa-esp32
#include "LMIC-node.h"

#define DEVICEID_DEFAULT "sbc-olimex-v1"  // Default deviceid value


#ifndef LMIC_CLOCK_ERROR_PPM
    #define LMIC_CLOCK_ERROR_PPM 0
#endif   

// https://forum.mcci.io/t/olimex-mod-lora868/264/2
#include "HalConfig.h"
static MyHalConfig_t myHalConfig{};

const lmic_pinmap lmic_pins = {
    .nss = 5,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 21,
    .dio = {26, 33, 32},
    .rxtx_rx_active = 0,
    .rssi_cal = 10,
    .spi_freq = 8000000,
    .pConfig = &myHalConfig
};

// nothing changed after this.
platformio.ini
Code Select
[platformio]
default_envs =
  sbc_olimex_v1 ;added new

[common]
lib_deps =
  olikraus/U8g2 ;even if there is no oled. make sure it is included. Otherwise i got compiling errors - OLED display library

[esp32]
build_flags =
-D hal_init=LMICHAL_init


[env:sbc_olimex_v1]
platform = espressif32
board = upesy_wroom
framework = arduino
upload_speed = 921600
monitor_speed = ${common.monitor_speed}
lib_deps =
${common.lib_deps}
${mcci_lmic.lib_deps}
build_flags =
    ${common.build_flags}
    ${esp32.build_flags}
    ${mcci_lmic.build_flags}
    -D BSFILE=\"boards/sbc_olimex_v1.h\"
    -D MONITOR_SPEED=${common.monitor_speed}
    -D LMIC_PRINTF_TO=Serial   
    -D USE_SERIAL

There are a lot of other configs in the platformio.ini. I reduced it to the changes and important things.

I hope I didn't forget anything  ???
#4
ESP32 / Re: ESP32-gateway...different ...
Last post by LubOlimex - Today at 08:19:45 AM
There are major changes between those two revisions.

> i installed mini lcd in both units to pin 11-12-13-14 and i connect pins 12 to 9....in revision E it's correct work, but in revision G no...

GPIO9, GPIO10, GPIO11 in revision E shouldn't be used in first place since they are connected to the internal memory. In newer revision they were completely re-routed from the headers so that you can't affect the memory. Probably one of these two major changes affect your work:

- GPIO6-11, which are used by the ESP32's internal flash, were disconnected from CON1 and the 6 SD card signals are now routed instead for use when SD card is not present;
- SD card changed from 4-bit mode of operation to 1-bit mode of operation! Added 3 NA resistor pads (R9-R11) for backwards compatibility.

You can find full revision changes and track the changes that occured from revision E to revision G here:

https://github.com/OLIMEX/ESP32-GATEWAY/blob/master/HARDWARE/README.md
#5
ESP32 / Re: ESP32-WROOM-32E-N8 - LoRa8...
Last post by LubOlimex - Today at 08:11:50 AM
Did it work? If yes, and if and when you have the time can you make a short post with description and maybe code on how you get it working. That would be helpful for a lot of people. The problem we face with the LoRa boards is that we don't have any public TTN network anymore in our town to help us test (we used to have a couple of such points, but they are no longer operational).Thank you in advance.
#6
PIC / TCP/IP Stack Lite: PINGs Quit ...
Last post by kc25chief - May 15, 2024, 07:35:27 PM
Disclaimer: I'm new to Olimex and Microchip's current line of toolset and chipsets beyond PIC12 and PIC16s using Assembler and not XC8.


I have created a short little program Targeted to the PIC-WEB PIC16F67J60 Ether PHY mirco using the TCP/IP Stack Lite using the latest most up to date everything in the toolchain and plugins to just do two things;

1. Toggle an onboard the onboard Red LED
2. simply reply to a 'PING' request via the PIC18F67J60 Ethernet PHY peripheral.

There are 2 Methods in which I 'blink' the onboard LED:
Method 1. from a RTC interrupt once a second.
Method 2. from the main() white(1) loop;.
Results:

With Method 1: when I Ping, both 'ping' replies and an LED 1-Second Toggle occurs just as expected- no problems.

With Method 2: when I place the LED toggle in the while(1) loop of the main() function; the LED toggles just fine- Very fast of course. However, the 'Ping' replies cease to occur and I get a timeout on the requester.

Can someone please give me some insight what is going on? Maybe the Network_Manage() call is getting 'starved for attention' and dropping out, but that seems crazy because the toggle should be only 1 instruction execution amount of time; in the nanoseconds range.

I have also tried a 'dummy function' for the led blink which is a simple delay bypassing the physical toggle of LED also achieving 'Request timed out.'.  I find this baffling and also lowering my confidence with the whole out-of-the-box solution.

Thanks in advance for any insights you may have,
KC Chief
#7
ESP32 / ESP32-gateway...different revi...
Last post by luca1978 - May 15, 2024, 02:50:49 PM
i have 3 unit:

-1 unit....esp32-gateway revision E (works correctly)
-2 units...esp32-gateway revision G (not works)

i installed mini lcd in both units to pin 11-12-13-14 and i connect pins 12 to 9....in revision E it's correct work, but in revision G no...

can you help me?

best regrads
Luca
#8
ESP32 / Re: ESP32-WROOM-32E-N8 - LoRa8...
Last post by Steff - May 15, 2024, 02:34:24 PM
Thank you so much LubOlimex. You are a hero.

Sorry for not reading all the details in your first post.
#9
UEXT / Re: Changing I2C address of MO...
Last post by ilario - May 15, 2024, 11:55:06 AM
QuoteYou need to power down the board, close jumper PROG, power up the board then issue the change address command, then power down the board, then open the jumper PROG and finally power and check new address.

Thanks for the clear instructions!

QuoteAre you sure it is on I2C port 1? It can be I2C 0 or 2?

Yes, using i2cset I can open and close the relay using port 1 (which is UEXT).

Interestingly, I can open and close the relay regardless if the PROG was closed or not (changing the state of PROG jumper, then powering up the MOD-IO2 and then running the i2cset command).

I replicated all of this on two MOD-IO2 boards.

QuoteSure you can try modio2tool, there is explanation on how to compile and use:
https://github.com/OLIMEX/OLINUXINO/tree/master/SOFTWARE/UEXT%20MODULES/MOD-IO2/linux-access-tool

Ok!
I tried to use the precompiled one and it gave an unexpected error:

Code Select
# chmod a+x ./modio2tool
# ./modio2tool
bash: ./modio2tool: No such file or directory
but then I realized that it was because it was the 32 bit executable and I am on A64-Olinuxino so it is a aarch64 platform so I compiled it with "make" and now it works :)

Before trying with modio2tool, I checked its source, and noticed that it was using an undocumented 0xF0 data address, and that this address was used also in the firmware in the OLIMEX.h file:
Code Select
#define SET_ADDRESS    0xF0
So I tried to add the data address 0xF0 to the i2cset command, and it worked :D

unplug power
close PROG jumper
plug power
i2cset 1 0x21 0xF0 0x22
unplug power
open PROG jumper
plug power
and now the MOD-IO2 has address 0x22

I double checked that if the PROG jumper is open it does not work, and it does not, as expected.

So I would suggest the following changes in the documentation:

In MOD-IO2 user manual revision E:

page 13, section 2.4.2 replace

Code Select
i2cset 2 0x21 0xHH
with

Code Select
i2cset 2 0x21 0xF0 0xHH
page 19, section 5.6.1 remove the whole section. From my tests it does not look like the PROG jumper has that described function.

In the readme of the firmware version 4.3:

page 11, section 4.10 correct as above including 0xF0.

Thanks!



#10
ESP32 / Re: ESP32-WROOM-32E-N8 - LoRa8...
Last post by LubOlimex - May 15, 2024, 10:53:01 AM
If you are using Olimex LoRa868 - you need to check your software for the state of PA_BOOST. Did you disable PA_BOOST mode in the library? Again check here:

https://forum.mcci.io/t/olimex-mod-lora868/264/2
Pages1 2 3 ... 10