Search results for:

Hi, we are interested in supporting wired networking (ethernet) on STM32 using the low-level ST ethernet driver package plus lwip (or similar). For example this might be on a nucleo board with built-in ethernet. Less interested in SPI or other add-on board solutions such as WIZnet.

Has anyone achieved this, or have any helpful pointers on steps required to enable?

Many thanks!

After a lot of messing about and reading the spec, I don't think it's possible to have the counter DIR bit change according to a simple high/low on another GPIO as required. The encoder mode of the timer is designed for a quadrature encoder.

I ended up with a little inline C to switch this bit according to GPIO input edge change like this:

const native=E.compiledC(`
  // void dir(bool)
  unsigned char *addr=(unsigned char *) 0x40010000;
  void dir(bool state) {
    *addr = (*addr & ~0b00010000) | (state * 0b00010000);
  }
`);

setWatch(native.dir, B7, {repeat: true, edge: "both", irq: true});

I'd now like to go further and handle step and direction (with direction being high/low signal on another gpio). Having trouble understanding how to translate the example given below into Espruino equivalent!

https://stackoverflow.com/questions/3294­7972/stm32-how-to-make-pulse-count-up-do­wn-with-timer

It just seemed to be easier to use 3 timers in the end because the register offsets are all the same, so I could write some generic code to initialise and read them etc.

I've put all the code on Github...

https://github.com/jugglingcats/pulse-co­unter

And the finished product :)

https://photos.google.com/share/AF1QipPR­R2cNrgRcmrWyI4HYQjqYQHJCvi22RbPz4kFwCmBi­TjG5c9GRKKNgFqNskFPdOA/photo/AF1QipPRH14­PQnJI4hWbzgJOrvier7nkeSc7_Tai5fFm?key=Sk­ZiSmFIYVd6U0tQbE83NldmRU9wbUdjUHhURjlB

Nearly done...

I got it all working - thanks!

Here is my code in case it's useful to anyone...

var DEFS={
  TIM1: {
    base: 0x40010000,
    pin: A8
  },
  TIM3: {
    base: 0x40000400,
    pin: B4
  },
  TIM4: {
    base: 0x40000800,
    pin: B6
  }
};

function init(tim) {
  const def=DEFS[tim];
  if ( !def ) {
    throw "Invalid timer!";
  }
  const BASE=def.base;
  
  // slave mode control register
  var SMCR = BASE+0x0008;
  // event generation register
  var EGR = BASE+0x0014;
  // Capture compare mode register
  var CCMR1 = BASE+0x0018;
  // Capture/compare enable register
  var CCER = BASE+0x0020;
  // counter
  var CNT = BASE+0x0024;
  // prescaler
  var PSC = BASE+0x0028;
  // auto reload register
  var ARR = BASE+0x002C;

  // enable PWM on A8 (TIM1 CH1)
  analogWrite(def.pin,0.5,{freq:10});
  // CC1E = 0 (Turn channel 1 off)
  poke16(CCER, peek16(CCER) & ~1);
  // CC1S[1:0]=01 (rising edge), IC1F[7:4]=0 (no filter)
  poke16(CCMR1, (peek16(CCMR1) & ~0b11110011) | (0b00000001));
  // CC1P=0, CC1NP=0 (detect rising edge), CC1E[0] = 1 (Turn channel 1 on)
  poke16(CCER, peek16(CCER) & ~(0b1011) | (0b0001));
  // SMS[2:0]=111 (ext clock), TS[6:4]=101 (CH1 as trigger)
  poke16(SMCR, (peek16(SMCR) & ~0b1110111) | 0b1010111);
  // Prescaler to 0 - use every transition
  poke16(PSC, 0);
  // auto-reload with the full range of values
  poke16(ARR, 65535);
  // poke the UG[0] bit to reset the counter and update the prescaler
  poke16(EGR, 1);

  return {
    get: function() {
      return peek16(CNT);
    },
    reset: function() {
      poke16(CNT, 0);
    }
  };
}

const TIM1=init("TIM1");
const TIM4=init("TIM4");
const TIM3=init("TIM3");

function update(){
  g.clear();
  g.drawString("Steps X: "+TIM1.get(), 2, 2);
  g.drawString("Steps Y: "+TIM4.get(), 2, 20);
  g.drawString("Steps Z: "+TIM3.get(), 2, 38);
  g.flip(); 
}

// SPI
var s = new SPI();
s.setup({mosi: B15 /* D1 */, sck:B13 /* D0 */});
var g = require("SH1106").connectSPI(s, B14 /* DC */, B10 /* RST - can leave as undefined */, function() {
  setInterval(update, 100);
});

setWatch(function(e) {
  TIM1.reset();
  TIM4.reset();
  TIM3.reset();
}, BTN, { repeat: true });

