<tpbsd>
I managed to find a solution though, with the help of SB47 next to debug-out connector.
<tpbsd>
When I couple SB47 the SWD cable I use takes Voltage and the nRF Dongle has power from the cable.
<tpbsd>
tabemann, hes using a segger and stuff and had some voltage level problem
<tabemann>
ah
<tpbsd>
every cortex-m has JTAG or SWD
<rdrop-exit>
It has an onboard Segger J-Link, which I think limits your flexibility
<tpbsd>
it's part of the ARM CORE
<tpbsd>
ahh, that may be part of it, but I have no Segger experience
<rdrop-exit>
if you're stuck going through the Segger J-link rather than having direct access to the debugging capabilities of the chip
<tpbsd>
ahh
<rdrop-exit>
Similar situation with the Hi-Five board, which is why I decided to avoid it
<tpbsd>
whats more the $100 dev board is the same
<tpbsd>
The nRF51 DK board has the following key features:
<tpbsd>
· nRF51422 flash based ANT/ANT+, Bluetooth low energy SoC solution
<tpbsd>
· Buttons and LEDs for user interaction
<tpbsd>
· 2.4 GHz compatible with nRF24L devices
<tpbsd>
· I/O interface for Arduino form factor plug-in modules
<tpbsd>
· SEGGER J-Link OB Debugger with debug out functionality
<tpbsd>
· Virtual COM Port interface via UART
<tpbsd>
· Drag and drop Mass Storage Device (MSD) programming
<tpbsd>
· mbed enabled
pareidolia has joined #forth
<tpbsd>
hmm Arduino users and Segger seem to go together
<tpbsd>
tabemann, if you need a Segger that's a big expense
<rdrop-exit>
The problem is when they force you to use the onboard debugger and it's related tools
<tpbsd>
maybe thats why Forth is popular on the $10 board ?
<tpbsd>
rdrop-exit, yeah, agreed
<tabemann>
I'd like to have debugger access for initial kernel debugging
<tpbsd>
aparently the Segger stuff is high end and gives more breakpoints etc, but Ive never seen the point when I have the STM SWD programmer/debugger on every disco and nucleo board
<tpbsd>
rdrop-exit, do you know the difference between a segger and jtag or swd ?
pareidolia_ has joined #forth
<tabemann>
I personally don't need anything elaborate as I rarely use more than a few breakpoints
<tpbsd>
tabemann, I've seen binaries that purport to turn a 'blue-pill' into a Segger
<tpbsd>
even a RPI
<tpbsd>
Ive tried the blue pill one on my non blue pill gear (same electrically) and could't get them to work
pareidolia has quit [Ping timeout: 265 seconds]
<tpbsd>
they purport to create a SWD and GDB 'interface' on the one 'blue pill' but I dont see that as anything special
<rdrop-exit>
I don't remember the details, the problem is the board manufacturers use the presence of the onbard debugger as an excuse not to give you direct access to the JTAG (or whatever) pins, you're forced to dance to the onboard debugger's tune
<tpbsd>
it sounds like another arduino user 'magic tool'
<rdrop-exit>
yup
<tpbsd>
stuff like that really annoys people like me as it's all just sugar coating over the same stuff I use and 10x the price
<tpbsd>
the 'hype' around the Segger is what gives it away to me
<tpbsd>
the guy using that board never mentioned a segger
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<rdrop-exit>
note on the hi-five you're only choice in debug is the onbard Segger J-Link, drag/drop code download
<rdrop-exit>
I don't want my only access to debug to be through a proprietary blob
<rdrop-exit>
no thanks
<tabemann>
all this makes me not want to bother with the nordic board
<rdrop-exit>
I feel your disappointment
<tpbsd>
( Contributed by John Huberts )
<tpbsd>
I have been using the nRFgo Motherboard fitted with a nRF51822 module
<tpbsd>
to do the development and testing. Programming is done using nRFStudio
<tpbsd>
and the Segger J-LINK LITE that comes with the dev kit.
<tpbsd>
I was also able to debug using GDB in the nRF51 Eclipse IDE
<tpbsd>
The motherboard has a DB9 for serial port connection but jumpers need to
<tpbsd>
be placed between P15 (RXD, TXD) and P9 (P2.0, P2.1). If you don't have a
<tpbsd>
serial port on your PC then you will need a USB-serial cable.
<tpbsd>
The UART can be configured to use other pins on the SOC by changing these
<tpbsd>
lines in in terminal.s:
<tpbsd>
.equ RX_PIN_NUMBER, 16
<tpbsd>
.equ TX_PIN_NUMBER, 17
<tpbsd>
... so it looks like a Segger J-LINK LITE comes with that $100 dev board
<rdrop-exit>
I'd rather have JTAG and go through a USB-JTAG cable
<tpbsd>
but not with the $10 board
<tpbsd>
rdrop-exit, me too, and maybe the $100 board stuff needs Windows ?
<rdrop-exit>
eek!
<rdrop-exit>
=8-O
<tabemann>
the board I'm using is actually the nRF52840
<tpbsd>
tabemann, sorry for the bad recommendation, but the Nordic chip is pretty awesome
<tpbsd>
tabemann, theyre all much the same like the STM stuff
<tabemann>
yeah
<tpbsd>
to port Mecrisp-Stellaris to the nRF52840 all the guy had to do was change the usart and the memory resource config iirc
<rdrop-exit>
A board should allow you to have total control without going through, as tp calls it, "sugar coating"
<tabemann>
I just hope I can at least program the damn thing over USB
<tpbsd>
rdrop-exit, I'm the first here to agree with that
<tabemann>
using tools available as free software on Linux
<tpbsd>
tabemann, ah well, at least it's only $10 or so
<tabemann>
yeah
<rdrop-exit>
That's the Forth philosophy, Total Interactive Control
<tpbsd>
I have some pretty expensive boards here I cant use
<tpbsd>
one is a really *really* nice board in a big kit, designed to interact with android phones
<rdrop-exit>
No Middlemen
<tabemann>
that's why I so much didn't want to shell out the money for the $100 board
<tpbsd>
I think I paid about $200 for it
<tpbsd>
it will never run Forth and has it's own dev system etc
<tpbsd>
too expensive to throw away, too specialised to use
<rdrop-exit>
I hate it when they make things "simpler" by locking you out
<tpbsd>
rdrop-exit, yeah, but the hobby market creates these kind of things
<tpbsd>
most hobbyists would throw a fit if they had to connect the 4 wires from a SWD programmer
<tabemann>
they expect that the user is going to be the kind of person who uses arduino-type crap
<tpbsd>
exactly
<tpbsd>
I mean look at the price of the arduinos or the ancient chips, WAY above much later and far more competent tech
<rdrop-exit>
I'm hoping the growth of RISC-V will result in more open hardware
<tpbsd>
I paid $0.56 for my STM32F051's but what does a MEGA328 chip for the first Arduino cost today ?
<tpbsd>
rdrop-exit, me too, but people are getting a bit sick of China's endless counterfeit chips
dave0 has quit [Quit: dave's not here]
<rdrop-exit>
as long as there's a market they'll keep making them
<tpbsd>
true
<rdrop-exit>
fool me once etc...
<tpbsd>
the market tho is the 'rebadging' market
<tpbsd>
so people order a cheap Chinese board and it comes with a relabled counterfeit chip ...
<tpbsd>
which is 95% 'compatible'
<tabemann>
okay, from looking at the datasheet on the dongle board I am getting... it has support for SWD... but it requires soldering...
<tpbsd>
damn
<rdrop-exit>
it's up to the buyer to be willing to spend more for quality and buy directly from a reputable manufacturer
<rdrop-exit>
they're will always be cheap junk available
<rdrop-exit>
(in any market)
<tabemann>
that's why I've gotten my boards from STMicroelectronics directly
<tabemann>
and the Nordic board I'm getting from an authorized dealer (DigiKey)
<tpbsd>
rdrop-exit, yes, exactly, but the hobby market thing that a complete running MCU board shouldn't cost more than $1. They put my penny-pinching ex-wife to shame
<tpbsd>
tabemann, yeah that board is a aftermarket design, thats why it's so cheap
<tpbsd>
it's like the 'blue pill' but there are no nordic chip fakes about
<tpbsd>
tabemann, I think it came out of "Seed Studio" who make great gear, very reputable. I have one of their boards and it's excellent
<rdrop-exit>
if you're not doing volume you shouldn't be penny pinching
<tpbsd>
They made a 200MHz logic analyser board with a USB interface for $50, it is so good I junked my ancient (second hand) 20MHz HP logic analyer that I paid $1000 AUD for back in the 70's
<tabemann>
for my two STM boards I didn't see any need to penny-pinch, and I'm only getting a cheapo Nordic board is because the alternative is way expensive
<tpbsd>
and tabemann is a hobbyist he wont be producing 1 million units
jsoft has joined #forth
<tpbsd>
tabemann, STM do make really expensive boards also, any factory dev board usually costs thousands, to tens of thousands
<tpbsd>
so $100 for a factory Nordic board is actually a bargain ... except for the Segger bs
<tpbsd>
this is the 'golden age of microprocessors' everything is so cheap I still have trouble believing it
<tabemann>
I realize that
<tpbsd>
maybe there are alternative nordic boards without the crap ?
<rdrop-exit>
unfortunately it's also the golden age of limiting direct access to almost everything via bloated tools and APIs
<tpbsd>
tho I think I have made one real Forth cortex-m 'library' in that it takes a parameter when called and offers Words that then do useful stuff
<rdrop-exit>
I think that's one of the reasons people turn to retro-computing as a hobby, the relative freedom compared to what they deal with in their "modern" computing jobs
<tpbsd>
I'm not a fan of retro-computing, it makes me want to throw up. I HAD to work with that old crap once!
<tpbsd>
todays mcus are like a gift from Ghod!
<rdrop-exit>
fine, but imagine what the typical computer guy deals with at work, Javascript and such
<tpbsd>
The nRF52832 Breakout ships out with a pre-programmed serial bootloader, so you don't need a specialized JTAG programmer to load code onto it.
<tpbsd>
hmm, one can use the serial bootloader to upload a Forth
<tpbsd>
rdrop-exit, good point
<tpbsd>
but a serial bootoader doesnt help with debugging
<tpbsd>
tabemann, that link just above does have SWD/JTAG connector pads but soldering is needed
<tpbsd>
tabemann, BBC Micro Bit UK computer edu device -->nRF51822
<tpbsd>
supported by Mecrisp-Stellaris
<tpbsd>
cheap
<Zarutian_HTC>
tpbsd: pads on package or on board? If latter then their placement might be for pogopin jig.
<Zarutian_HTC>
oh, right. Have examined those. Trying to recall the pad layout
<tpbsd>
Zarutian_HTC, I used the wrong term, they look like 0.1" vias for headers
<tpbsd>
oops, the Microbit is ARM Cortex-M0 !!! no good to tabemann !!!
<Zarutian_HTC>
tabemann: heavily parkisons unsteady or just usual fumbly unsteady?
<tabemann>
more like I don't like carrying more than one dish at a time
<tabemann>
and attaching jumper cables to my F407 board was a fucking pain in the ass
<Zarutian_HTC>
tabemann: ah I see. So you might be good with brushing on solderpaste and use a heatgun then
iyzsong- has joined #forth
iyzsong has quit [Ping timeout: 272 seconds]
<tpbsd>
tabemann, one problem with the disco boards is that the pins above and below the board are way too SHORT!
* Zarutian_HTC
has to do a bit of calmness meditation before he hand solders 0403 sized SMD
<tabemann>
tpbsd: yep
<tpbsd>
hahaha, I use a 40x binocular microscope to solder smt
<Zarutian_HTC>
tpbsd: sure but when you have to factor in heart tremors when soldering then you are dealing with seriously small components
<tpbsd>
but 0403 is like a grain of sand!
<tpbsd>
Zarutian_HTC, yeah, it's the same with 50 metre pistol shooting, a heartbeat moves the point of impact
<tpbsd>
just remember not to sneeze with 0403
<tabemann>
back
<tabemann>
tp: I've now got a working LED driver for the F407
<tabemann>
I also figured out why sleep was not working for the F407
<tpbsd>
interrupt config ?
Keshl has quit [Read error: Connection reset by peer]
<tabemann>
I forgot to change the location of the RCC block from its setting for the L476
<tpbsd>
tabemann, sleep was working initially
Keshl has joined #forth
<tpbsd>
hahahah!
<tpbsd>
really ?
<tabemann>
yeah, so I wasn't setting the low power clock for the USART
<tpbsd>
but sleep WAS working on the F407 initially
<tabemann>
it was pretending to work by setting the systick rate high enough that the systick was waking the processor fast enough to avoid problems
<tpbsd>
oh
<tabemann>
I'm going to try my hypothesis here to see if it works
<tpbsd>
cool
karswell_ has joined #forth
karswell_ is now known as karswell
<tabemann>
okay, I'm headed off to bed
<tabemann>
g'night all
<rdrop-exit>
bonne nuit tabemann, stay healthy
<tpbsd>
night tabemann
rdrop-exit has quit [Quit: Lost terminal]
nonlinear has quit [Ping timeout: 256 seconds]
_whitelogger has joined #forth
_whitelogger has joined #forth
nonlinear has joined #forth
webchat9_bbl has joined #forth
mtsd has joined #forth
cartwright has quit [Remote host closed the connection]
cartwright has joined #forth
dddddd has quit [Remote host closed the connection]
webchat9_bbl has quit [Ping timeout: 258 seconds]
webchat9_bbl has joined #forth
mtsd_ has joined #forth
mtsd has quit [Read error: Connection reset by peer]
mtsd_ has quit [Ping timeout: 256 seconds]
actuallybatman has joined #forth
xek has joined #forth
xek has quit [Read error: Connection reset by peer]
xek has joined #forth
xek has quit [Remote host closed the connection]
xek has joined #forth
xek_ has joined #forth
xek_ has quit [Remote host closed the connection]
xek has quit [Ping timeout: 256 seconds]
wickedshell_ has joined #forth
wickedshell_ has quit [Client Quit]
dave0 has joined #forth
jsoft has quit [Ping timeout: 265 seconds]
webchat9_bbl has quit [Read error: Connection reset by peer]
webchat9 has joined #forth
WickedShell has quit [Remote host closed the connection]
dddddd has joined #forth
xek has joined #forth
dys has quit [Remote host closed the connection]
dys has joined #forth
jsoft has joined #forth
iyzsong- has quit [Read error: Connection reset by peer]
dave0 has quit [Quit: dave's not here]
webchat991 has joined #forth
webchat9 has quit [Read error: Connection reset by peer]
Zarutian_HTC has quit [Ping timeout: 250 seconds]
webchat991 has quit [Quit: Leaving]
Zarutian_HTC has joined #forth
jsoft has quit [Ping timeout: 265 seconds]
proteus-guy has quit [Ping timeout: 250 seconds]
crab1 has joined #forth
<crab1>
what's up forth boys
<crab1>
Do any of y'all have experience with writing VMs?
lonjil2 is now known as lonjil
<siraben>
crab1: What sort of VM?
<crab1>
Well I'm writing a simple VM to construct a forth on top of, it's extremely simple, just two stacks and a chunk of memory, a few instructions. But I'm wondering how I should implement interaction with other devices. Should I create instructions specifically to do that? Should I take inspiration from physical hardware and have devices mapped to
<crab1>
memory?
karswell has quit [Remote host closed the connection]
karswell_ has joined #forth
proteus-guy has joined #forth
<crest>
tpbsd: sounds you would want to use the mecrisp register allocator if your chip is supported and has enough space for the slightly larger compiler
<crest>
because spilling the stack to sram costs power, time and code space
rdrop-exit has joined #forth
<rdrop-exit>
crab1, a sandboxed VM written in C or some HLL?
<crab1>
wdym by sandboxed?
<rdrop-exit>
Is your VM's "RAM" just an array in the implementation language?
<crab1>
At least for now I'm doing it that way to keep it simple
<MrMobius>
crab1, memory mapped peripherals are good for things like video ram
<MrMobius>
like if you want to keep it simple and pick a fixed size with one byte per pixel so its easy to draw graphics from forth
<MrMobius>
then let your VM figure out how to take that and render it
<MrMobius>
or just redirect EMIT to console if thats complicated
<crab1>
I don't think I would need graphics, more like filesystem access and block storage, maybe keyboard
<crab1>
and syscalls
<rdrop-exit>
If this is a JAVA style bytecoded VM than I would just have an escape instruction to access the outside world, call it SYS or something like that.
<rdrop-exit>
Then you can have as many different system services as you want.
<crab1>
and sys would just offer an argument to the system then?
<rdrop-exit>
The instruction would take a service# parameter from the stack
<rdrop-exit>
So 0 SYS might be write, 1 SYS might be read, and so on.
<crab1>
hm
<rdrop-exit>
You can add new services without adding new opcodes.
<rdrop-exit>
So if your VM is bytecoded, only one opcode takes care of any future interfacing needs to the underlying OS.
<crab1>
right
xek_ has joined #forth
<rdrop-exit>
Of course when you add a new service# you'll have to recompile your VM executable
<rdrop-exit>
This is all assuming you're doing a JVM style sandboxed VM
xek has quit [Ping timeout: 256 seconds]
<crab1>
Oh it looks like Retro does something similar to what you're talking about
<rdrop-exit>
does it, I've never looked into Retro
<rdrop-exit>
By sandboxed I mean that a VM address isn't a real address of the underlying platform, it's just an offset into your "simulated" RAM array
<rdrop-exit>
Ya, he's talking about actual devices, I'm talking about a way to access OS services from a VM
<rdrop-exit>
but conceptually it's pretty much the same thing
<crc>
my device model can wrap os services (e.g., on unix hosts, I have a unix device to handle system calls and such)
<crab1>
what is io:enumerate useful for?
<rdrop-exit>
a SYS service# can be whatever you want, just a thin wrapper on a POSIX call, or something more high level.
<rdrop-exit>
In retro's case he seems to be using it for a sort of H/W abstraction layer, my proposal is more basic
<crab1>
more basic, less power
<crc>
io:enumerate returns the number of io devices provided by the vm
<crab1>
yes, but when is that useful?
<rdrop-exit>
you can think of it as less power, I think of it as more basic, you think up any new service you want to make available, implement it, assign it a number, and your done.
<crab1>
more work is deferred to the OS, right
<rdrop-exit>
like I said a service is whatever you want it to be, you decide, it's mechanism without policy
<rdrop-exit>
the main thing is that only one opcode in your ISA is used for all your underlying platform needs
<rdrop-exit>
whatever they may turn out to be
<rdrop-exit>
(you can also you the mechanism to configure memory mapped virtual devices if you want those too)
<rdrop-exit>
* use the mechanism (not you the mechanism) :)
<crab1>
we the mechanisms
<rdrop-exit>
:))
<rdrop-exit>
in effect it's a type of escape opcode
xek_ has quit [Remote host closed the connection]
<rdrop-exit>
it's almost 2am here, must sleep, stay healthy my friends
rdrop-exit has quit [Quit: Lost terminal]
<crab1>
sleep well
<crab1>
o too late
<crc>
I like my model; the enumerate and query abilities make it easier for an application to confirm that the vm in use supports the I/O needed
karswell_ has quit [Read error: Connection reset by peer]
dddddd has quit [Ping timeout: 260 seconds]
WickedShell has joined #forth
dave0 has joined #forth
keltono has joined #forth
jsoft has joined #forth
cartwright has quit [Remote host closed the connection]