<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
:-/<br>
<br>
I guess that's the price to pay for using <strike>bananaware</strike>
cutting edge technology.<br>
<br>
On the plus side, maybe the ESD shield of the WROVER module will
help in CE/FCC certification…<br>
<br>
Thanks for not losing faith.<br>
<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 30.01.2018 um 09:33 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:955BD9DD-E707-46AF-BC1F-E4E16370F43D@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class=""><br class="">
</div>
A lot of back-and-forth with China (suppliers, partner, etc).
<div class=""><br class="">
</div>
<div class="">Bottom line is that we don’t think Espressif is
ready for PSRAM + external flash. The IDF code just doesn’t seem
to support it. Very frustrating, given that nobody on their
support forums or issue tracker is saying that; but looking at
the code it is pretty obvious they have just tested it with
their particular use case (this specific set of bus speeds, this
particular PSRAM part, etc).</div>
<div class=""><br class="">
</div>
<div class="">We’re all getting pretty fed up with this. Trying to
get Espressif to recognise (and fix) the SD CARD issue took
months. Now, we have to go through the same hoops for this...</div>
<div class=""><br class="">
</div>
<div class="">So, we’ve decided to raise the white flag, swallow
the extra cost (probably only perhaps US$3 or so, although
one-time CE/FCC certification fees could be drastically higher),
and source a WROVER module with 16MB flash + PSRAM directly in
the module. We’re 99% certain that will work, as that is pretty
much Espressif’s supported configuration. Circuit leads are
short, everything is encased in a metal ESD shield, the 1.8v is
a non-issue, etc. Lead time for those components is 7-to-30
days, so as a quick confirmation we are getting the parts and
will modify some of our own WROVER modules first (remove the
top, unsolder the 4MB flash, solder in a replacement 16MB
flash). Time to dust off the microscope again.</div>
<div class=""><br class="">
</div>
<div class="">Flash chips are being overnighted to me, and both
China and HK sides are doing the work at the same time. We
should have confirmation within this week. The peripherals all
seem ok with the new board, so it is only the 16MB flash issue
to resolve.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 30 Jan 2018, at 9:00 AM, Mark Webb-Johnson
<<a href="mailto:mark@webb-johnson.net" class=""
moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">News: Some good, some bad.</div>
<div class=""><br class="">
</div>
<div class="">Injection moulded cases are here. They
look good, feel good, and everything fits. Blue light
doesn’t show through (we should turn it off to save
power anyway). Our logo looks particularly good as
part of the mould.</div>
<div class=""><br class="">
</div>
<div class="">All the peripheral functionality seems to
work just fine. SD CARD, CAN bus, simcom, USB
flashing, GPIOs, EGPIOs, etc.</div>
<div class=""><br class="">
</div>
<div class="">But the bad news is external flash + psram
combo is not working well. Just seems flaky. I tried
‘scoping the level converter last night, and the
signal looked really dirty. We’re not sure if the
problem is the level converter propagation delay
(we’re right on the borderline with that) or trace
layout (we moved the flash to the underside of the
board to get it closer to the ESP32 module, but that
meant using vias which could be contributing to the
issue). We have found some alternative level
converters which bring propagation down to 1.3ns or so
and are supposedly good for up to 100Mhz, and we’re
trying to hand-modify a board at the moment to see if
those improve things. I dug some into the ESP32 PSRAM
library and it is really strange:<br class="">
<br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">They hard-code the flash CS pin
(GPIO10) in the library, so our external CS isn’t
going to work.<br class="">
<br class="">
</li>
<li class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>They
have a separate clock for PSRAM, and for some
reason want to delay it with respect to the
flash clock. They do this by routing it in and
out through an internal GPIO that is not
externally visible (and that pass through the
GPIO matrix delays it). Path ends up SPI CLK
--> GPIO28 --> signal224(in then out)
--> internal GPIO29 --> signal225(in then
out) --> GPIO17(PSRAM CLK). Urgh.</div>
</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">I’m trying to fix this at the firmware
level, but I suspect that it is not going to be
trivial.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
<span id="cid:7B55BDAB-54F7-42AF-B9EC-D093D0790812"><PastedGraphic-5.tiff></span><span
id="cid:577DB22F-8976-4727-B4B6-110AC635F9CA"><PastedGraphic-6.tiff></span>
<div class=""><br class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 26 Jan 2018, at 2:01 PM, Mark
Webb-Johnson <<a
href="mailto:mark@webb-johnson.net" class=""
moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; line-break:
after-white-space;" class="">3.1:
<div class=""><br class="">
</div>
<div class=""><span
id="cid:8803B0E4-AFED-4ADA-AA5E-BBFA5692B847"
class=""><A3D70FF6-1425-4220-9FC2-4D25EF2EB4A0.png></span></div>
<div class=""><br class="">
</div>
<div class=""><span
id="cid:2FAD078A-0D45-4306-BD12-74B37A79B915"
class=""><latest.gif></span></div>
<div class=""><br class="">
</div>
<div class="">Mark</div>
<div class=""><br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 26 Jan 2018, at 10:44
AM, Mark Webb-Johnson <<a
href="mailto:mark@webb-johnson.net"
class="" moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8"
class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space;
line-break: after-white-space;"
class="">
<div class="">Version 3.0 main
board:</div>
</div>
<span
id="cid:FA623A18-680A-4863-9A94-68AB28D26FE2"
class=""><49304d73$1$15e08a5e24c$Coremail$guangzhouxinghai$<a
href="http://163.com/" class=""
moz-do-not-send="true">163.com</a>></span>
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space;
line-break: after-white-space;"
class="">
<meta http-equiv="Content-Type"
content="text/html;
charset=utf-8" class="">
<br class="">
<div class=""><br class="">
</div>
<div class="">Version 3.1 main
board:</div>
</div>
<span
id="cid:EA5DF71A-DABA-4B1C-96E7-AF138AD6F885"
class=""><C1BAC905-8C0F-4A15-A50D-E74D649A94FA.png></span>
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space;
line-break: after-white-space;"
class="">
<meta http-equiv="Content-Type"
content="text/html;
charset=utf-8" class="">
</div>
<span
id="cid:BBC0B98C-4CA7-47EB-8293-162D383D56B8"
class=""><6D8998ED-A8F1-494D-BA01-2D4A4990DF1E.png></span>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8"
class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space;
line-break: after-white-space;"
class="">
<div class=""><br class="">
</div>
<div class="">We’ve just started
testing it now.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 10 Jan 2018,
at 2:41 PM, Mark
Webb-Johnson <<a
href="mailto:mark@webb-johnson.net"
class=""
moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<div class="">
<meta
http-equiv="Content-Type"
content="text/html;
charset=utf-8" class="">
<div style="word-wrap:
break-word;
-webkit-nbsp-mode: space;
line-break:
after-white-space;"
class="">
<div class=""><br class="">
</div>
<div class="">Production…</div>
<div class=""><br class="">
</div>
<div class="">Analog Lamb,
while interesting, is
just (a) too expensive
(double the price), (b)
unproven, (c)
uncertified, and (d) has
long lead times. Using
proven Espressif
certified modules seems
the safer way to go.</div>
<div class=""><br class="">
</div>
<div class="">So, we’ve
decided to go with a
switch to a standard
certified ESP WROVER
module, and external
16MB flash memory. The
circuit board footprint
for this is a little
larger than the WROOM-32
module we’ve been using,
and requires one more
3.3V->1.8V power
conversion, but seems
the safest way to go.</div>
<div class=""><br class="">
</div>
<div class="">Accordingly,
I’ve agreed with the
China guys to proceed
along these lines for
the main board:</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""
style="margin: 0px;
padding: 0px;">
<ol
class="MailOutline"
style="margin-right:
0px; margin-left:
0px; padding: 0px
0px 0px 20px;
list-style-position:
inside;">
<li class=""
style="font-family:
微软雅黑; font-size:
14px; margin: 0px;
padding: 0px;">Change
WROOM-32 to WROVER
(on circuit
antenna version,
similar to
WROOM-32).<br
class=""
style="margin:
0px; padding:
0px;">
<br class=""
style="margin:
0px; padding:
0px;">
</li>
<li class=""
style="font-family:
微软雅黑; font-size:
14px; margin: 0px;
padding: 0px;">We
can free IO12
(SD_D2), IO13
(SD_D3), and IO4
(SD_D1), by using
just 1-line
SDCARD. I don’t
really want to use
IO12 as that is a
bootstrapping pin.<br
class=""
style="margin:
0px; padding:
0px;">
<br class=""
style="margin:
0px; padding:
0px;">
</li>
<li class=""
style="font-family:
微软雅黑; font-size:
14px; margin: 0px;
padding: 0px;">WROVER
PSRAM uses IO16
and IO17, so we
can’t use that for
modem.</li>
<ul class=""
style="font-family:
微软雅黑; font-size:
14px; margin: 0px;
padding: 0px 0px
0px 20px;
list-style-position:
inside;">
<li class=""
style="margin:
0px; padding:
0px;">Move modem
to IO4 and IO13.<br
class=""
style="margin:
0px; padding:
0px;">
<br class=""
style="margin:
0px; padding:
0px;">
</li>
</ul>
<li class=""
style="font-family:
微软雅黑; font-size:
14px; margin: 0px;
padding: 0px;">Change
to 1.8V 16MB flash
chip (W25Q128FW?).
As SDD_VDIO is not
exposed, add a
simple regulator
3.3V->1.8V for
external flash?<br
class=""
style="margin:
0px; padding:
0px;">
<br class=""
style="margin:
0px; padding:
0px;">
</li>
<li class=""
style="font-family:
微软雅黑; font-size:
14px; margin: 0px;
padding: 0px;">When
burning e-fuses,
need to take care
with 1.8V/3.3V
SDD_SDIO fuse -
leave at 1.8V.<br
class=""
style="margin:
0px; padding:
0px;">
<br class=""
style="margin:
0px; padding:
0px;">
</li>
<li class=""
style="font-family:
微软雅黑; font-size:
14px; margin: 0px;
padding: 0px;">Add
capacitors for SD
CARD and external
Flash, as per
Espressif example.<br
class=""
style="margin:
0px; padding:
0px;">
<br class=""
style="margin:
0px; padding:
0px;">
</li>
<li class=""
style="font-family:
微软雅黑; font-size:
14px; margin: 0px;
padding: 0px;">Increase
size of solder pad
for big
capacitors, and
USB connector, to
make it stronger.<br
class="">
<br class="">
</li>
<li class=""
style="font-family:
微软雅黑; font-size:
14px; margin: 0px;
padding: 0px;">For
the data lines of
circuit traces
SDCARD, SPI bus,
external flash,
take care to keep
away from power
traces or other
sources of
interference and
keep the traces as
short as possible.</li>
</ol>
</div>
</div>
<div class=""><br class="">
</div>
<div class="">The change
to WROVER is a PITA at
this stage, but that 4MB
PSRAM should give us
more headroom and the
extra bill-of-materials
costs is just a couple
of US$.</div>
<div class=""><br class="">
</div>
<div class="">For the
modem, we’re
double-checking the
power (which seems ok,
but check to be sure),
and changing passive
-> active antenna. At
the moment, it seems to
be just a couple of
passive components
soldered inline between
two easily accessible
points. For existing
developer modems in the
field, we’ll try to make
a simple upgrade kit
(passive->active) for
GPS, and post them out.
If you don’t need GPS
(such as Roadster
users), the modem boards
are functionally the
same as the production
ones.</div>
<div class=""><br class="">
</div>
<blockquote style="margin:
0 0 0 40px; border:
none; padding: 0px;"
class="">
<div class=""><span
id="cid:F76A8208-20C9-4D7C-A4C5-8B5B318D8C3D"
class=""><A04F19CE-27D9-439A-89DB-8B70136598A0.png></span></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Existing
developer OVMS v3 boards
(with WROOM-32 module)
will continue to be
called v3.0. New
production OVMS v3
boards (with WROVER
module) will be called
v3.1. We have
conditional compilation
in the firmware, to
switch the pin
assignments and whatever
else is required.</div>
<div class=""><br class="">
</div>
<blockquote style="margin:
0 0 0 40px; border:
none; padding: 0px;"
class="">
<div class=""><span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> Branch:
refs/heads/for-v3.0</span><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> Home: </span><a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3"
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3</a><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> Commit:
9504df70be78b6626970ec0ea53d2c2470e90afa</span><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> </span><a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa"
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa</a><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> Author:
Mark Webb-Johnson
<</span><a
href="mailto:mark@webb-johnson.net"
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""
moz-do-not-send="true">mark@webb-johnson.net</a><span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">></span><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> Date:
2018-01-10 (Wed,
10 Jan 2018)</span><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> Changed
paths:</span><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> M
vehicle/OVMS.V3/main/Kconfig</span><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> M
vehicle/OVMS.V3/main/ovms_peripherals.h</span><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> Log
Message:</span><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> -----------</span><br
style="font-family:
Menlo-Regular;
font-size: 14px;"
class="">
<span
style="font-family:
Menlo-Regular;
font-size: 14px;"
class=""> Support
for OVMS hardware
v3.1</span></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">
<div class="">Converting
developer v3.0 boards
to v3.1 is not really
feasible (a skilled
solderer could
probably use a 16MB
Analog Lamb
WROOM-32+PSRAM module;
that would be a
relatively simple
de-solder + re-solder
of the module, a
not-so-simple
re-arrange of the
traces for
IO16->IO4 and
IO17->IO13, and
disabling of external
16MB flash). Anyway,
those existing
developer modules
should be fine to
continue to use (just
without the extra
PSRAM).</div>
</div>
<div class=""><br class="">
</div>
<div class="">We are today
finalising the circuit
schematic and board
layout for the above,
and building a couple of
test boards (with WROVER
modules). I should have
one in about a week’s
time (assuming all the
components are
available). In that
time, we’ll finish the
ESP IDF v3.0 support,
and test late next week
/ over next weekend
(20th/21st Jan).
Assuming no problems, we
should be able to give
factory the go-ahead to
produce early the week
after.</div>
<div class=""><br class="">
</div>
<div class="">Given that
timing, I doubt if we
are going to be able to
get these boards made
before the Chinese New
Year holidays. Even if
we can get them made,
FastTech distribution
may not be able to get
them out during the
holidays. Manufacturing
in China starts to close
down around the end of
January / early February
this year. New Year
itself is mid-February.
Anyway, we’ll get this
all finalised, payment
and instruction to start
manufacturing in place,
then do the best we can
and get these out
available during
February. A big warning
is going to go with them
that this is for early
adopters only, and
firmware is changing on
a daily basis. Updating
firmware via wifi / sd
card should be fine.</div>
<div class=""><br class="">
</div>
<div class="">I’m seeing a
light at the end of a
long dark tunnel.</div>
<div class=""><br class="">
</div>
<div class="">Regards,
Mark.</div>
<div class=""><br class="">
</div>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br
class="">
<a
href="mailto:OvmsDev@lists.teslaclub.hk"
class=""
moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br
class="">
<a
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev"
class=""
moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>