-
ESP Everything transcript part 2
03/09/2018 at 16:46 • 0 commentsSophi: @1rabbit as much as we love chaos, in order to avoid it here in the chat, we uut all the questions in the comments.
Arsenijs: That's no wonder, goats are for 6GHz and up, you're supposed to sacrifice fluffy rabbits for 1-6GHz as a rule of thumb
Sprite_tm: Ah, the goggle questions. Again, dunno, deeper RF magic, not my forte, sorry :)
Billybob: :<
Michaelm: Checking in with ham radio groups would be the ideal. Antennas can make a difference. There are onmi-directional and directional. You would need something more directional.
Michael Anfang has joined this room.10:44 AM
Billybob: Well, the goggles have omni and patch antenna. Though the omni is circular polarized. Maybe that makes all the difference.
Billybob: Guess it's a "tryandsee"
Sprite_tm: True. The ESP32 (and the 8266) actually have pretty good RF specs, on par or better than the chips of other WiFi-companies, so at least with a good antenna you can get a fair bit.
1rabbit: i get about 200meters outdoors
hazbounn has joined this room.10:44 AM
1rabbit: with the pcb antenna
Thomas Shaddack: usually the "omnidirectional" antennas with gain work by flattening the characterstics so it has higher gain along the plane perpendicular to the antenna axis, so it radiates more there and less up and down. handy when we have an apartment that is usually mostly horizontal.
Kevin: I forgot this chat started this early. I just got here. Hm... Sprite_tm mentions porting Doom to the ESP32? I knew the device was a capable little beast. Didn't know it was that capable. :)
michaelm: Look up yagi antennas. I saw a version of the ESP32 that allows an external antenna connection.
Sprite_tm: Kevin: https://github.com/espressif/esp32-doom Runs at a nice 30FPs or so.
Sophi: Q from @konsgn : any 5ghz chipsets in the works?
Sprite_tm: Yes, we do. No idea how far along it is (I think our next chip is still 2.4GHz only) but I've heard giddy sounds from some of our RF guys with interesting terms like 'really low phase noise' and 'antenna coexistence' and other things, so I can only assume we should have something good upcoming :P
Sophi: Next Q from @Simon Merrett: I'm designing a wearable temperature sensor that I'd like to keep low size, weight, power. I know ESP32 has BLE but I understand that up to this point the BLE still takes ~100mA. Are there plans to optimize BLE power to act closer to the ~10mA of e.g the Nordic chips with BLE? If so, is this something likely to be available to Arduino IDE or just in the Espressif SDK? Thanks!
konsgn: cool, good to hear
Sprite_tm: Issue is mostly that getting the thing to be anywhere near efficient is a PITA, as 5GHz amplifiers are way less efficient than 2.4GHz ones, or so I hear.
Sprite_tm: Eh, I can stay a bit longer if that's okay.
Sophi: we can do a follow up chat on this if @Sprite_tm is willing
oh that would be super @Sprite_tm !!
Sprite_tm: Meh, everyone is here anyway :P
Sophi: Next from @HCARLOTT : Anyword on the esp-idf 3.1 release date?
Simon Merrett: Sorry, no reply to mine?
Sprite_tm: Lower-power BLE: Yes, we're most certainly doing things in that direction. (That is also one of the reasons the SDK isn't visibly expanding: 'lower-power modes' is only a small bullet point but can take a huge effort to get done.) I can't tell you how much lower that is going to be, though.
Simon Merrett: Thanks
Sprite_tm: 3.1 should actually bring in a lot of those lower-power things.
Sprite_tm: For when it's released.. that's always a mystery. We're trying to get less things into the releases, because the time delay between them is irritating to us as well. If any, we are poised to keep releasing all features on the master branch as soon as we merge it, so if we have something, you'll see it.
Sophi: Next q is from @Matthias Boesl : is there any plan to support the esp32 port in zephyr OS? They are currently working on WiFi integration, and the OS seem very promisingSprite_tm: We actually have a bunch of OSses that have interest in providing an ESP32 port: Zephyr, Nuttx, some Chinese RTOSses... We are absolutely not against integration of that, and we have some abstraction layers in the works that make it easier to integrate the (still binary, sorry) WiFi and BT drivers into foreign OSses. As it is, we will not be doing any coding for these OSses ourselves, as we lack the manpower to do that, but we're most definitely willing to help out when technical issues come up.
Michaelm: FreeRTOS and Mongoose work on ESP32.Matthias Boesl : is there an OS agnostic WiFi blob available?
Sprite_tm: Well, FreeRTOS is what we use in esp-idf ourselves, and Mongoose isn't so much as an OS but more like a very comprehensive user space... so that's not really any 'foreign' OS.
Sprite_tm: Not yet. We're working on that.
Matthias Boesl: cool, thanks
Q from @dreamer : Will Espressif ever get rid of the binary blobs still needed to use the ESP series?
We would like to see FrostedOS on the esp32, but since this needs fully open kernel space it's currently not possible.Sophi: lots of questions about the binary blobs!
Sprite_tm: 'Ever' is a long time... and in general this has been a pretty hard issue here, as I do think I have some influence on the company direction here. On the one hand, I'm all for open stuff, as much as possible, yes please!
Sophi: here's another about the blob from @Arsenijs : I've been discussing usage of ESP8266 as a SDIO WiFi card with people in the DIY smartphone community (specifically, in regards to the ZeroPhone project, but there are other projects I know of that currently use SDIO WiFi cards and considered replacements). There's always a question - what about the binary blob uploaded by the driver? Speaking mainly about this: https://github.com/al177/esp8089/blob/master/eagle_fw1.h, as well as the corresponding .fw2 and .fw3 files.
Are there sources? We haven't managed to find any yet. We've considered putting a bounty on reverse-engineering the blob, so that we have a WiFi card we can use internally for people that want to have an open-firmware driven WiFi card, with all the benefits it brings. However, if the sources could be made accessible, that'd be awesome. Is there anything we could do about it?
Dreamer: @Sprite_tm yeah I guess "someday maybe" is an answer. but what are the main motivations to keep these parts closed?
Sprite_tm: On the other hand, there are some risks involved. Especially with the WiFi stuff: what if your WiFi hardware can actually do much more than the binary blobs normally allow? We've already seen people make disassociation throwies with the ESP8266. What if people can disrupt more communications because you opened up the interface to hardware that allows more than is legally allowed? You can get stuff like the FCC all of a sudden requiring all WiFi firmware to be signed so no one can mess around with it.
dreamer: and could an esp be used without the blobs? (ok, not as useful without wifi/bt)
1rabbit: @dreamer good point
Thomas Shaddack: in the age of software-defined radios, do such restrictions make sense at all?
1rabbit: a knife can be used to kill or to cook healthy food
Sprite_tm: Also, there are more down-to-earth issues. For instance, we're pretty sure we have all our patent stuff covered, but what if there's something patented we've missed, hidden deep in the WiFi hardware? Seeing the bits that control it directly would make it way more visible. To make it open anyway is a choice we can make, but I'm just saying it is not entirely consequence-free.
1rabbit: same with the wifi
Milkey Mouse: *small brain* using an esp32 with binary wifi/bt blobs
*expanding brain* using an esp32 without wifi or bluetooth
*cosmic brain* interfacing an esp32 to another radio chip
Arsenijs: Avoiding exposure of patented stuff does make sense, of course
Dreamer: @Milkey Mouse brain?
1rabbit: so then from that logic we would only be able to cook with butter knifes
1rabbit: :)
Arsenijs: But there are already open-firmware WiFi cards (just USB, not WiFi)
Thomas Shaddack: @1rabbit UK actually made some noise about banning steak knives due to having a sharp tip.
1rabbit: binary blob are the butter knifes of wifi
Arsenijs: And the ESP8266 deauth stuff hasn't exactly died down - people just use the old SDK, it's still possible to do so; and yet ESP8266 is popular as ever
Sprite_tm: True, but you have to keep the practical in view as well. A SDR still is pretty expensive, and GnuRadio is all but user-friendly to the newb. When you can grab an ESP32 devboard for $5, blow some disrupt-everything firmware inthere, add 2 AAs and hide it somewhere at school/work/..., we all of a sudden are known as the company that makes those chips that kill your WiFi and endanger people because they can't call 911 on their WiFi phone.
Sprite_tm :Arsenijs: Exactly, once the ghost is out of the bottle, you can't put it back again. And that is why we are so hesitant to open-source the drivers.
Thomas Shaddack: easy remedy: do the same with more chips from other vendors.
1rabbit: the deauth thing is fun for 0.1 seconds maybe ? i tried it on myself and moved on quickly
Milkey Mouse: some people are more easily entertained by messing with people
Arsenijs: @Sprite_tm Do you actually feel any long-term consequences of that?
Thomas Shaddack: has some tactical uses in the field of electronic warfare.
Sophi: next question from @1rabbit : what kind of range should i expect from ESP-NOW in urban conditions? i have not been impressed by the range from my tests at home (a good slices of lost messages) iirc its supposed to be stronger than regular wifi, is there options to consolidate the transmission?
1rabbit says:11:10 AM
tbh if you want to do evil stuff the blobs wont stop you
Sprite_tm says:11:11 AM
Thomas: As soon as there's a chip near our price range that has the interface to the HW entirely open (and given the interface to the HW is as capable as ours), I'll start advocating to open it up within our company without a thought.
konsgn says:11:11 AM
well, not to switch topics but to switch topics, @Sprite_tm would you be open to having expantions to the pocket-sprite sdk in the form of alternate input methods, joysticks etc...
Hans has joined this room.11:11 AM
1rabbit says:11:11 AM
you can sharpen a butter knife prison style on the walls
Arsenijs: I'm really curious about that, since it's been possible for a while and all I've seen were some tutorials on Instructables
1rabbit: same with the blobs
Tythompson2556: Dont underestimate the shallow fear based regulation the us government wages on its people were quite lucky not to have had then crack down on some / all of it at this point
Thomas Shaddack: we need some tools for rapid reverse-engineering of blobs. generic answer to generic problem.
Thomas Shaddack: ...and we need desktop chip fabs, but that's a bridge too far for now...
Tythompson2556: +1 for decompilation @ home
Milkey Mouse: We'll cross that bridge when we burn it
Sprite_tm: Anyway, the ESP-Now question. No, ESP-Now is not supposed to be longer-range than normal WiFi. We do have a special modulation scheme that does have a longer range, but IIRC you need to enable that separately.
1rabbit: interesting
Sprite_tm: And yes, you're going to have a fair amount of packet loss, as esp-now does not do any retransmits, to my knowledge.
1rabbit: how can i enable it, is there docs on it
Sprite_tm: Erm, lemme see if I can find it...
1rabbit: nice
Thomas Shaddack: thought about code visualisation using the molecular modeling approach. instructions as atoms, links to them as bonds, algorithms for bond length to self-organize into structures, so code chains form tight strings while library calls are long and weak and their functions get segregated away.
Kevin says:11:15 AM
@Sprite_tm Thanks for the link to the info about Doom for the ESP32. Amazing.
Last question: Sort of a follow-up question to the Linux one: assuming I'm using the QFN ESP32 directly, what's the maximum SRAM or Flash I could theoretically connect to it? I've heard conflicting figures from ESP-PSRAM datasheet, esp-idf docs, hardware datasheet, etc
1rabbit says:11:15 AM
is that modulation lowering the noise floor, like lora would do?
Sprite_tm: @1rabbit: Sorry, can't find it. Suggest you read through the WiFi docs, the mode is called 'long range' mode. You enable it on the WiFi interface itself, iirc it's not ESPNow specific.
1rabbit: oh
Sprite_tm: And dunno, it uses some different modulation, but I can't even remember which :P
Tythompson2556: Hey code vis guy there's an article on mddium .com about software and bugs and the Toyota code spaghetti you might be interested in. Some or all of that should find it
Thomas Shaddack:...random weird thought... exotic modulations for very slow bitrates for low powers over large distances, like QRPp...
Ajlitt: @Thomas Shaddack sounds like LoRa
Thomas Shaddack: more like lora on steroids doped with low probability of interception.
1rabbit: ok, ill look it up, if you can find it please pm on git (1rabbit)
Sophi: Last question: Sort of a follow-up question to the Linux one: assuming I'm using the QFN ESP32 directly, what's the maximum SRAM or Flash I could theoretically connect to it? I've heard conflicting figures from ESP-PSRAM datasheet, esp-idf docs, hardware datasheet, etc
Michaelm: @Thomas Shaddack There are modes like that used in ham radio. FT8, JT65,, & JT9 to name a few.
Sophi: ok we also have one more after that: sprite_tm was the guy who made the SHA2017 badge, used a special ESP from espressif for it, i am wondering what he would use for the next badge project ;)
Sprite_tm: Lessee, memory to the ESP32. In theory, we support 16MiB of flash and 8MiB of SPI RAM. However, we don't have address ranges to keep that all mapped at the same time: the psram can have maximally 4MiB mapped at the same time, the flash can has 4MiB mapped as data memory and (iirc) 4MiB as instruction memory... I think there are 2 other 4MiB regions for the flash, but they are mappings for instruction memory and I'm not 100% sure if they're usable out of the box.
Sprite_tm: No, I did not make the badge. Not even close. We had a very good team of people in the Netherlands, I think I lent a hand here and there, but they did the brunt of the work.
1rabbit: @Sprite_tm is that long range mode only for the esp32 or the 8266 as well
Sprite_tm: @1rabbit ESP32-only.
1rabbit: good to know
Sprite_tm: As wrt the next badge: dunno :) I think the design of a badge wrt functionality should go first, then the component choice. (Which obviously isn't always possible because some parts you can get sponsored, others you can't.) However, I probably would go for something Espressif again, as I know we're pretty okay with sponsoring cool badges ;)
@1rabbit maybe this one https://www.esp32.com/viewtopic.php?t=1001
Dave Blundell: What do you think the chance is of getting some better CANbus transceiver in the next silicon? The ESP32 is almost perfect for a bunch of car appplications.
1rabbit: @baoshi neat!
Kevin: @Thomas Shaddack I was thinking about FT8 as I've been hearing of an interesting experiment currently ongoing involving a platform floating out on the sea. I haven't read much about the actual protocol as I don't have a computer near my radio equipment to try any digital modes.
Sprite_tm: @1rabbit Sounds like it yes.
Sprite_tm: @Dave Blundell Anything specific you'd want?
Ajlitt: Talking about component choice, it's awesome that Espressif parts are available from major US distys like Digikey. When will the ESP32-PICO make it to those channels? The only source I can find today with a quick search is Electrodragon -
ESP Everything transcript
03/09/2018 at 16:35 • 0 commentsSophi: And.... let's get started. welcome @Sprite_tm !
Sprite, can you introduce yourself, tell us all who you are and what you work on?
(pretty excited to have you hosting btw)
Sprite_tm says: Thanks Sophi, glad I can be here again! Fingers all warmed up, hope I can type quick enough :)
Marek has joined this room.10:05 AM
Sprite_tm says: I'm Jeroen Domburg, aka Sprite_tm. I am an engineer for Espressif, working mostly on the platform side (SDK, drivers, examples, ...) but I tend to poke my nose in other internal stuff as well. Somehow I also got the title of 'marketing manager'. Not sure how I got that one, but I try to use it for good, e.g. as an excuse to port Doom to the ESP32.
Sprite_tm says: Furthermore, I also tend to meddle a bit in electronics here and there. I think you may have seen some of my stuff on HAD, as they have featured some of my projects. Sophi, mind if I plug the PocketSprite here as well?
https://pocketsprite.com/
POCKETSPRITE
PocketSprite - Tiny Retro Gaming on your Keychain
PocketSprite is the world's smallest gameboy and sega emulator. Play all your favorite gameboy and mega drive ROMS on this keychain emulation console.
Read this on PocketSprite >
plug away :)
Sprite_tm says:So my latest (well... two years in the making) project is a tiny game console based around the ESP32, the Pocketsprite. It's open source and all, and already has a GameBoy and Game Gear emulator, but it also has a SDK so you can write your own things for it. Crowdfunding is still going on: https://www.crowdsupply.com/teampocket/pocketsprite/ .
cpope says: congrats on your campaign, looks like it is going well!
Sprite_tm says: So, erm, any questions about Espressif, myself, the PocketSprite or whatever are welcome. I'll stick to the questions posted at https://hackaday.io/event/69323-esp-everything-chat-with-sprite-tm first, feel free to chime in if you have anything to say on the topics there.
Sprite_tm says:cpope: Thanks! Yes, >600% funded, we can't complain :)
Milkey Mouse says: Yes the PocketSprite is really cool. I've wanted one ever since I saw Sprite_tm's hackaday superconference talk. Just a little too lazy to replicate it myself ;)
Sprite_tm says: Yes, I heard that way too often, hence me actually turning it into a commercial product :)
Sprite_tm says: Anyway, 1st question from the comments:
Sophi: Here is our first question: Would it make sense to use small USB-capable chips in place of the USB to serial converter on the development boards, like the micro:bit does, to allow for easier programming (for example using UF2) and possibly access to the on-flash filesystem? Would Espressif or you personally be interested in developing such a board?
Sprite_tm says: he guy wo had way too many fun with Unicode asked: "Would it make sense to use small USB-capable chips in place of the USB to serial converter on the development boards, like the micro:bit does, to allow for easier programming?" The answer is: yes! Actually, one of us (Angus, aka projectgus) already looked into this for the esp8266 but aborted his project somewhere. We think it would make sense to replace the usb-to-serial converters we use now with something slightly more custom-made for ESP32s. We just don't really have the time to design something like that ourselves, but we'd be welcoming efforts there.
question is from @ɖҿϝիɟթվ
konsgn says:I finished wiring up a similar prototype the day the campaign launched. Really happy to see that it was turned into a thing. great job!
Sujith Anandan: That was awesome..congrats
Thomas Shaddack says:10:11 AM
thought. add rotation encoder or three and it could be a good "core" for all sorts of lab instruments.
watson has joined this room.10:11 AM
Sprite_tm says:10:11 AM
Sophi: GMTA:) You do the questions, I'll do the answers.
ok cool
question 2: Is there any recent software improvement for the ADC of the ESP32? Will there be a new revision of the chip with improved V_REF and a more linear behavior?
Sprite_tm says:
Anyway, we are looking into making our devices slightly more user-friendly. We have things planned wrt a native USB-interface for the next chip. We'll still be mostly WiFi/BT, but we have noticed USB can be useful at times.
Sprite_tm says:
Aah, the dreaded ADC.
Sprite_tm says:
The answer is yes - we're actually working on improving the characterization in software so you at least have an option to get something linear out of the ADCs. For now, you'll have to measure the offset of the reference voltage yourself, but we are working on integrating this in the ATE process and burning the exact reference voltage into the E-fuses. It still does not mean you have a perfectly linear 12-bit ADC, but it should go a fair way in making it more useful. For our next chip, we'll definitely be improving the ADCs - the ADCs in the ESP32 are far from the best we can do.
ɖҿϝիɟթվ says:
thanks, that's good to know!
Sophi: so is the ADC in the esp8266 not working? I get some data using the Arduino IDE, but haven't checked if it is accurate yet
Milkey Mouse says: It's just not very linear from what I remember
Sprite_tm says: No, this is the ESP32 ADC. The 8266 ADC probably works, but to be honest I have not heard anything about its precision.
benjaminaigner says:
@Sophi Kravitz There is a big discussion ongoing on how to measure accuracy and linearity of the ADC in ESP32...
Milkey Mouse says: *in the ewp32
Sophi: where is that discussion?
Sprite_tm says: Sophi: The issues are that a. the Vref is not very accurate. Well, it is, but it varies chip-by-chip. Once you know it and compensate for it, that's no issue. The other issue is the non-linearity. We have curves to compensate for that (also in esp-idf), but you lose some precision near Gnd/Vref that way.
Sprite_tm says: Analog hardware on chips is hard :/
benjaminaigner says: On GitHUB :-), different issues are posted here:
https://github.com/espressif/esp-idf/issues?utf8=%E2%9C%93&q=adcSophi: ok cool. I'm just measuring the battery, so when it gets near 3.6-3.7 is enough
thanks for the link @benjaminaigner
Thomas Shaddack: ...if a pwm is reliable, could we self-calibrate the adc with a small circuit that'd feed it with filtered pwm-ed voltage from 0 to vcc and build a curve to write to the memory?
Sprite_tm: Sophi: Pro-tip: If you have a charger that outputs a 'battery full' signal, connect that to the ESP32. If that goes active, you know that what you're measuring corresponds to 4.2V exactly.
Sophi: good point :) yeah I have 4.2 mapped to 1V
Ɖҿϝիɟթվ: ooh, I didn't even think about using the status led pin for anything else than the led
Eric has joined this room.10:19 AM
Sophi: @ɖҿϝիɟթվ what will you use it for?
Sheffieldnick: Question: what's the best way to contact Expressif about technical issues? e.g. I submitted an issue on github about the ESP8266 coming out of light sleep over 2 months ago... ? Thx! :D https://github.com/espressif/ESP8266_NONOS_SDK/issues/78
fkilleen has joined this room.10:19 AM
Sprite_tm: The question ties in with that trick: if you have a precise external voltage you can measure, you can figure out what the Vref of the chip is, feed that into the ADC calibration logic in esp-idf, and that will then give you a more precise measurement.
Sophi: next question from @haddyhad, a bit of a rant: Hey SpriteTM! Esp32 sdk development has issues, Minor features pending for over a year, commits take forever to make it to the public repo and still break stuff, some peripherals still not supported, wifi/Bluetooth not optimized, docs incomplete, not enough effort to avoid both shanzhai practices (passing around zip files, multiple versions of closed source libs) and corporate stuff (sales conduit to tech support solving the same problems over and over in private instead of public support response and push to public KDB).
Sprite_tm: Well, first of all, if you're talking about very recently, we've had the Chinese new year which tends to slow things down. Apart from that, most of the drivers are done now, so we only have a few done that at least our customers do not have a pressing need for. Apart from that, we're using the SDK more and more for internal projects that are pushing the limits of what the chip can do, and that brings small but pretty hard to pin down bugs to the surface; the fact that we're expanding QA/testing to actual projects and not just the SDK helps there as well. I think it's just part of the lifetime of the SDK: initially, there's a huge rush to get everything built, but later on the priorities are more on making it bug-free (as much as possible), polishing it and maintaining it.
Sprite_tm: I don't really see us reverting to shanzai practices and corporate stuff, do you have any examples of that if you're here?
Sophi: question from @Milkey Mouse : I have too much time on my hands and am considering trying to get linux-xtensa to run on an ESP32 (obviously with a trimmed-down kernel, maximum SRAM, XIP, etc.). What are some roadblocks that I would come across? I'd have to use ucLinux no-MMU stuff because the MMU isn't the Linux-capable one as used in the Diamond 232L, right?
Sprite_tm: Ah, I saw that one. That would be absolutely awesome to do, if you ever get that off the ground and I'll see if we can help wrt getting WiFi/BT to work!
Arsenijs: Posted a question, fingers crossed =)
Simon Merrett: @Sophi Kravitz I think @ɖҿϝիɟթվ was talking about using the charge full status led voltage going high as a trigger to read ADC and record it as whatever voltage your charger gives as full (4.2/4.25V).
Sprite_tm: Some issues... well, first of all, you indeed don't have a MMU compatible with Linux, so as you guessed you'd have to run the MMU-less variant. Another issue would be that the amount of RAM you can run instructions on is pretty limited: only a few hundred K if memory serves, and external PSRAM can't do it at all. Not sure if Linux plays well with that.
Milkey Mouse: Why wouldn't PSRAM work? Can't it be mapped in same as the rest of it?
I mean, code and data would be separated, but that isn't a showstopper
Sprite_tm: No; the memory range it normally lives in can only be connected to the D-port, which can't execute instructions. You may be able to hack something with connecting psram instead of flash, however... not sure how viable that would be. Flash is usable as both instruction as well as data memory, but is read-only.
Milkey Mouse: Can you execute instructions from flash without loading them into RAM first (XIP)?
Sprite_tm: Yes, you can definitely do that.
Sophi: Next question is from @davedarko : I have this project idea: #WIFI Game Boy Cartridge - I was a bit naive when I started this, tried to toggle pin for pin but it was way too slow. Would/could this work with the I2S parallel interface? I wasn't able to find much on the I2S interface when I started this and what I found was above my skillset, but I still like the idea of having a cartridge that has wifi.
Sprite_tm: So if you can do everything XIP, there's a chance you can get it to work.
Sprite_tm: Ah, I saw that. Did something like that on a Vectrex with a CortexM4.
Sophi: Q from @Jarrett : Do you have any tricks for the homegamer to try and tune their antennas for the ESP32-PICO-D4?
Milkey Mouse: Cool, XIP is natively supported by Linux mainline as well as -xtensa, I'm just not sure if it would work in combination with ucLinux no-MMU patches out of the box.
Sprite_tm: Wrt the WiFi GB cartridge: Long story short, I don't thing I2S is the right way to go there.
Davedarko: okay, any right ways?Sprite_tm says:10:32 AM
DaveDarko: Sophi went a bit too fast, I'll continue answering your Q.
davedarko says:10:33 AM
cool
ɖҿϝիɟթվ says:10:33 AM
this is too exciting
Sprite_tm says:10:33 AM
The issue mostly is that you need to see that a CS line goes low, then immediately read the address lines, look up whatever you want to send back and send it.
Sprite_tm says:10:34 AM
I think that I2S would be too slow for that; you'd have to set up a transaction and everything. I think you could get it to work if you wrote a high-prio interrupt for the CS pin, then in the interrupt handler, in assembly, read the address GPIOs as fast as you can, grab a response from internal memory (which luckily you have more than enough of) and send that to the data pins.
Sprite_tm says:10:35 AM
If you need help with that, poke me; by now I have some experience with high-level interrupts and I'm actually curious if the ESP32 can do it, but don't really have any interesting consoles here.
jay broni has joined this room.10:35 AM
konsgn says:10:36 AM
could you put a small fpga to act as a buffer between the gb and esp32. that might werk too
davedarko says:10:36 AM
I thought "as fast as I can" would be I2S, since there's no way of getting pins parallel
davedarko says:10:36 AM
no "take other chips" please :)
Sprite_tm says:10:37 AM
You might get it to work... but there's a fair amount of setup using the I2S peripheral. It may still be quicker than doing it manually, I agree.
konsgn says:10:37 AM
does the esp32 have enough pinout to connect fully?
ɖҿϝիɟթվ says:10:37 AM
@davedarko you could do it with a 555 ;-)
davedarko says:10:37 AM
almost enough
davedarko says:10:38 AM
I tried it with reading via the registers, but was a full cycle behind
Sprite_tm says:10:39 AM
@davedarko Maybe a good idea to move on to other qs... if there is still time at the end, I'd love to come back to it. For now, feel free to poke me at jeroen at spritesmods period com for this.
curly722 has joined this room.10:39 AM
davedarko says:10:39 AM
yes, was about to say that
@Sprite_tm there are about 10 more questions, can I move on?
haha ok
davedarko says:10:39 AM
thanks a lot!
Sprite_tm says:10:39 AM
GMTA :P
Do you have any tricks for the homegamer to try and tune their antennas for the ESP32-PICO-D4?
from @Jarrett
1rabbit says:10:40 AM
what kind of range should i expect from ESP-NOW in urban conditions
let's move fast for a bit. @Jarrett someone else responded to your q in the comments too
@1rabbit all questions go in the comments here: https://hackaday.io/event/69323-esp-everything-chat-with-sprite-tm
1rabbit says:10:41 AM
i have not been impressed by the range from my tests at home, iirc its supposed to be stronger than regular wifi, is there options to consolidate the transmission
and a question from @billybob : Q: I want to shove an esp in to my fpv goggles, but I am pretty sure it will interfere with video quality. The video comes in at 5.8ghz. It shouldn't interfere, but I can't help wonder if a small transmitter inside the goggle enclosure would have negative effects.
1rabbit says:10:41 AM
allright thanks
Sprite_tm says:10:41 AM
Ah, yes. I have no idea. Antenna tuning is Deeper Friggin' Magic, as is all RF things. I've been watching the RF team here, and they seem to be able to go without sacrificing goats... so I think the one advice I have for the homegamer is that I have no clue, but that sacrificing goats does not seem to be an essential part of the ritual.