That's helpful Gordon thanks. Yes I am using the Pico.

So you think if I pick, say B6 and B7 (TIM4, CH1 and CH2 respectively), I should be able to do the same trick as you did with TIM1, just by looking up the relevant register addresses/offsets?

Hi, I read this page with interest: http://www.espruino.com/STM32+Peripheral­s.

I followed the "Counting edges" section and got it working - very happy.

I'd like to capture 3 inputs using this method. Is this possible using more channels on TIM1? Am not clear how pin A8 gets associated with TIM1 CH1 and how I'd do this for other pins. Any pointers would be appreciated.

EDIT: TL;DR
Completed project write up here: https://github.com/jugglingcats/pulse-co­unter

Thanks,
Alfie.

Hi @Wilberforce, here are my changes:

https://github.com/espruino/EspruinoTool­s/compare/gh-pages...jugglingcats:serial­-block-size

That's a good tip to use two output pins -- will try it!

I'll give it a go. I don't know how they do the 'trill' type sound when two notes are to be played together. I assume they alternate between the two notes very fast and setInterval may not be fast enough. Maybe this isn't how it's done but it doesn't sound like a proper chord. My music knowledge very limited!

I have a little piezo speaker hooked up to a Pico. I'd like to generate some simple 8-bit game-type sounds for it.

What I'd really like to be able to do is export sounds created on http://www.beepbox.co (they have JSON export) and add them to Espruino projects.

The sound would need to play in the background so I think this would need to be implemented as some kind of task, but beyond that am not sure where to start.

Any ideas appreciated!

I find mine crashes a lot too. Does anyone have any insight why it's so unstable? Is it issues with the Espruino port or something else. Does it depend on the specific board -- are some more stable than others.

Port 23 open is good -- the telnet port. You can add the IP in the Web IDE communications settings and it should connect. You'll find TCP a lot faster as your programs get bigger -- assuming your wifi is stable of course.

100% understand -- read your Makezine article... will try and stay out of your hair.

Hopefully things are working for you financially with the range of hardware you have and that having the other ports in the ecosystem at least adds some value.

Hi @Gordon I tried adding the call and it didn't cause any issues but didn't seem to help either - still seeing New interpreter error: FIFO_FULL. This is from the command line. Is there a way I can check if hardware flow control is being attempted?

You gave me an idea. At the moment I'm running webpack --watch in one terminal and espruino --watch in another. I could write a simple webpack plugin to run espruino CLI (or integrate with the lib) after each build and push the result to the device.

Sending over TCP is quick from the Web IDE, but wifi doesn't seem to be completely stable (then again my ESP32 doesn't seem completely stable in general!).

There is an issue open for enabling TCP in the CLI... https://github.com/espruino/EspruinoTool­s/issues/32.

Happy to modify and have a go at the Web IDE if you can suggest right approach...

For the ESP32 env.CONSOLE is coming through as Serial1, so setSlowWrite(true) is called in versionChecker.js. In this case SERIAL_THROTTLE_SEND has no effect. I think the options are either to provide an explicit block size for slow sends only, which is what I've done or provide an explicit block size for all sends slow or not.

@Wilberforce, Gordon says that flow control "can be enabled". Do you think this is a possible option for ESP32? In which case we wouldn't need hacky options.

Yes I've been doing hacking around the SPI with DMA so have a custom build... Definitely feels a bit bleeding edge particularly on the ESP32, but having fun... Espruino is a great project - well done!

Thanks. I actually added an option on my local CLI, -s --serial-block-size. I can send you a pull request if useful. I found that on the ESP32 128 works well enough. I didn't look at adding this in the Web IDE because I don't tend to use it except for testing tiny things (partly due to my Typescript pipeline...)

Hi @Gordon I will investigate some more and try to nail it down. It's a bit hard because my app is getting more complex and it's transpiled from Typescript...

I just did a quick test setting the limit back to 15 and running make clean && BOARD=ESP32 RELEASE=1 make and first signs are good -- no assertion! I feel a bit of a fool now -- I will have to re-run my SPI performance test and see what difference it's made ;)

I have an app that's been running fine on the Pico but now when running on ESP32 it immediately gives an assertion failure: ASSERT(jsvGetLocks(var) < 15) FAILED AT src/jsvar.c:632. As far as I know it doesn't have much recursion or deep call tree, but I am transpiling from Typescript so.....

I increased this to 31 and re-flashed and problem went away. Perhaps this is a more sensible default for this platform?

@Gordon, @Wilberforce should I log suggestions/requests like this in the Github issues (not sure what the process is for ESP32 specific suggestions/requests)?

Just for info I am using Typescript (target: es5) along with webpack to transpile and minify code before sending to Espruino, and this gives me most of the features I'm used to. Obviously doesn't work for features that the Typescript folks haven't done es5 polyfills for...