-
Neat and very safe solution - the routing from 0.05" rows to 0.10" left and right sideline rows. The few holes that have to be given up don't make a dent at all.
For a shim it looks a bit different: having even one row more: a 2 x 14 = 28 wide DIP resembling solution adds at the same time already a minimal proto board - even more with castellations:
-
Don't feel a 'Tschumpuhung'... things are already quite voluminous and move so fast: solutions and new things appear quicker and more often than you (re)start and (re)stop the IDE...
-
Did you install and start the Espruino Web IDE in Chrome?
In the IDE in top left corner, you see a yellow/kaki Connect icon. Clicking/tapping it shows you the list of USB ports, from which you pick the one that obviously got successfully installed.
The Connect icon will turn green, and in the console, Espruino will print a banner including the installed firmware.
Espruino is now at you service!
PS: This button press on or briefly after plugging in/powering on is only for reset or flash. You do not need that to just get Espruino connected and talking to the IDE.
-
bigger Pico with some serious sensors onboard
@Spoki, I feel Espruino listens to a different drum beat... as many other alike enterprises do too - and that is: get a thing done as small as possible and as a component to integrate/combine with alike component as easy as possible. This promises the largest (potential) clientele - for function and for (affordable) price. The same goes for the gazillion sensor (chip) solutions...
'We' - the Pico Kickstarter backer community - had the opportunity to choose larger or smaller... and smaller was the answer, hence the 0.05" pitch. And look how beautiful a Pico looks with an ESP8266! ...and the little shim makes it happen.
Therefore, I think optimize an on-demand creation and delivery of shims / carriers dedicated to combinations could be a solution. Yes, there are a lot of combinations, but getting a (passive) shim/carrier going is a pico fraction of what it takes to get an board like Pico going.
-
-
-
Is there any way to put a female USB-A on a pendrive and get the pico to write to that? Just trying to get out of doing the SD card bit of I can.
Answer from @Gordon: plug-and-play for USB is not an option (yet)... may be it has changed.
I had similar ideas when Pico was in the making and in scope definition. Because the USB infrastructure is already there, why not use it, for example also to drive any of the available communication dongles - Bluetooth, Wifi,...
-
For removing silk and mask, consider a rotary/engraving tool (with switchable accessories)... like Dremel, but it does not to be that sophisticated and high speed. There are inexpensive ($10), suitable ones available, powered with wall outlet power adaptor or cordless/battery. With the right accessory - just enough cutting/abrasive - it is a bit safer - for both you and the board - than a knife. Btw, lower speed means also less cutting/abrasive: you do not want to harm the cooper track/pad too much...
-
Regarding ESP8266 (firmware): may be cloning @Gordon and throw up some kickstarter money for a Gordon-quality ESCOMINO would get everyone in a better state of wifi!
-
@Gordon, you mentioned a while ago on my memory manager thread something about DMA... could that help? Something like a module that let's you setup a DMA between two connected devices/'comm protocols'? It can evade the back and forth between fast firmware and slower source interpreted JS? The module should be an on-demand loadable module but would for need pieces in the firmware. The firmware pieces are like a switch board or clearing / routing house for data in transfer. I see the available firmware memory melt away like snow in summer...
-
Interesting... may be it is out there somewhere how what the boot sequence for standard and Pico are... but it looks like that something more like a Datasheet with the essentials has to be composed from what is already out there. It would then also include a section about what is different between the two boars. Before, it was a bit easier, it was the Espruino board and all others. Now it is the two Espruino standard and pico board and the others... I know it is work and even though I did some technical writing for some time, it is really not a enjoyable strength of mine. :(
-
When reviewing my last post's code example, I felt a bit uncomfortable withe the choice of 'on' as a variable name. It became such an overloaded (prefix)word, so there may even a better solution.
Btw, the example was not related to the font thing: I just verified my basic understanding of onInit() - save() code, re-plug power or press reset and see how Espruino 'reboots' and goes into my code - and it was still laying around in my scratch pad... and it became unintentionally the perfect match for situation. So only the last comment line was situation intended... ;)
Other font for IDE: For sure it has to be fixed font... would have to look how it is pulled, because it should work nicely in available environments: Windows, OSX, Linux (even though OSX is a Unix as well, it goes its own ways).
Regarding forum's font: I'm aware that the forum (code) was built for a different audience than programmers, and it turned out pretty good also for programmers, especially the letter o and digit 0 (zero) solution in text paragraphs, but not so much for the letter l and the digit 1 (one) in both text paragraphs and in code blocks. It's livable.
@Gordon, btw, I knew that you could not have made that mistake in the 'get started sample', because I know that code you publish runs... because you ran it more that once... and I - and everyone else - appreciates this fact: it saves everyone aeons (cumulated) of time.
-
-
...but the code assumes that there is at least data available to fill three buffers (or at least the first two fully and the third partially)... because I do not see any checks before these three buffers are getting used. May be the implementation is tolerant to the case were not even the first buffer is full... ;) I'm also not sure if stopping at the moment when reading ahead the content for the next buffer switch is correct... the waveform may still have things to play off of the buffer to which it just has switched. @Gordon will for sure provide the needed insight here!
-
-
Fort the stop play:
Make this line
var watch;
the very first line in your code and insert after the line in which you turn the LED1 on these lines:
watch = setWatch(function(){ // set the watch for stopping w.stop(); setWatch(play, BTN1, { repeat: false, edge:'xxxxx' , debounce:50}); }, BTN1, { repeat: false, edge:'xxxxx' , debounce:50});
Then add in the stop before the line with w.stop(); this line:
clearWatch(watch); // clears the watch for stopping
-
What I think happens is - since you do not debounce your button - that multiple play() run at the same time, and due to interference with time/phase constantly shifting funny sounds... (to verify that, put in our current code
var cnt = 0;
before the linefunction play()
, andcnt++
after it. Then you upload the code and press the button. When it has finished playing, enter in consolecnt
and tell me what you got!Therefore, do something like this for watching your button:
setWatch(play, BTN1, { repeat: false, edge:'xxxxx' , debounce:50});
xxxxx is either rising or falling - both is working (if you do not hold on to the button until play has finished).
You put this line as line 27 and you also insert it into your stop after line 14 (in which you switch your LED1 off).
When this is working - with xxxx the way that the play starts only after you have released the button - you can then make it stop when pressing and releasing the button while it is playing.
Looking forward to hear from you!
PS: I did not work with files yet on Espruino, but I wonder if you need to do something like close(), do you?
-
-
A variable can never be a literal number or begin with a digit (or sign or...) or be one of the language reserved words. So it is not an IDE thing, it is a language thing, and the IDE is so helpful to point the coding mistake out. Make it
var v1 = false;
orvar v2 = false;
- or even much better - some 'speaking' name, such as:var led1State = false;
. Since long names eat up precious space / available RAM - though Pico has (much) more of that than the original board - you may end up (far down the lane) with something along the lines:l1S
, but do not do that in the beginning. And there are even tools out there that minify - shrink wrap - the code for runtime: while coding/in source, the code is very human readable, and when uploaded and executed, it is extremely terse (some minifier replace then the variable names with _0, _1, _2,... , _a, _b, ..., _10, _11,... _0a, _0b, etc).PS: After reading your post and watching the video a second time closely, I notice, that you did not replace the 1 (one) with a 1 (one), you replaced the letter l (for led) with number 1. . Line 3 and 4 they all use letter l. If you change it there as well to one, IDE will complain there as well. I'm saddened(***) by font selections insensitive to this issue... sorry @Gordon for this rant - and for that one too: even though the forum does a mixed-better job with letter l and digit 1 - l1,
l1
,l1
, it could do a better job with the o letters and 0 (zero) digit: Oo0,
Oo0
, andOo0
, it could be more pronounced. That's why the
code format
is there to avoid any ambiguity - more so for o and 0 with the dot in the center, a bit less the l and 1.
(****) After being wasted over and over by similar font selections in the past, the politically correct I'm saddened feels more like I 'hate' insensitive font selection... nevertheless, for both you need a shrink to fix-ya, but with the latter you are left alone and get no empathy...
Understanding now the challenge, I suggest that you - @JackJamesHoward - change the conversation title to - for example - Watch out, 1 (number/digit) looks like l (letter), but they are really not the same! - Mr Obvious ;-) - and it will become a great help for many others...
-
Did you ever think a bit in the direction(s) the attachments convey? @DrAzzy, your work got me - may be a bit too - excited... ;-). @Gordon, could that be some shim - and even carrier / breakout - ideas as well? ...because It would bring the connectivity into just 2 single, parallel rows... (I 'accepted' the perpendicular rows - in the first place - only because they yielded to a smaller size, even on the standard board...).
For the not overhanging placement on @DrAzzy's proto-board and and its derived carrier board, a pin headers can be soldered between the Pico and the board for 'distancers' to give enough clearance for the cable to plug or (micro?) USB socket to mount. The headers can also be replaced by just wires, as @Gorden shows for attaching the already available shim. I'm not to much worried about the extra height this adds.
The (thin) shims can be soldered on either bottom or top of Pico, and with thin shims, two pin headers can be soldered across Pico and the shim along the long edges to give the overal board the typical two-row pin header look and application options.
With some
PS: regarding the routing: my experience in that matter is quite outdated, so it may be a bit far (tight) fetched... on the other hand that @Gorden made the routing in regard to the 0.05" pin row makes it look feasible to me.
-
I've seen your conversation about Promise. For me it was missing the support of re-try options, that's why I went on my own - and I did not need (so far) the other stuff - which of course my solution is missing: the next or goto. Sequencing I can make after a sync point with (the first) 'parallels' and then venture into the next ones the same way as I did into the very first one. I used a pattern I got known to in 86 when working on TANDEM NonStop Systems(R) - now server division of HP - and worked on code generators to take advantage of fault tolerance and parallel execution. Tandem was not a hardware based fault tolerance - like [IBM S/88'(http://domino.research.ibm.com/tchjr/journalindex.nsf/600cc5649e2871db852568150060213c/cfc96f12d1fb70c385256bfa00685bd8!OpenDocument) and many others were/are - but more so on a software fault tolerance that allowed sync points in the application and not only in the system software (or hardwired in hardware / on the board).
-
There was a time where the heart of a board - cpu - was the center of attention. With Pico it looks like the heart fits like a header / connector / socket, and everything else gets the day in court.
0.05" headers look like a bit pity... understandably: why would you make them as tall/long as the 0.1", because you just shrunk the pitch to 50%... so the 0.05" option in combination with 0.1" headers may not have been the most thought through decision... but may be this start the 'revolution' to do everything in 0.05" pitch, including bread boarding, the way the 0.1" pitch is established. Of course, I would then need to use my desk magnifier glass all the times... ;-)
-
@DrAzzy, is above code working to your expectations? I try to understand and get a bit confused about the sequence in which things get called. Last but not least the 15s timeout on line 16 throws me off. (The double-require of http - once in line 5 and the second time in 25 are probably just a casual thing...).
To capture the ready state, Promise help. When challenged with that, I though chose a more lightweight approach and has retry option built in - and called it Tasker - Task synchronizer - kind of a 'purposed' Promise. It helped me to detangle the callbacks, and also get rid of timeouts that most of the time take annoying long but are never long enough when it comes to hick0-ups.
As you posted in a different conversation, the callback-mania can become a throw-off and a challenge. May be it is a bit here too... So many things have to get ready - including dependencies have to be considered - before being able to 'moving on' - and you know only within (nested) callbacks when that is the case (for example, you need the ip address, which you can get when successfully connected, and then you can create the server...).
I also wonder why you put all into one single object: wifi. Having the things separated would allow to exchange the 'http connection' with what ever is available C33K, ESP8266, WIZ550S2E,... On the other hand - as pointed out for your case - your gearing up for managing swarms of Picos that connect with ESP8266.
Bottom line, the code you present, is straight forward.
-
@Joakim, it all depends on the requirements... but thanks for your kind words. @DrAzzy's current implementation can be seen at the very beginning of this post - ESP8266 server only serves page once, sometimes twice. His needs are obviously more than satisfied with a simple dedicated implementation using switch-case to handle just 3 options.
Currently I'm deep into node.js / express / ... (and other heavy things - as whole frameworks solutions compared to (small) modules) where things are not that resource constraint... and that leads me (sometimes to go astray) to more generic than just pragmatic solutions. It is an adjustment from client and server side JS to micro controller JS.
You don't need this extra
gps.on("data",...)
in lines 12 thru 14. You already pass the callback in anonymous form onto the connected gps (js) module in line 7 thru 10.