May 17, 2024, 08:07:32 AM

Recent posts

#1
ESP32 / Re: ESP-POE having problems wi...
Last post by djpeterlewis - Today at 01:49:00 AM
I did a test with another supplier of a board using WLED as well using the same settings on Ethernet and their board did not flash pixels. I was hoping it would have been the WLED software as it is a easier fix.

Can you guys look into it ?

I want to standardize my products using your board. So far I have over 100 boards and they all seem to give the same issue

Thank you
#2
ESP32 / Re: ESP32-gateway...different ...
Last post by luca1978 - May 16, 2024, 05:07:59 PM
ok, quindi non c'è modo di farlo funzionare? dovrei trovare due schede con revisione E?
#3
STMP1 / Re: Olimex STMP1 SOM - Error s...
Last post by LubOlimex - May 16, 2024, 04:07:01 PM
Yes, better create a new thread.
#4
STMP1 / Re: Olimex STMP1 SOM - Error s...
Last post by Gaël - May 16, 2024, 11:45:25 AM
So, should I create a new thread ?
#5
A20 / Building u-boot for A20-OLinuX...
Last post by luimarma - May 16, 2024, 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
#6
ESP32 / Re: ESP32-WROOM-32E-N8 - LoRa8...
Last post by Steff - May 16, 2024, 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
// 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
// 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
#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
[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  ???
#7
ESP32 / Re: ESP32-gateway...different ...
Last post by LubOlimex - May 16, 2024, 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
#8
ESP32 / Re: ESP32-WROOM-32E-N8 - LoRa8...
Last post by LubOlimex - May 16, 2024, 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.
#9
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
#10
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